This page summarizes some ideas regarding how we choose commands for items in a list. The tracking bug is bug 367458.
In 0.5 we have moved to a traditional "extended select" model in many of our lists, such as navigator, git status, where you click on one or more items and choose commands that operate on the selection. Previously, we had a number of actions that appear in-line next to items in a list. We also had some inline actions collapsed into menus, giving a context menu like interaction, but the menu was scoped to a single item.
So far, we've removed these context menus and moved some lesser used inline actions into selection menus. The question is...what is our rule/strategy for when we show actions in-line vs. showing them in a selection menu.
Please edit this document with your thoughts/suggestions. (include your initials so we know who is saying what)...
Problems with current state
- When the initial state of a list is "nothing selected" the selection (More) menu is not appearing so the user has no idea what to do or that a selection model is available.
- For pages where the items can expand into very tall/heavy content (like the compare widgets under the git status changes), it is inconvenient to scroll from deep in the content to the toolbar or heading that provides the actions.
- Often there is a commonly used action that is more convenient to access inline. For example, in git status, it's common to want to stage the items. We've discussed having the actionable link for the item perform the default action, but this isn't obvious to people in use
Ideas to try
- The More menu should be called "Actions" and should always appear, even when there is no selection. If you click on it when it's empty, it tells you that need to make a selection.
- When there is the "80% case" default action for an item, it should appear in-line in a dedicated location. There might be just one of these? (open to discussion). The proposal is that it appears to the left of the item itself, before any decorator or model icons. We will need to style this in a way that it's clear that this thing is a clickable item (maybe the existing border/hover behavior is enough for now, but we may want distinct model icons vs. action icons later.)
- Why would someone want more than the "default" action inline. The problem remains that you could be deep in content and want to perform an action on the item, but you don't know what your selection state is and what the action will apply to. The idea is to use a Scroll Spy with a presentation similar to twitter bootstrap, which would pin your section header (and action buttons) to the top. So if you are deep in the staged list, you see the staged section header pinned to the top. If you are deep in the unstaged list, you see that heading, etc. etc.
The question is...would having the selection count indicator and the selection-based actions close at hand eliminate the need for more than one inline (default) action?
- Susan will ensure the more menu is always visible and has instructions, will name it "Actions" for now. bug 379589
- Szymon will try the "default action" idea in git status and also move the compare widget actions to their own line bug 380004
- We need to look at the specific pages to see if this will work, what is the default action, etc. Example ideas:
For pages that show multiple kinds of items in multiple states, the question is do we try to move to this same model? For example, in the repository page below, the actions available on the active branch are different than those available on a non-active branch. Are we losing information if we move most of these actions into an Actions menu? It seems like this is a case worth preserving more in-line commands.
- We will need to implement this section header/scroll spy concept
- Do we always put selection based actions in "Actions" menu or do we put them as buttons (especially if there is only one, such as "Delete"). Do we always show the button even when there are no selections, to tell you that need to make a selection?
- See above regarding repository page. If different selectable actions have different states, do we keep the inline actions to help explain the relationship? And if that's true, would some sections on a page use a selection model and Actions menu, while other sections did not? Would repository page always use inline actions for consistency within itself, or would it only use inline actions on the branches section?