Project

General

Profile

Feature #1369

Back button in the action bar

Added by megabitdragon about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
UI/UX
Target version:
-
Start date:
05/16/2014
Due date:
% Done:

0%


Description

Let's consider the case when you have a large number of files in a folder. In this situation, if you are at the last file in the folder you have to scroll all the way to the top to go back to the parent folder (unless you use the system back button). We don't want that. This is the reason why the back button should be in navigation bar. Here is how I would like this to work. When you are at the top level inside the share, the navigation drawer menu should be visible. As soon as enter a directory the navigation drawer indicator has to be hidden and replaced with a button with left arrow and the name of the parent folder. Touching the menu will take you to the parent folder (Like the up button does now). For an example you can look at the gmail app when you select multiple emails. The navigation drawer indicator is replaced with a button with check mark and the navigation drawer is still available by swiping. I understand hiding the indicator is not recommended in the guidelines but I believe this is an elegant solution (from the UI perspective).

History

#1 Updated by ming about 8 years ago

I am sorry but I strongly believe that replacing the indicator is a wrong direction. And I have reasons.

First, as you mentioned, the guidelines state that “all screens that correspond to an entry in your navigation drawer should show the navigation drawer indicator next to the application icon in the action bar”. What you see while selecting emails at the Gmail app is the overlay, not a change of the current action bar. Second, Up navigation using the app icon should be used for activity stack only.

One of main goals of the app’s development was being consistent with the OS. That’s why there is the drawer actually. Hiding the drawer indicator and using the up indicator for inner-fragment navigation definitely is not consistent. I am talking about design at moment, not mentioning that these actions can cause series of hacks.

I understand it is not nice to reject something and give no alternative instead but I really don’t see any other balanced solutions unfortunately. Maybe it is better to stick with the current implementation and move on. One correction—I showed you how file chooser at the Google Drive app shows the app navigation, probably it is a better modification of the current approach. BTW the Google Drive app relies on the back button more than on the navigation in the action bar—one can not even know that path is clickable at all.

#2 Updated by megabitdragon about 8 years ago

I understood that up navigation is not an option. We don't use that. Regarding the guidelines, technically there is no direct entry in the navigation drawer for the actual directory (just for the share) so we will not break the guidelines, but this are just technicalities. As much as I would love to move on, the solution with the up button in the fragment is not acceptable for the aforementioned reason. Can we use an overlay while we are not at the share level? It will include a design similar with the up navigation (i.e. <icon|parent folder) but not the up navigation. I understand it will still be part of the fragment but it will fixed at the top and it will not trigger a redrawing since we will use overlays.Right? Sorry for being such a pain with this. :).

#3 Updated by megabitdragon about 8 years ago

Let's do the following. We will move forward with the development according to the schedule, but keep this bug open.

#4 Updated by ming about 8 years ago

Are you talking about the CAB? As its name states it is for context options, like share a file on long-press and so on. This can be required in the future for files actually.

Let’s think from the beginning. What we are trying to accomplish there? We want to show the current directory name or something similar, plus allow navigation to the upper directory. The second goal is kind of wrong because there is the back button already for that. iOS doesn’t have it and thats why the back navigation is moved to the top. We are thinking about Android, not iOS now, so the second goal can be ignored. The first goal can be achieved displaying the path at the action bar’s subtitle. It is not the best combination with the navigation drawer, but the action bar’s titles are meant to be for naming the current display. Do you agree with these theses?

You really should take a look at the Storage Framework. Just try to attach a file to an email while using the Gmail app in KitKat. It has many great and simple ideas. For example, it solves the problem similar like I described, only using multilevel navigation at the action bar. The bad thing is if we are going to follow its design the Amahi app will be almost the same as the Storage Framework ;-)

#5 Updated by cpg about 8 years ago

  • Status changed from New to Assigned
  • Priority changed from Normal to Low

#6 Updated by megabitdragon about 8 years ago

CAB is not the way to go. We will probably use that for sharing and other operation on individual files/folders.I agree with your reasons. The more I looked at the app the more I thought we should remove the up button all together and use the back button. However, looking at the Storage Framework (thanks for that) something else came to my mind. Don't blame me, you just did this to yourself by showing it to me :-). Can we do something similar to the storage framework but without the multilevel? Just a button, that replaces the selection box with the label "Up to parent dir". Anyway let's just focus on what is next and give this some thought.

#7 Updated by ming about 8 years ago

The left part of the action bar is usually used for navigation purposes. The right part is for buttons and actions. But you are right, let’s keep it open for discussion and ideas at moment.

#8 Updated by ming about 8 years ago

Side note: the current solution (the files list’s header) doesn’t work well for directories without files. There is no list and no header as well, though it forces to use the back button. Probably we should rely on the back button everywhere and not duplicate navigation controls.

#9 Updated by cpg about 8 years ago

  • Status changed from Assigned to Closed

Also available in: Atom