Definitely! I'm pretty sure I wrote about this on some other task. It was blocked due to making some changes to the manage API and then I never got around to working on that. :/

@Glaisher @01tonythomas Could this be a GCi task?

If yes, we could also add it to the new UI to add/remove subscribers (in a different GCi task).

Is there some method which would give us autocomplete and single-line, and etc, like this one here in the GCI site:

This can be an interesting Google-Code-In-2016 task, but frankly I got no idea on how to get such a thing working. Probably we might need some external JS and CSS libraries or the student might need to talk with the WM design team a bit and find out what would be the best approach for this test case.

I can still mentor this one with a discalimer: "Please dont expect any deep implmentation guidelines from the poor mentor involved". I see the students are smarter, and they might find this okey though.

(If you are a GCI student, and is looking for this cool task to work on, comment now - and we get this imported)

Imported as https://codein.withgoogle.com/dashboard/tasks/5079541397585920/ waiting for one of the GCI admins to import!

Ah, true. The closest thing that comes to mind in the MediaWii context is... HotCat? That is a JavaScript gadget.

I don't know how good idea would be to try to "bring" that behavior to the Newsletter extension.

Currently I am working at this task. Here is what I have at this point.

Appearance

Firstly, we have two ways of how this can look like.
The first is list appearance, which @Qgil showed us in the description of the task. Here is how it will look like if we choose this option:

The second is single-line appearance, which @01tonythomas showed us in his comment. Here is the image:

Each option has its advantages and disadvantages. Which one do you think is better? Do you have any suggestions? Please do not judge my design strictly, I will definitely do some more work to improve it :)

Implementation

Here goes the tricky part. And we have some different options on how to do that too.

1. We can create new HTMLForm field, extending HTMLTextField (using HTMLUserTextField as example). We also create new InputWidget and js + css module related to it: we can use the copy of mw.widgets.UserInputWidget as starting point and then try to extend its functionality. To implement the first variant of design, we will need just to add some html of the list before the input and insert new element to it each time new username is entered. To implement the second variant, we can add div before the input, containing the list of users. Some hacks will be needed to make it work: I think we will need to set div position to absolute to make it overlay the input and we need to modify inputs padding to shift the position, where the new text is entered.

2. We can create new HTMLForm field, extending HTMLFormField. Some js + css modules will also be needed. We will create new input from scratch, trying to make it match the design of other inputs using css. That will be a bit more simple, and we will use less hacks to make it work. And I think it will work better. However, there is one disadvantage: looks like it will not use OOui at all, so some work will be needed to make it look like other inputs.

3. Maybe try to create completly new OOui widget.

All options will have autocomplete feature.

I tried to explain my thoughts as well as I could. If anything is unclear, feel free to ask and I will give more info.
I am still thinking on implementation and will update you as I figure out the better way of doing this.

What are your thoughts on this?

Personally, I like the second option. I think it looks nicer, but the first does look more like a classic newsletter. In terms of code, it's probably wiser to ask @01tonythomas and @Qgil

Wow. Great to see this coming up. Let me paste something here for your reference, and a green flag for the second one (personally I would've waited for @Qgil too)

Reedy> tonythomas: The second design seems to be getting more common; GCI, Phab etc
addshore> I agree with Reedy

Second option is nicer indeed! Let's go for that.

@01tonythomas @MtDu : Yeah, second option is more user-friendly.

In T131492#2923360, @Phantom42 wrote:

Implementation

Here goes the tricky part. And we have some different options on how to do that too.

1. We can create new HTMLForm field, extending HTMLTextField (using HTMLUserTextField as example). We also create new InputWidget and js + css module related to it: we can use the copy of mw.widgets.UserInputWidget as starting point and then try to extend its functionality. To implement the first variant of design, we will need just to add some html of the list before the input and insert new element to it each time new username is entered. To implement the second variant, we can add div before the input, containing the list of users. Some hacks will be needed to make it work: I think we will need to set div position to absolute to make it overlay the input and we need to modify inputs padding to shift the position, where the new text is entered.

2. We can create new HTMLForm field, extending HTMLFormField. Some js + css modules will also be needed. We will create new input from scratch, trying to make it match the design of other inputs using css. That will be a bit more simple, and we will use less hacks to make it work. And I think it will work better. However, there is one disadvantage: looks like it will not use OOui at all, so some work will be needed to make it look like other inputs.

3. Maybe try to create completly new OOui widget.

This sounds just like CapsuleMultiselectWidget... I'm sure there's something I'm missing though

In T131492#2925381, @Jay8g wrote:

This sounds just like CapsuleMultiselectWidget... I'm sure there's something I'm missing though

I have tried to find documentation about this widget, unsuccessfully. Can someone provide a URL, please?

I have tried to find documentation about this widget, unsuccessfully. Can someone provide a URL, please?

I think this one: https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.CapsuleMultiselectWidget
But I don't think that's what we need.

Anyway, I am working now at creating new widget option, and I am almost done. It seems that it is the right way of implementing this.

Update: I was wrong, checked it again. Looks like it is what we need

Shouldn't it be also used in subscriber add/remove? Btw, capsuleMultiselectWidget is exactly what we want, look at https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-ltr-desktop

Btw, capsuleMultiselectWidget is exactly what we want, look at https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-ltr-desktop

Yes, I have mentioned that in my previous comment.

Actually I am almost done and will upload a patch to Gerrit soon. I implemented it as another HtmlFormField (which uses CapsuleMultiselectWidget), so we can use it on any other page (and adding subscribers too, if it is needed) just by changing few lines of code.

@Phantom42: Awesome! Would love to see this working!

I think that it would be a nice idea to make a fallback to simple textarea, if javascript is not enabled. However, there are some small disadvantages: less clean code and textarea showing first few moments after page is loaded (until related js code is executed to hide it). What are your thoughts on it? Is such thing worth adding?

@Phantom42: Hmm, a lot of stuff uses javascript. Maybe just show warning? This would be another task. @01tonythomas: What do you think about it?

Change 331205 had a related patch set uploaded (by Phantom42):
UsersMultiselect widget and form field.

https://gerrit.wikimedia.org/r/331205

I have uploaded patch, which adds needed widget and form field. If something needs improvment, or there are any problems, please tell and I will fix. I will also upload second patch later which will make Newsletter extension use newly added widget.

@Phantom42: Hmm, why split it in 2 patches? Really want to test this!

@FilipGCI We have two patches: the first one to the core repository, which adds new html form field and new widget. The second patch is to the Newsletter repository, which makes Newsletter use newly added widget instead of textarea. That allows us to use this widget in other extensions if needed too. I think there is no other way of doing that :)

