Hi Matthias,
Here are more details about today's 10am PT deployment of AFT on English Wikipedia (see also Bug 45538).
https://bugzilla.wikimedia.org/show_bug.cgi?id=45538
We propose to make these revisions today: * remove AFT4 feedback form on the English Wikipedia * remove feedback form from AFT5 lottery articles * switch AFT5 to 'opt-in'mode
This will remove AFT feedback forms from over 99% of the articles on the English Wikipedia, as requested in the RfC closure statement.
As a result, we would only show feedback forms for articles in the 'Article Feedback 5' and 'Additional Articles' categories. The rationale for keeping AFT5 on the 783 articles with these categories is that many community members added that category themselves and the Foundation wishes to monitor feedback on that small sample, within the scope of the RfC-approved 'continued experimentation' for this tool. At a later date, we may also want to merge these two categories together, so we only have one main 'Article Feedback 5' category, which is easier to remember.
http://en.wikipedia.org/wiki/Category:Article_Feedback_5
Editors who want to enable AFT5 on articles they watch can simply add [[Category:Article_Feedback_5]] to their pages and the feedback form will automatically appear on these pages, as described here. Anyone is welcome to manually add articles to this category, as long as they are prepared to moderate feedback periodically for those articles (using the reader feedback link at the top of their article talk pages).
Articles from the lottery (or articles whose category is removed) would no longer have a reader feedback link at the top of their article talk pages (or in the 'Toolbox' left sidebar on article pages), and their feedback pages would no longer be accessible by the public (unless the Article_Feedback_5 category is added to these articles).
Regarding what to do with the data, Dario has recommended that we keep the data tables for AFT4 and for the old version of AFT5, so that all his dashboards and metrics can continue to point to that data. Would that be an issue, from a technical standpoint?
Next week's deployment will include these new tasks on the English and German Wikipedias: * remove AFT5 DB + archive * upload AFT5 DB with new schema * deploy new features * test and fix bugs
These are the new features which we have been testing on prototype, as described here: http://www.mediawiki.org/wiki/Article_feedback/Version_5/Testing
Next steps are outlined in this updated 2013 release plan for Article Feedback: http://www.mediawiki.org/wiki/Article_feedback/Version_5/Release_Plan_2013
Please let us know if you have any comments or questions.
Let's plan to track the deployment on IRC chat #wikimedia-dev, starting at 10am PT.
Thanks!
Fabrice
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout. Antoine also wants the ability to view all unread notifications from the flyout without leaving the page. This would probably require some type of pagination ability.
Ryan Kaldari
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
Antoine also wants the ability to view all unread notifications from the flyout without leaving the page. This would probably require some type of pagination ability.
I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO.
On Tue, Mar 5, 2013 at 5:51 PM, Steven Walling swalling@wikimedia.org wrote:
This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
FB doesn't - it behaves like Echo; the number goes down, but you can always access recent notifications. I think there a probably good UX reasons for that (the benefit to advanced users may be outweighed by confusion of beginners of where a disappearing notification went and how to get it back). The [X] in Facebook acts like the [X] in Echo to quickly customize notification settings.
On Tue, Mar 5, 2013 at 5:56 PM, Erik Moeller erik@wikimedia.org wrote:
FB doesn't
(Referring here to the FB website; the app may be acting slightly differently in that respect, especially if uses device-native notification features.)
On Tue, Mar 5, 2013 at 6:02 PM, Erik Moeller erik@wikimedia.org wrote:
(Referring here to the FB website; the app may be acting slightly differently in that respect, especially if uses device-native notification features.)
The Android app does not.
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach:
1) On first click you have a smaller window of notifications (4-5). 2) Once you attempt to scroll the notifs list expands vertically to accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all").
The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well.
Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size.
The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for.
That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen.
Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new".
The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications.
Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement.
Luke Welling
On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the
ability to
remove individual notices after they are read (or clear all read notifications) from the flyout.
One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach:
- On first click you have a smaller window of notifications (4-5).
- Once you attempt to scroll the notifs list expands vertically to
accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all").
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Thanks for all your good insights about this proposed feature, which we had planned to tackle after the first release.
I find Facebook's approach to be pretty intuitive. It seems to be working well for people I know, and I have never heard anyone complain about it.
With Echo, we also limit the number of notifications shown in the flyout based on your screen size, and support limited scrolling up to about 10 notifications. After that, you are encouraged to go to the 'All notifications' page, where you can find at least a week's worth of notifications (we currently support an infinite number of notifications on that archive page, but may have to cut back to a month's worth or so).
Currently, we highlight new notifications in the flyout, so it's easy to tell them apart from old notifications, which seems effective. We then un-hilight them after you have viewed the flyout, which is also consistent with Facebook's approach. An argument could be made that perhaps we should only un-hilight that notification if you have actually clicked on it, but I believe we can wait on this until we have done a usability study.
Since we are already using an 'X' button to dismiss notification types which you don't want to see anymore, it would be awkward to add on additional functionality to that button for dismissing just that particular notification, because it would clutter the user interface.
So a 'Mark all as read' button might be a more effective way to address requests like Antoine's, as described in this proposed feature: http://www.mediawiki.org/wiki/Echo/Feature_requirements#Mark_all_as_read
Though I would argue that the current UI provides a practical solution by automatically un-highlighting notifications you have seen in the flyout, as well as limiting the number of notifications in that flyout.
Either way, I recommend that we wait on this feature until after the first release on Enwiki, which will generate a lot of user feedback which may provide more insights from our community.
I do not support the second suggestion to enable viewing all notifications in the flyout, which would seem highly impractical to me. That's what the "All-notification" page is for, and it's only a click away.
My 2 cents,
Fabrice
On Mar 6, 2013, at 8:47 AM, Luke Welling WMF wrote:
The Facebook approach is nice. The number they show initially varies with screen resolution and their scrolling and lazy loading work well.
Most of it would be relatively easy to copy, although I suspect a lot of testing (or a lot of bug reports) have gone into correctly guessing the number of elements to show based on screen size.
The best thing imho about their approach is that they react to all page visits, and very clearly show a bold notification for a notification sent after you visited that page and a more subtle version for a notification that you have already seen the triggering change for.
That's how they solve the feeling of being overwhelmed by notifications. It keeps the new number down and means that a new notification should only refer to a change you have not seen.
Sadly most people (including us) compromise and show notifications as "new" if you have not seen the notification before, and clear their new status before you click through rather than maintaining the relationship between trigger and notification to give a more accurate version of "new".
The Quora compromise on the same UI feature is different but silly. They keep notifications marked new until you manually clear them. I rarely use Quora and have a completely useless readout that tells me I have 200 new notifications.
Unfortunately I think adding "untriggers" alongside all the notification triggers is significant work, so it should remain a potential future enhancement.
Luke Welling
On Tue, Mar 5, 2013 at 9:13 PM, Erik Moeller erik@wikimedia.org wrote: On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
One thing I'm wondering about is whether the high number of notifs that are immediately displayed when you click may be contributing to that - the feeling of being overwhelmed by old notifs + desire to make some disappear. FB/web has a pretty sophisticated approach:
- On first click you have a smaller window of notifications (4-5).
- Once you attempt to scroll the notifs list expands vertically to
accommodate a longer list. 3) Scrolling supports dynamic loading of additional notifs for roughly a week's of backlog (which seems to be identical to what's available in "See all").
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
On Mar 5, 2013, at 5:51 PM, Steven Walling wrote:
On Tue, Mar 5, 2013 at 5:44 PM, Ryan Kaldari rkaldari@wikimedia.org wrote: Both Antoine (hashar) and Reedy have mentioned that they want the ability to remove individual notices after they are read (or clear all read notifications) from the flyout.
This I definitely agree with. You see this pattern in notifications in several contexts (Android ICS has it, Quora, FB I think?).
I'm not sure this is a great idea. If someone really wants to focus on viewing and responding to all unread notifications, asking them to go to a queue of it is likely the simplest and best UX choice IMO.
-- Steven Walling https://wikimediafoundation.org/ _______________________________________________