Opened 4 years ago

Last modified 2 years ago

#1446 accepted defect

I2P-Bote Android: Merge menus into a single one

Reported by: dllud Owned by: str4d
Priority: minor Milestone: soon
Component: apps/android Version: 0.9.17
Keywords: I2P-Bote usability Cc:
Parent Tickets:

Description

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.

Subtickets (add)

Attachments (1)

bote-android-interface-sketch.jpg (60.4 KB) - added by dllud 4 years ago.
I2P-Bote Android interface suggestion sketch

Download all attachments as: .zip

Change History (10)

comment:1 Changed 4 years ago by str4d

  • Milestone changed from undecided to soon
  • Status changed from new to accepted

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.

Changed 4 years ago by dllud

I2P-Bote Android interface suggestion sketch

comment:3 Changed 4 years ago by dllud

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.

Last edited 4 years ago by dllud (previous) (diff)

comment:4 Changed 4 years ago by str4d

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.

comment:5 Changed 4 years ago by str4d

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.

comment:6 Changed 4 years ago by str4d

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?

comment:7 follow-up: Changed 4 years ago by 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?). 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.

comment:8 in reply to: ↑ 7 Changed 4 years ago by str4d

Replying to 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.

comment:9 Changed 2 years ago by str4d

Migrated to https://github.com/i2p/i2p.i2p-bote/issues - I will close these tickets as things are resolved rather than right now, but please make future comments on GitHub?.

Note: See TracTickets for help on using tickets.