Page MenuHomePhabricator

Placement of a new Notifications button violates fundamental UX rules
Closed, ResolvedPublicBUG REPORT

Description

Please, switch:

  • newly added Notifications button with
  • "old" Tabs List button toghether

(i.e. place Tabs List button back in the place where it was and put Notification buttons left to it).

Current design violates most fundamental UX/UI rules:

  1. You should avoid situation in which the same button appears in two different places on different switchable screens.
  2. You should introduce new buttons to the new positions, not to replace existing ones (which location was unchanged for years and users get used to it).

Currently (the most recent change in article view design):

  1. You cannot quickly open tabs list, because corresponding button is no longer in the position where it was for past years (and where millions of users are used to it); it is now replaced with the new Notifications button.
  2. You need to get used to the new location (for what reason?). During the transition process you will be constantly opening Notifications screen instead of tabs list.
  3. You cannot quickly open and close tabs list, because corresponding button shifts "there an back" as you switch between article view and tabs list.

The new design (new location of Tabs List button) brings absolutely no value to mobile app users, yet introduce a lot of confusion and irritation. We don't want to switch behaviour we're used to for past years only, because...

01.png (187×720 px, 11 KB)
02.png (202×720 px, 5 KB)

Steps to reproduce

  1. Open mobile Wikipedia app for Android
  2. Open any article or navigate to article view
  3. Notice Tabs List button in the new position
  4. Tap Tabs List button

Expected results

Tabs List button appears in the same place, where it was for past years. Tabs List button does not change its location on different views where it appears.

Actual results

Tabs List button appears in the new position, replaced by Notfications button. Tabs List button switches its location "there and back" on these two switchable views.

Environments observed

App version: 2.7.50374-r-2021-09-13
Android OS versions: 10 (Android security patch level 2021-08-01)
Device model: Motorola One (XT1941-4)
Device language: English

Event Timeline

Thanks for providing feedback @trejder. There are multiple angles to look at this.

The addition of the notification icon on Explore makes sure that the criteria you’re describing is met, see these screenshots [1]:

ExploreTabs
Screenshot_20210922-095121.png (2×1 px, 1012 KB)
Screenshot_20210922-095131.png (2×1 px, 171 KB)
  • In addition to this, I’d argue that the tab switcher is used to navigate to a specific tab, namely to tap on one of the open articles.
  • Another, more likely, scenario: Users navigate to the tabs overview screen to open a new tab from the tab overview screen via + button.
  • The scenario of pressing the tab switch button 'to see' what tabs are open and then tapping the same button again, is less likely. Of course, we’d need to pull data to be 100% sure.

[1] I acknowledge though, that it’s more likely that users press the tab switch button from the article view, not the Explore feed.
Therefore I suggest to add the notifications button to the tabs view for consistency reasons, like this:

ArticleTabs
Article view new notifications.png (1×720 px, 511 KB)
Tab switcher new notifications.png (1×720 px, 108 KB)

Thanks for a great and comprehensive explanation @schoenbaechler. But... Are we talking about two different things? Please, take a look at my screenshots. You're showing bell icon in each screenshot, while I am showing (and talking about) an empty inbox icon. Are we talking about the same functionality, if icons are different?

Anyway, your idea of adding notifications button to the tabs view for consistency reasons sounds great. But (my second argument) it should be switched with tabs button, so notification icon appears as first, next to the search box and tabs button appears between notification icon and three-dot menu.

This way we are able to introduce new functionality without breaking the design that users are used to for years (we just add new button by making the search box a little bit smaller). And in the same time -- this way we are organising all buttons, from right-to-left, based on their importance and usage frequency. I.e. first (from right) three-dot menu as used the most time, then tabs button and then notification button, which is used the least time.

Because I am more than sure that tabs button is used many, many more times than notification button and by many, many more users. This is simply because, if you are just a regular user / reader, without any editing capabilities then you will have the notification button empty all the time and you will not be using that button at all (which is why I propose to add configuration switch to hide notification button at all). While you will will be using tabs button extensively, switching between articles / tabs over and over again.

The above scheme is shared by me (I do edits very little; I have no more than 2 notification per year!) and probably by millions of users of "just reader" kind. It is beyond my imagination to change years -long location of some button, used by millions, only to introduce new button in that place, used by relatively small group of users. I don't know, if that has any value to you, but to be honest, I have even logged out myself from Wiki mobile app and stop editing at all, only to get notification button gone and to have tabs button, where it was previously.

These are key reasons for you I vote so strongly to not move tabs button from its original location under any circumstances.

@trejder

Are we talking about two different things? Please, take a look at my screenshots. You're showing bell icon in each screenshot, while I am showing (and talking about) an empty inbox icon. Are we talking about the same functionality, if icons are different?

We are talking about the same thing, but we currently run an A/B/C test for the placement of notifications (T288248)

These are key reasons for you I vote so strongly to not move tabs button from its original location under any circumstances.

For your other points, we’ll consider a few possible directions in the upcoming days and share it here. Stay tuned...

Thanks again for engaging in the discussion.

@trejder

We are hearing you on your second argument:

it should be switched with tabs button, so notification icon appears as first, next to the search box and tabs button appears between notification icon and three-dot menu.

But still want to move forward with the existing design. Here’s our explanation:

The change, namely moving tabs to be closer to search, has been made deliberately because they are conceptually related (T281413). The thinking is that search is where users go to find articles and some of these are kept in the tabs. We consider it as a necessary step to keep the app’s architecture future proof.

However, we are closely observing the feedback we receive by Email or Google Play on this.


In summary, I propose to move forward with my previous suggestion:

Therefore I suggest to add the notifications button to the tabs view for consistency reasons, like this:

ArticleTabs
Article view new notifications.png (1×720 px, 511 KB)
Tab switcher new notifications.png (1×720 px, 108 KB)

I created a separate task for it: T291682


Thanks for engaging @trejder — we really appreciate the feedback.

JTannerWMF claimed this task.