Merge menus into a single one (Trac #1446)

[str4d]

On I2P-Bote Android main Activity there are two menus:

• the main menu on the left panel;
• an auxiliary menu which is displayed by clicking the 3-dots symbol on the upper right corner or by clicking the Menu button on Samsung phones.

The usage of two menus adds confusion to the user and seems to go against Material design best practices. All other Material-based apps I have played with, including those from Google, use a single menu, where items are gathered into logical groups. IMHO, I2P-Bote would be better with a single menu like them.

Migrated from https://trac.i2p2.de/ticket/1446

{
    "status": "accepted", 
    "changetime": "2015-01-28T23:05:12", 
    "description": "On I2P-Bote Android main Activity there are two menus:\n- the main menu on the left panel;\n- an auxiliary menu which is displayed by clicking the 3-dots symbol on the upper right corner or by clicking the Menu button on Samsung phones.\n\nThe usage of two menus adds confusion to the user and seems to go against Material design best practices. All other Material-based apps I have played with, including those from Google, use a single menu, where items are gathered into logical groups. IMHO, I2P-Bote would be better with a single menu like them.", 
    "reporter": "dllud", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1422486312327492", 
    "component": "apps/android", 
    "summary": "I2P-Bote Android: Merge menus into a single one", 
    "priority": "minor", 
    "keywords": "I2P-Bote usability", 
    "version": "0.9.17", 
    "parents": "", 
    "time": "2015-01-27T00:32:26", 
    "milestone": "soon", 
    "owner": "str4d", 
    "type": "defect"
}

[str4d]

Trac update at 20150127T01:19:56:

• str4d commented:

I agree completely, and this is on my todo list. It requires redesigning the layout of the navigation drawer and reworking the backend, which is why it has not happened yet.

• str4d changed milestone from "undecided" to "soon"
• str4d changed status from "new" to "accepted"

[str4d]

Trac update at 20150127T16:36:40: zzz commented:

related reading:

https://redbooth.com/blog/hamburger-menu-iphone-app https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/

[str4d]

Trac update at 20150127T18:42:04:

• dllud changed attachment from "" to "bote-android-interface-sketch.jpg"
• dllud commented:

I2P-Bote Android interface suggestion sketch

[str4d]

Trac update at 20150127T18:46:02:

• dllud changed _comment0 from:

Thanks zzz! Had never thought about this in detail and indeed I have to agree with the authors of those pages. I wonder why Google is going for "hambuger menus everywhere" with their Material design.

Taking this in consideration, I uploaded a sketch with my interface suggestion.

to:

1422384439761038

• dllud commented:

Thanks zzz! Had never thought about this in detail and indeed I have to agree with the authors of those pages. I wonder why Google is going for "hambuger menus everywhere" with their Material design.

Taking this in consideration, I uploaded a sketch with my interface suggestion. The hamburger menu would be dropped for good.

[str4d]

Trac update at 20150127T21:09:40: str4d commented:

I agree that the navigation drawer is not always the best navigation system. In the I2P Android app, for example, I do think the navigation drawer is a hindrance, and a (well-designed) tab bar would be more beneficial.

However, the nav drawer is a common Google pattern (unlike iOS), which does help negate some of the issues about discoverability that the articles above mention - users can expect it to be there. The primary reason I prefer the navigation drawer is because the Gmail app uses it (as do many other email apps), and I want Bote to be as similar UX-wise as possible to reduce the barrier for new users.

http://www.google.com/design/spec/layout/structure.html#structure-side-nav http://www.google.com/design/spec/patterns/navigation-drawer.html

There is also the consideration that using a tab bar at the bottom of the screen makes the app much more inflexible towards adding new views at the same heirarchy level. If you have more than four, you need to put the rest in a separate menu anyway. Google recommends a nav drawer when you have many different pages that need to be navigated to - such as email folders, which I do plan to add to I2P-Bote at some stage.

https://developer.android.com/design/patterns/navigation-drawer.html#WhenToUse

Every email app I can think of (desktops too) shows their folders/labels/whatever in a side list. IMHO it's a mental model that works for email clients, and not something that the articles on side drawers take into account.

Having said all that, if another navigation design were proposed that worked better, I am open to discussing it. dllud, your design is pretty much what I think I would have done for Bote if I had not used a navigation drawer. However as above, I don't think it would be as usable once users are allowed to make email folders. Also, the "Check email" button would not be on the toolbar, because it is only a backup method for when users are unaware of the pull-to-refresh system.

[str4d]

Trac update at 20150127T21:15:16: str4d commented:

Another thing to think about:

Gmail has a simple interface for switching between email accounts at the top of the nav drawer. I am considering a similar interface for switching between identities - so instead of all emails being displayed in one window, users can opt to focus on a single identity (although the "all identities" view will still be available). This is similar in concept to Thunderbird's consolidated view, where there is a general Inbox for all mail, with subfolders showing each account.

[str4d]

Trac update at 20150128T06:54:30: str4d commented:

From http://thenextweb.com/dd/2014/04/08/ux-designers-side-drawer-navigation-costing-half-user-engagement/

My take-away from all of this is that if most of the user experience takes place in a single view, and it’s only things like user settings and options that need to be accessed in separate screens, then keeping the main UI nice and clean by burying those in a side menu is the way to go.

IMHO this applies to email apps. Discuss?

[str4d]

Trac update at 20150128T13:04:23: dllud commented:

Thanks for all the info and input str4d. Knowing what you plan for Bote Android allows a better reasoning over the UI. I never thought you would implement account switching and user-created folders (will you allow nested folders?). Anyway, personally I would still prefer a bottom navigation with the most frequently used folders (Inbox, Outbox, Sent) easily accessible and a "More..." button to show the what's left (like this: https://lmjabreu.com/post/2014-05-14-how-and-why-not-to-use-hamburger-menus/itunes-tabbar-ff107615.png). The "Change account" button could be on the top panel.

However, a colleague of mine, which uses the GMail app and read no single word of our discussion, told me he prefers the side navigation. He gave me the exact same argument you mentioned previously "GMail and many other messaging apps use it and so do virtually all desktop email clients and webmail interfaces".

Therefore, weighting all pros and cons, and particularly due to the "Change account" feature, I say you should keep the side navigation.

As for the check mail button you should replace it for a swipe down action on the email's list. Most apps (GMail, K-9 Mail, Twitter...) use that action, thus users are quite accustomed to it.

[str4d]

Trac update at 20150128T23:05:12: str4d commented:

Replying to [comment:7 dllud]:

Thanks for all the info and input str4d. Knowing what you plan for Bote Android allows a better reasoning over the UI. I never thought you would implement account switching and user-created folders (will you allow nested folders?).

Bote uses real folders on-disk to store emails, so it is entirely possible to do so.

As for the check mail button you should replace it for a swipe down action on the email's list. Most apps (GMail, K-9 Mail, Twitter...) use that action, thus users are quite accustomed to it.

This is already done - pull down on Inbox. I didn't add it to the other folders because Inbox is the only one that ever gets anything from the network. But would it make more sense to have refresh shown in every folder? This could maybe make sense if e.g. filters were added when user folders were, so emails could be directed into the correct folder. Then it would make sense to be able to refresh from user folders, and would make it simpler to just have pull-to-refresh in every folder.