Jump to: navigation, search

Difference between revisions of "Orion/UX Issues/Selections"

(New page: 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...)
 
(To do)
(10 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
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.  
 
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 ==
 
== 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.
 
* 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.
 +
[[Image:orion-initialnav.png]]
 
* 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.
 
* 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.
+
* 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
 +
[[Image:orion-howdoistage.png]]
  
 
== Ideas to try ==
 
== 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.
 
* 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.  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.)
+
* 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.)
* For the non-default actions, 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 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.
+
[[Image:orion-defaultaction.png]]
 +
* 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.
 +
[[Image:orion-scrollspysectionheader.png]]
 +
 
 +
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?
  
 
== To do ==
 
== To do ==
* Susan will ensure the more menu is always visible and has instructions
+
* 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}}
 
* 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 (screenshots coming)
+
* Libing to investigate the section header/scroll spy concept {{bug|380454}}
* We will need to implement this section header/scroll spy concept
+
* We all need to look at the specific pages to see if this will work, what is the default action, etc.  Example ideas:
 +
[[Image:orion-sitesactions.png]]
 +
[[Image:orion-pluginsactions.png]]
 +
 
 +
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.
 +
[[Image:orion-repositoriesactions.png]]
 +
 
 +
== Unresolved?? ==
 +
* 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?

Revision as of 18:02, 23 May 2012

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.

Orion-initialnav.png

  • 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

Orion-howdoistage.png

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.)

Orion-defaultaction.png

  • 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.

Orion-scrollspysectionheader.png

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?

To do

  • 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
  • Libing to investigate the section header/scroll spy concept bug 380454
  • We all need to look at the specific pages to see if this will work, what is the default action, etc. Example ideas:

Orion-sitesactions.png Orion-pluginsactions.png

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. Orion-repositoriesactions.png

Unresolved??

  • 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?