Page MenuHomePhabricator

Overview of newsletters with subscribe/unsubscribe options
Closed, ResolvedPublic

Description

We have decided to complete the MVP without this feature:

an MVP can have a table where all newsletter listed with subscribe and unsubscribe options in 'Actions' column.

However, there is no such table (something like M12). It is ok to deviate from the original plan, as long as the benefits of the alternative are clear. In this case, the two blocks for subscribing / unsubscribing with dropdowns have some problems:

  • The dropdowns don't give an overview like a table can give.
  • The dropdowns only shows the title of the newsletters. A table would show all the information collected, including a link to check the newsletter before subscribing to it.
  • Having subscribe/unsubscribe in separate actions is confusing. You have to check in a dropdown the newsletters ou are subscribed to, and then check in another one the newsletters you could unsubscribe from. A table with checkboxes checked/unchecked gives a better overview (in the future we could sort the newsletters subscribed at the top, now the simplest implementation would suffice).
  • The dropdown complicates things i.e. when you select to subscribe to a newsletter you are already subscribed. The checkbox is clearer, it is either checked or unchecked and users cannot double-check them by design.

Related Objects

Event Timeline

Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil subscribed.
Qgil renamed this task from Overview of newsletter with subscribe/unsubscribe options to Overview of newsletters with subscribe/unsubscribe options.Jun 25 2015, 10:50 AM
Qgil set Security to None.

The reason why we have the selectorother instead of 'select' there is because T102114 is still at large. Currently, the default 'other' would also be posted when the other form is submitted. As an alternative, we can have a

	$defaultOption = array( '' => null );

and in the 'select' options

'options' => array_merge( $defaultOption, $newsletterNames )

Would show up an empty option.

But right now, on print_r - ing both the $formData, I think only the form whose button I clicked only had 'value' for its corresponding key. For eg, I clicked on 'Unsubscribe' button for a newsletter named 'Second' and even though the other form was having something selected, the print_r output was:

The subscribe partArray ( [available-newsletters] => [subscriber] => 1 )
The unsubscribe partArray ( [subscribed-newsletters] => Second [un-subscriber] => 1 )

In that case, I think we can just check

if ( isset( $formData[ 'subscribed-newsletters' ] ) ) { } )

to see if the Unsubscribe form was submitted.

Change 221118 had a related patch set uploaded (by Tinaj1234):
Remove 'Other' option from drop down menu

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

Change 221118 merged by jenkins-bot:
Remove 'Other' option from drop down menu

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

Hey, the "Other" bug is being dealt at T100492: Implement 'Subscribing and unsubscribing' feature for Newsletter extension. This task is for getting rid of the dropdowns after the MVP is completed.

Tinaj1234 raised the priority of this task from Medium to High.

Change 223951 had a related patch set uploaded (by Tinaj1234):
Replace drop down menus in Special:Newsletters with table

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

The related patch uses TablePager and contains just two columns, 'Name of newsletter' and 'Description' whose values are extracted from Database. But right now, there is a need to add a new column 'Actions' with two check boxes - Subscribe and Unsubscribe and this column doesn't have any value in the Database to relate with.

So, I checked the Special:NovaInstance and found out it uses HTML directly instead of using TablePager. 01tonythomas, either we find a way to add column or I think we might have to switch to the way Special:NovaInstance is doing it. Any thoughts ?
So far :

pasted_file (213×954 px, 20 KB)

Looks like https://gerrit.wikimedia.org/r/#/c/223951/ is going smooth.

Low priority : I want inputs on how the table header row and radio button labes should be. Which one looks good ?

Name of NewsletterDescriptionAction
SignpostAwesome NewsletterSubscribe o Unsubscribe o

or

Name of NewsletterDescriptionSubscribe
SignpostAwesome NewsletterYes o No o

we can have a subscriber_count column too, which will readily print outputs from a DB query.

Since this version use JS API to insert into the database, we will need to have a fallback mechanism for non-JS users. This can be done by enclosing everything in a <form> and later calling the same, or a different API with the subscription details. This can go as a separate patch-set though.

Since this version use JS API to insert into the database, we will need to have a fallback mechanism for non-JS users. This can be done by enclosing everything in a <form> and later calling the same, or a different API with the subscription details. This can go as a separate patch-set though.

... and maybe even as a separate task that would not be required in the context of this GSoC project. I'd rather focus first on other features and polishing. The end of GSoC will come sooner than expected, as usual. :)

... and maybe even as a separate task that would not be required in the context of this GSoC project. I'd rather focus first on other features and polishing.

It's almost done and starting today we move onto to other pending tasks!

We have two options for the Special: Newsletters page :

Option 1 - A column which shows if you are subscribed or not and you get one button corresponding to the action you can take in the actions column. If you are already subscribed, you only get a unsubscribe button and vice versa.

option1.png (236×1 px, 24 KB)

Option 2 - A column with radio buttons already checked depending on if are subscribed or not.

option2.png (238×1 px, 21 KB)

Let's finalise on any of these two or if you have better ideas, do comment. Open for suggestions and discussions !

I personally find the second one as a better approach as:

  • The second one will have the corresponding 'Yes'/'No' radio button selected using a line of code, on page reload.
'checked' => in_array( $this->mCurrentRow->nl_id, SpecialNewsletters::$subscribedNewsletterId ) ? true : false,
  • We can save a column, and use it for 'Subscriber count' later ( in the next patch )
  • The first one will need us to alter the text in the 'Current Status' column too on selecting 'Action'. The JS API call makes the database entry readily when the radio button is selected, and not when the 'Submit' button is clicked. This will show the user his current status is 'Not Subscribed' even though he is internally subscribed.

I am waiting for more from UX experts, which sadly I never am.

I'm not a UX expert ether, but in case of doubt it is a good idea to keep it simple and not to invent things.

https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-gadgets offers a very simple, flexible, and efficient approach:

  • Title: Description.

I would start with this, which is simple to code, makes efficient use of space, is mobile friendly, and what not. Then, if we get good UX advice, we can do something more elaborate.

Change 223951 merged by jenkins-bot:
Replace drop down menus in Special:Newsletters with table

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