This is a task for design feedback on the Newsletter extension.
(The other feedback posted in comments below should be moved here, to check better what has been addressed and what not.)
This is a task for design feedback on the Newsletter extension.
(The other feedback posted in comments below should be moved here, to check better what has been addressed and what not.)
http://newsletter-test.wmflabs.org/wiki/Special:ManageNewsletter
http://newsletter-test.wmflabs.org/wiki/Special:Newsletter/11
http://newsletter-test.wmflabs.org/wiki/Special:CreateNewsletter
http://newsletter-test.wmflabs.org/wiki/Special:Newsletters
Taking this task to go through the feedback (thank you!) and create subtasks, and even microtasks thinking of Google Code-in if possible.
Note that we're going to kill the ManageNewsletter eventually and merge its functionalities with Special:Newsletter.
Has been fixed.
- publisher can't delete own newsletters?
Has been fixed. It did work originally and was broken due to a silly logic error.
There isn't any limit and I don't think it makes sense to add a limit?
- "title of issue's main page" text input should support page autocompletion using AJAX
Makes sense to implement this in core as we now use HTMLTitleTextField. Filed T117033: HTMLTitleTextField should support ajax autocompletion.
- how do I edit any of the fields???
This will be implemented in the future.
- instructions say preferences can be changed at Special:Preferences... is this true currently?
Yes, in the Echo section of preferences. Users can choose either email or web notifications or both.
Change 249792 had a related patch set uploaded (by Florianschmidtwelzow):
Enable Title and User suggestions on Special:ManageNewsletter
https://phabricator.wikimedia.org/T117043
- permissions model is binary? publisher or not? this seems a bit weird...
We did have 'owners' and 'publishers' earlier.. but then we removed the owners and decided to give the sysops the 'newsletter-addpublisher' permission because the roles of owner were limited.
- how many publishers can a single newsletter have?
- how do I add or remove a publisher?
You can remove a publisher in Special:ManageNewsletter using the 'Remove' button you see on the 'Action' column. Only a publisher or a sysop can do this action.
- not clear what the contributors column is... single username?
- not sure this column is needed at all
List the publishers or those who contribute to the newsletter.
Poking around again briefly, it looks like there's still plenty of work to be done here; lots of the feedback from this task is still unresolved. I can revisit this task again in a few weeks if there's interest in having another review.
It shouldn't allow scripts to be executed but it allows wikitext because it goes through Message's parse(). I'm actually not sure if we should be allowing random text in name field though. Needs more thought. Either way, it shouldn't be parsed like that.
- validate all user input and sanitize all user output!
It shouldn't allow scripts to be run now. Tracked in T110491 and T116382.
- if you insert "Special:BlankPage" into the "Title of Main Page" text field at http://newsletter-test.wmflabs.org/wiki/Special:CreateNewsletter, the error message tells you "Special:BlankPage does not exist", where "Special:BlankPage" is a blue link; this is weird behavior
This is the default message thrown by HTMLTitleTextField from core. I have submitted https://gerrit.wikimedia.org/r/250184 for this.
- might be nice to consider using Special:Newsletter/Create, Special:Newsletter/Manage, etc. instead of Special:CreateNewsletter, Special:ManageNewsletter, etc. in order to reduce polluting the Special namespace... or maybe not, probably doesn't matter
Related to T107555: Consistency of names across Newsletter extension special pages. Sort of.
Poking around again briefly, it looks like there's still plenty of work to be done here; lots of the feedback from this task is still unresolved. I can revisit this task again in a few weeks if there's interest in having another review.
Yes, I agree that there's still work that needs to be done before deployment and will start to work on major improvements after next week (if doesn't get resolved by then!) as I will have more time then. Additional feedback is always welcome!
It seems like this field should be setting 'creatable' => true so special pages aren't accepted?
Yes, thanks. I didn't know that this existed and thought that MZMcBride referred to it being linked for non-existent pages.
Change 250462 had a related patch set uploaded (by Glaisher):
Switch Special:CreateNewsletter to use OOUI form
Change 250463 had a related patch set uploaded (by Glaisher):
Remove 'id' field and 'hist' link from Special:Newsletter
Change 250462 merged by jenkins-bot:
Switch Special:CreateNewsletter to use OOUI form
Change 250463 merged by jenkins-bot:
Remove 'id' field and 'hist' link from Special:Newsletter
Change 249792 merged by jenkins-bot:
Enable Title and User suggestions on Special:ManageNewsletter
I think I have been cookie-licking this task for a long time. The team has been looking at the issues reported, and the ones relevant for a first release in Wikimedia have all their own tasks. In addition to this, now we have T124527: UX review of Newsletter extension, which will also help to have our UX back covered.
Change 267449 had a related patch set uploaded (by Glaisher):
Remove intro text from some pages
Change 274449 had a related patch set uploaded (by Glaisher):
Improve navigation links on special pages' subtitle
Change 274449 merged by jenkins-bot:
Improve navigation links on special pages' subtitle
Some problems reported were sold already. I created some subtasks based on feedback about problems that still exist.
Then some comments:
What we are asking for is exactly the title of the main page of the newsletter, so at least it is accurate. Do you have suggestions for a better title? "Newsletter main page"?
- The "subscribe" button at http://newsletter-test.wmflabs.org/wiki/Special:Newsletter/6 shouldn't require confirmation on a separate screen
I agree that a direct subscribe would be better, but I think this is what we had before, and then @Glaisher change it for non-JS compatibility. Is this accurate?
- Description field doesn't parse wikitext (http://newsletter-test.wmflabs.org/wiki/Special:Newsletters)
I think parsing wikitext would complicate things a lot (i.e. not allowing people to insert images, templates, etc. It is meant to be a plain description, and I think plain text is just fine.
- Breadcrumbs at http://newsletter-test.wmflabs.org/wiki/Special:ManageNewsletter aren't aware of the current page (current breadcrumb should turn bold and be de-linked)
The current behavior is consistent with MediaWiki behavior, see for instance https://www.mediawiki.org/wiki/Phabricator/Help
T124527#1961041 has some related comments.
- The "subscribe" button at http://newsletter-test.wmflabs.org/wiki/Special:Newsletter/6 shouldn't require confirmation on a separate screen
I agree that a direct subscribe would be better, but I think this is what we had before, and then @Glaisher change it for non-JS compatibility. Is this accurate?
That was on Special:Newsletters when we used to have radio buttons (see T110191). It would be easy to make the code in ext.newsletter.newsletters.js reusable and attach a click handler to the (un)subscribe button on Special:Newsletter to achieve this.
- Breadcrumbs at http://newsletter-test.wmflabs.org/wiki/Special:ManageNewsletter aren't aware of the current page (current breadcrumb should turn bold and be de-linked)
This was fixed in https://gerrit.wikimedia.org/r/274449
Here are some suggestions!
List of newsletters
Title row should text should be left-aligned to match content below
Increase line-height or spacing between rows
Subscribe: instead of button that says subscribe/unsubscribe, use check boxes
Filter: instead of filter at the top to see all newsletters/subscribed/unsubscribed, make the subscribe column in the table sortable
Subscriber count: also make this sortable
Suggestion: add a column to the table for latest issue date. make this column sortable so that users can see the most recent issues at the top.
Newsletter details
Change text sizes to make title stand out and provide better hierarchy (see mock)
Title - serif 21px
Make main page title, publishers and subscribers bold
Move unsubscribe button to bottom
Create a newsletter
Move title of main page to top, add a description with instructions on creating a new page. Something like, "Create a new page with the title of your newsletter. Add that title here."
Thank you @KHammerstein ! I agree with all your suggestions. I wonder whether we have any technical limitations with checkboxes and/or sortable columns? We have been going a bit back & forth with this.
In any case, I don't think any of the remaining points is blocker for a deployment in production. I will move this task to the corresponding column in our workboard. Progress!
Initially this used to have radio buttons but I changed that to use links because it didn't work for no-JS users. See my comment above just above yours and the linked task. Unless it's possible to link to the subscription page with checkboxes for non-JS users, this cannot be done.
@Qgil as this is a subtask of the deployment goal I assume it is complete and can be closed?
Yes, I would say that this task has run its length. With its deployment in Wikimedia, this new extension will get a new wave of real users, and we will be paying attention to their UX related feedback.