Back when I was working on Echo, I begged and begged the designer and project manager (who are both gone now) to let us have more than 1 link per notification (in the drop-downs). They refused, saying that having more than 1 link would be confusing and distracting to the user (as if Wikipedia editors weren't able to navigate complicated UIs). Well, it looks like I finally got my wish, but the implementation doesn't make any sense to me. Why would we put all the possible links in a list at the bottom instead of linking them inline? In the current implementation, I still can't click on the parts of the notice that I would expect to be able to click on, like user names, page names, etc. And now there's all this extra clutter at the bottom of every notice. If we're going to give the user links to everything, why don't we just put them inline like everyone would expect?
Description
Related Objects
Event Timeline
Here are some of the considerations for the current design:
- Having one main action per notification helps processing them faster. In most cases you are just interested about what happened, and having interactive links on top of an interactive element requires to make make a choice and be careful on which specific area of the message you are clicking. This was something we wanted to a void in an environment where you want to process items fast.
- The language for some notifications was twisted just to add secondary pieces of information. If we remove this need, some notifications become simpler to process. A notification such as "How the moai moved? Ludmilla responded on Moai", becomes "New reply on 'How the Moai moved?'". Saving this space allows us to include content excepts which seem more relevant information (e.g., to distinguish between two replies and easily find them later).
- Secondary actions provide the additional context (when you are interested in it). For example, the actor name acts like a signature of the message you can check when interested on it. Some notifications had already secondary actions such as "view changes", we are extending that model with icons and a menu to avoid showing too many of them at a time. The idea is to show just two at a time (although there is currently a bug: T125949), but we can reduce the prominence and show just one if we find that the secondary actions are distracting from the main message.
- Actions are expected to increase. Thanking users immediately, being able to keep a notification as unread as a reminder, expanding bundles, or muting a specific kind of notification are some actions that may help users to better organise their work. Having an extensible model that allows more actions to be added (behind the "..." menu when there are more than two) provides a flexibility we cannot support by adding more links to the message.
There are still several aspects to polish (T119374), and we'll find more as the system is used on real notifications.
Research results are promising but it is hard to anticipate all combinations and volumes of notifications users have, so we are interested in hearing (and if screenshots are possible, also seeing) from specific cases.
I'm going to close this ticket as declined. However, I would like to express my continued preference for a simple notification interface that is just a message with appropriate inline links. The only actions that I need from notifications are: visit the page, visit the user, see the diff. Everything else I can do from those pages. Please don't make the interface even more complicated than it already is.
Back when I was working on Echo, I begged and begged the designer and project manager (who are both gone now) to let us have more than 1 link per notification (in the drop-downs).
I don't understand. By 'drop-downs' do you mean in a menu, like we have now? Are you saying you changed your mind, or am I misunderstanding?
That is basically what the primary link (what you get when you click the notification itself) takes you to (that one key action). If you think the primary link goes to a sub-optimal place (e.g. it goes to the topic page when it should go to a diff), that would be good feedback also.
Please don't make the interface even more complicated than it already is.
Other people, particularly those used to other sites (some of which use a similar model to the new one), may find notifications with inline links complicated too. I think "as if Wikipedia editors weren't able to navigate complicated UIs" is a flawed argument. We're not building Echo only for the old-school editors like me who grew up with Monobook.
It would also help to engage with us earlier, especially on design issues like this. We've been working on this a while, done usability research, etc.
I don't understand. By 'drop-downs' do you mean in a menu, like we have now? Are you saying you changed your mind, or am I misunderstanding?
Yes, in menus like we have now (I was just clarifying that I wasn't talking about Special:Notifications which has always supported multiple links per notification). I still believe that notifications should be able to have more than 1 link. I just think that the pendulum has swung dramatically from notifications being too limited to now being too complicated (and apparently the pendulum is still swinging in that direction). Notifications could still be simple and uncluttered but support multiple links. For example: "Joe thanked you for your edit on Spam."
That is basically what the primary link (what you get when you click the notification itself) takes you to (that one key action). If you think the primary link goes to a sub-optimal place (e.g. it goes to the topic page when it should go to a diff), that would be good feedback also.
Sure, that's fine. But why have a separate list of links below each notification instead of the simpler and more intuitive option of putting the links inline?
Other people, particularly those used to other sites (some of which use a similar model to the new one), may find notifications with inline links complicated too.
Sure, but I've never seen a notification system on any site as complicated as the one we have now. I support the idea of mimicking the notification systems on other websites. The notification system I built was a carbon copy of Facebook's (1 link indicated by what is in bold). The one I wanted to implement is the same as Twitter's (multiple inline links that behave just like all the other links on the site). If Twitter users aren't confused by such an interface, I have a hard time imagining that Wikipedia editors would be. Either way, I still think that inline links would be a lot simpler than what we have now.
It would also help to engage with us earlier, especially on design issues like this. We've been working on this a while, done usability research, etc.
I completely understand and agree. I'm just surprised that this is the result that came out of that research. I've never seen anything like what we're doing currently. Hopefully I'm just out of touch and everyone else will love it.
In addition to usability, it will probably simplify support for native apps.
Sure, but I've never seen a notification system on any site as complicated as the one we have now. I support the idea of mimicking the notification systems on other websites. The notification system I built was a carbon copy of Facebook's (1 link indicated by what is in bold).
Every notification on Facebook has at least a menu and Mark as Read. That menu has at least "Hide this notification" and sometimes something like "Turn off notifications about friends' birthdays" (similar to our Mute). I think some might have more then two, but not sure.
You can make a case that things like inline "thank this user" are over-doing it (it's not clear to me yet), but we're not really an outlier with our actual current implementation.