Community
Participate
Working Groups
We don't have a good guideline for when an action should be in the local actions column/local menu, and when it should just be a checkmark based selection action in the toolbar. It makes sense to me that if an action applies to many items, it should be offered as a selection-based operation. But we've seen evidence that having the action locally is also handy (bug 365463) so some actions that apply to multiples (like move/copy in the navigator) are also located in the actions menu. Git Status currently offers "save diff" as a selection-based command in the unstaged list but not in the actions column. Whereas "stage" appears in both, and "checkout" only appears in the column. We need to have a story for how we decide these things.
I don't know the right answer, but I think there is also potential confusion with the actions that are available in both menus. For example: - In Navigator containing two files - Select file1 with the checkbox - In the menu for file2, hover on "Delete" -> It says, "Delete the selected files or folders" It's not clear what will be deleted here... the selected file, or the file whose menu I opened. I was wondering if the local menus should disappear or grey out when there is a selection? Gmail does something similar, where selection-based actions only appear at the top when there is a non-empty selection.
(In reply to comment #0) > Git Status currently offers "save diff" as a selection-based command in the > unstaged list but not in the actions column. Whereas "stage" appears in both, > and "checkout" only appears in the column. I hit real issue without ability to check out a group of files.See Bug 369667. > We need to have a story for how we decide these things. One of the chapters of the story: Currently we have pageAction and pageNavigationAction. We may want to have SelectionAction, no matter where they are rendered. We may also want to think about selection changes to reflect action rendering. An example is the commit action in the replace preview. If there is no files/matches checked, the commit action should be disabled. Another example is the stage/unstage in git status page.
(In reply to comment #2) > One of the chapters of the story: > Currently we have pageAction and pageNavigationAction. We may want to have > SelectionAction, no matter where they are rendered. We have the pieces of this working (navigator does it, for example see "selectionTools" navigate/table.js, line 84 and others). Since it's not in the global banner, the page is in charge of setting this up. > We may also want to think > about selection changes to reflect action rendering. > An example is the commit action in the replace preview. If there is no > files/matches checked, the commit action should be disabled. > Another example is the stage/unstage in git status page. We have this as well. For example in the navigator, the selection affects the appearance/disappearance of the More menu (and the content as well.) You will need to ensure that your command service instance has been passed the associated selection service instance, and all the right notifications will happen. This of course assumes you are using the common explorer code which handles selection service.... Ping me if it's not clear how to make this work, you should be able to implement this now.
What I was getting at in this bug originally was the UI design question....how are we deciding when something is merely a selection action, when it's an item-level action, and when it's both. We don't have a consistent story, right now we are using the specific workflows to decide.
(In reply to comment #3) > (In reply to comment #2) > > > One of the chapters of the story: > > Currently we have pageAction and pageNavigationAction. We may want to have > > SelectionAction, no matter where they are rendered. > > We have the pieces of this working (navigator does it, for example see > "selectionTools" navigate/table.js, line 84 and others). Since it's not in the > global banner, the page is in charge of setting this up. > > > We may also want to think > > about selection changes to reflect action rendering. > > An example is the commit action in the replace preview. If there is no > > files/matches checked, the commit action should be disabled. > > Another example is the stage/unstage in git status page. > > We have this as well. For example in the navigator, the selection affects the > appearance/disappearance of the More menu (and the content as well.) You will > need to ensure that your command service instance has been passed the > associated selection service instance, and all the right notifications will > happen. This of course assumes you are using the common explorer code which > handles selection service.... Ping me if it's not clear how to make this work, > you should be able to implement this now. Thanks for pointing this out. I opened Bug 369732.
(In reply to comment #4) > What I was getting at in this bug originally was the UI design question....how > are we deciding when something is merely a selection action, when it's an > item-level action, and when it's both. We don't have a consistent story, right > now we are using the specific workflows to decide. The third part to this is "when is it a top level toolbar item in the nav?" For any action that applies to a single folder, we could put it: - in the nav toolbar, evaluated against nav root - in the individual item menu, evaluated against adjacent item - in the selection menu, evaluated against selected items
The guideline we are moving toward with row based selections is something like this: - most selection based actions should be in the toolbar (or section toolbar) menu. We won't have single item (chevron) menus. - actions that can be applied to more than one item and are frequently used are always in the selection menu - the only real exception case is an action that meets these conditions: 1) only ever applies to one item (does not appear when there is a multiple select) 2) is very frequently used 3) it is important to promote discovery through the use of the inline action 4) the icon is clear/intuititive....creates no noise "what is this" reaction
I've now moved navigator and favorites actions to the toolbar, driven off the selection model. We'll still want to visit the other pages...
jjb suggests: >Rather than 2 or 3 items then More, I'd prefer as many items as will >fit and the rest in More. So the question is...do we want to contribute some of the selection actions into the toolbar directly vs. all in one selection menu.?
Szymon had some confusion about the behavior of "new file" and "new folder" in the main toolbar. Currently those refer to the nav root, but he was expecting to be able to select a folder and create something there. (We used to have it in both places and that was confusing, too)...
I opened bug 380299 to consider the specific case in comment 6 and in comment 10 so that we can focus this bug on how to handle in-line actions vs. selection menu actions.
We had some more discussion on this today. See http://wiki.eclipse.org/Orion/UX_Issues/Selections
We've done some stuff in M2: - nav actions are in the "actions menu," chevron is gone - likewise with favorites - we're exploring defining a default action for most places that is inline and the rest would be by selection. Git status has implemented this. We will work with the default action concept further in RC1 with Sites Settings Repositories Git Log
Moving to 1.0. Many pages are adopting this approach, but it is unlikely we will get to others because we need some additional support (scrollspy/pinned section headers and inline floating actions) to make it work. I'll attach other dependent bugs to this bug. We've done (or are in the process of doing) - navigator - favorites - git status - sites We've not done - plugins - git commit - git log - git repo page
moving milestone to 2.0 M1 for future triage.
Can we continue this discussion ASAP?
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