@Phantom42: For me, its onneeded to add new class to core repo. UserMultiselectCapsule is that what you want, just add this class to Newsletter. @01tonythomas

In T131492#2926702, @FilipGCI wrote:

For me, its onneeded to add new class to core repo. UserMultiselectCapsule is that what you want, just add this class to Newsletter.

If I understood you correctly, that's exactly what we are doing now

@Phantom42: Yeah, I know. But its uneeded to add this to core. Just create new class in Newsletter extension.

@FilipGCI Now I understand what you mean. But I don't think that is a good idea. Because apart from adding a new class to this widget, we will also need to modify form creation code, which will make code less clear. I think it is much better to add new widget to the core repository and then change just few lines in NewsletterEditPage.php.

@Phantom42: Hmm, I tought we can add new HtmlForm without modifying the code, but i'm not sure. @Reedy - what do you think about it?

Change 331214 had a related patch set uploaded (by Phantom42):
Use UsersMultiselectWidget to manage publishers list

https://gerrit.wikimedia.org/r/331214

@Florian during code review on Gerrit have said that we need to make some support for non-JS users. I agree with that and offer to do a fallback to the text area with each username at a new line (like we had before) in such cases. Maybe the same for non-OOUI forms. What are you thoughts about that? Is such solution okay?

The solution we had before was OK. Your plan sounds good, @Phantom42.

@Phantom42: We need to get merged this previous patch. Will checkout them, and try this out tomorrow!

@Qgil thank you! I will implement it soon (right after I finish with my current GCI task)

@FilipGCI No, we can't get it merged. I need to fix all issues first, mentioned by reviewers. However you can checkout it now using:

git fetch https://gerrit.wikimedia.org/r/mediawiki/core refs/changes/05/331205/4 && git checkout FETCH_HEAD

(in core directory)
and in Newsletter extension directory:

git fetch https://gerrit.wikimedia.org/r/mediawiki/extensions/Newsletter refs/changes/14/331214/1 && git checkout FETCH_HEAD

@Qgil: @Phantom42: Tested, looks good!

Neat!

I fixed some code issues mentioned by @Florian . Additionally, implemented fallback to simple textarea in non-js mode. Also added indication of suggestions being loaded.
What are your thoughts? Is there something we need to change or improve now?

In general, I think it is time for us to focus on the extension to be deployed, get real users, and pay attention to their feedback. There have been many improvements thanks to Google Code-in (yay!) and it is better to let things rest a bit, test the extension...

All this to say that I don't see an urgency to improve in this specific task unless we find clear bugs.

Change 331205 merged by jenkins-bot:
UsersMultiselect widget and form field.

https://gerrit.wikimedia.org/r/331205

Wow. the upstream got merged. yay! \m/

Great! The next step is to review and merge this patch: https://gerrit.wikimedia.org/r/#/c/331214/ which makes Newsletter extension use newly added widget.

Change 331214 merged by jenkins-bot:
Use UsersMultiselectWidget to manage publishers list

https://gerrit.wikimedia.org/r/331214

Wow. Great to see this one. For people to see the change => http://newsletter-test.wmflabs.org/w/index.php?title=Newsletter:CustomOne&action=edit

Very cool! What is left here?