Community
Participate
Working Groups
We have command scopes and associated visual placement for commands that are global, page level, and navigator item level. We don't really have a formal scope for commands that are in "visual panes" within a page, and we have some "item" level commands that don't appear in navigators, so they are hard to find. When first defining scopes, I avoided the temptation to define "viewlet level" command scopes (and associated toolbars) until we had concrete instances. Now we have several pages with a "viewlet" scope. Issues include: - is there a common area (visual) to show these kinds of commands? - are they buttons, icons, or links (if links they should be styled differently from normal links) - how can we style these areas so the scope is clear without coming up with a heavy viewlet treatment? Examples of places we have "visual area" commands - the "add favorites" icon - the git status push, fetch, merge buttons - side by side compare panes The favorites pane got some visual design attention from Linda for viewlet styling, that is where the heavy font and dotted underline came from. But the add favorite command is hard to find if the pane isn't wide. We also have some "nav item" level commands that aren't clearly labeled with actions columns - git commit details compare pane - delete/rename favorites What should we do for items like that where it's not clear you have a hoverable action?
Slightly related to all this is how some page actions really don't "fit" on the left side of the toolbar. For example the "Next>" link in the git log page should probably be on the right. Likewise, the find/replace functionality in the editor should be implemented as a command that collects parameters, and it naturally should be on the right also. How do we deal with this? This is different than something like two-way compare, which has two separate "panes" each needing commands. In the examples above, the commands apply to the main pane, but users expect them to appear somewhere else. Should we have a "page navigation command area" on the right?
(In reply to comment #1) > Slightly related to all this is how some page actions really don't "fit" on the > left side of the toolbar. > > For example the "Next>" link in the git log page should probably be on the > right. > Likewise, the find/replace functionality in the editor should be implemented as > a command that collects parameters, and it naturally should be on the right > also. How do we deal with this? > > This is different than something like two-way compare, which has two separate > "panes" each needing commands. In the examples above, the commands apply to > the main pane, but users expect them to appear somewhere else. Should we have > a "page navigation command area" on the right? Good point. When I implemented find/replace I was wondering where I should put these commands and visual stuff. Mcq, Simon and I sat down together and had a short conversation about a possible generic way to contribute commands like these.We didn't have a conclusion but we all believed that by means of passing parameters to a command, we will be able to contribute commands and extend the command pane visually.
Another reminder is the "selected item/items" scope. An example is git-status page: you can select/deselect a group of files and do further actions. A future example will be global search: you can select a group of folders you want to search on then put keyword and hit search.
(In reply to comment #3) > Another reminder is the "selected item/items" scope. > An example is git-status page: you can select/deselect a group of files and do > further actions. We already have the item scope and a way to tie to selection service, but git status doesn't use it. I think this is already covered in bug 359730.
(In reply to comment #4) > We already have the item scope and a way to tie to selection service, but git > status doesn't use it. I think this is already covered in bug 359730. Yes, I assigned that bug to myself and will look at it in 0.4.
see john's comment in bug 360964 comment 4. Several problems with icon commands that I see: - today we have a strange mix of icons and text (for example see bug 361109) so even the visual separation of commands is not clear - and then on some pages, we put this strange mix in strange/unadorned places (see bug 360964) - and in case you aren't confused enough, sometimes these things are only available on hover, and sometimes they are not. And when they are hoverable, there is not always an affordance that hoverable commands are present (see bug 360472) Things we need to do: - save icons for obvious things like "star" (make favorite) and for arrow (move up/move down) where parsing the text is harder than parsing the icon. - visual adornment for command areas that are not the "global" or "page toolbar" scope AND/OR styling of text commands (button look, etc.) - figure out what we can do instead of hover for command appearance, also taking our mobile problems into account
Looking at the git log page, again there are commands currently in the page toolbar that I expect to be somewhere else (on the right? separated?). I think it's important to try to categorize these and see if we can then have a dedicated visual area. Today we have: - primary navigation (top row) - page-level (dark toolbar) - item-level (actions on each row in a list) Some of the page-level commands feel "better" on the right, and some need some kind of grouping. Examples: - putting things that are really "pane-level" on the right(such as the left/right commands in a side by side compare) - putting things that navigate within the page 1-- find/replace is on the right, feels natural there 2-- Next> link in git log doesn't feel right on the left - some things switch the "page input"...what the page is showing 3-- "Switch to Remote" in git log Seems to me that we could solve 1 and 2 by allowing page-level navigations on the right hand side. But #3 feels different. Also imagine if we had a combo that let you switch which branch you were looking at on git log. Those things seem like they belong in a different place altogether.
Created attachment 205935 [details] mockup/screenshot things to notice: - git log breadcrumb is greatly simplified because it's not trying to show you local vs. remote, etc. - a new area above the right side of toolbar lets you choose the "input" or "location." (it's semantically related to breadcrumb, so we can play with how close to the breadcrumb it should be.) - page navigation (next links) moved to right of toolbar
Another note about command presentation. Links that appear by items that do something should have a different styling than the true links that just take you to some page/resource. For example, the location link in the search results page currently scopes the search down. That link should look different (or we should use a button, or....) We'll need to go looking for cases like this once we settle on the approach.
The need for some kind of "button" styling that is not just hover becomes more evident now that we have the actions commands closer to the model icon (file, folder, etc). You can't really tell (apart from opacity) that the favorites star "does something" and that file/folder do not. So we probably need some css treatment of the commands that shows a border all the time, not just on hover. We could still use opacity to "mute" the button when not in use, but it would always look like a button.
(In reply to comment #10) > So we probably need some css treatment of the commands that shows a border all > the time, not just on hover. We could still use opacity to "mute" the button > when not in use, but it would always look like a button. see jjb's comments in http://dev.eclipse.org/mhonarc/lists/orion-dev/msg01050.html The opacity looks too disabled. We need a treatment for commands that is not too noisy but not disabled. Grouping the commands in a more orderly way (git clones page) should be done as well, the current sprinkling of links and icons will probably look funny regardless of treatment.
I thought the 0.3 file/folder rename box worked really well. 0.4 hides it, not a plus.
(In reply to comment #12) > I thought the 0.3 file/folder rename box worked really well. 0.4 hides it, not > a plus. I take it back. It's fine.
adding Anton to this bug. This bug is kind of rambly and probably cryptic to other people, but I think it describes part of what Anton's styling is trying to address. Where we have "sections" or "boxes" on a page, we need to have standard styling: - trim or no trim - where how are commands shown, how does user know it's a command - how is title shown, etc. We have examples today of these "boxes" - the favorites list (which uses bold font and dotted underline styling as its "trim"). - the git status minilog boxes (which aren't really delineated at all and have cuased some confusion, especially about command scope) The prefs page and the mockup in bug 359621 are introducing new styling here. The end goal (regardless of where we end up in styling) is that these "boxes" of content with associated commands are styled the same so that users can recognize, "here is a box of stuff, links to the full page (if applicable), and these are the things I can do in this box.)
had a review of our current state with Linda and asked for suggestions regarding command rendering, cleanup. For now (before we revisit any overall styling) she suggests: - main toolbar actions are always text (I can think of exceptions, like Libing's next search and prev search result...things where a well known icon like an arrow make sense). - local actions are always icons - the menu icon should be closer to the color of title text so it blends nicely in the nav and doesn't need to be muted - local actions are never muted. They are full strength all the time. Therefore... - we should be very sparing in what local actions earn their own spot in the actions column vs. going in a menu - we don't show model icons unless they are to be differentiated. So if a view always shows a single icon (like...everything is a file) we could get rid of the icon. Not sure we have this case, but I will check. - in "sections" such as the git mini-log commands, we right align the icons - the titles in the sections should be styled like favorites (the section header with the light underline). I can handle these styling details for now in one pass, then we can see if it helps with identification of commands. If needed we can go back and add a button-style rendering. I will update bug 364399 with new icon needs.
committed some helper methods for the simple cases (header styling, command column generation and auto-rendering). However the git-status case is more complicated (dynamic header, object-level commands with different targets rather than dom, etc.) so I need to understand that one better.
Created attachment 208649 [details] mockup this mockup uses Szymon's experiments on a flat repository page, and then uses the ideas in comment #15 to show the commands (all icons, full strength, menu icon, etc.). This certainly looks better than the existing git clones page, but I think having so many different command icons (and some with menus, some not) does not help. I think we're going to need some kind of text/icon combination.
I created a "button" style (icon + text) in the command framework and am experimenting with using this in views where there are lots of actions in "random" places. I changed git status and git repository to use this. I think this is playing better. The commit is 9b46cdcb35203961ecf9cc1cbf2a39c827fcc15b
(In reply to comment #15) > - local actions are never muted. They are full strength all the time. > - in "sections" such as the git mini-log commands, we right align the icons > - the titles in the sections should be styled like favorites (the section > header with the light underline). > > I can handle these styling details for now in one pass, then we can see if it > helps with identification of commands. I updated the git status page to use the headings and underlined currently used by favorites, etc. We'll want to synthesize this style with the new "sectional" styling used by Anton/Szymon. For now I've left it the same. As far as right aligning tools on the sections go. This can be accomplished with tables, or with CSS columns, or with CSS box model. The latter 2 don't work on IE9 and they made the local section commands jump down to their own row. It looked awful, so until we move to IE10 I think we live with the commands not fully right aligned.
Another note (a more general issue with command links) is that the text links need to give some feedback when clicked. If we keep the plain link presentation for commands we need to do something about this.
I've gone as far as I can with this for M2. Awaiting further direction from Linda. This will go in RC1. The plan right now is: * on the main toolbar: ** non-href commands will be rendered as text, but their hover will be buttonish ** href commands will have a link color that is distinct and hover will underline * in pane sections (like git status) ** the header of the pane will have a distinct "bar" ** need to understand from linda how commands (href and plain) will render * in item-level commands ** need to understand from linda how commands (href and plain) will render. ** not sure if we'll use icon+text buttons, just icons, or a mix of both for non href commands
specific implementation things: 1. To get command right justification, use the same technique as the banner - the existing paneHeadingToolbar should become a div float right and we can get rid of paneHeadingCommands. Fix in places like git-status-table.js - the pane title would be float left - paneHeading and auxpaneHeading would then clear: both 2. Favorites doesn't need to be rendered in a table, it should be more like git-status
(In reply to comment #22) > specific implementation things: > > 1. To get command right justification, use the same technique as the banner > - the existing paneHeadingToolbar should become a div float right and we can > get rid of paneHeadingCommands. Fix in places like git-status-table.js > - the pane title would be float left > - paneHeading and auxpaneHeading would then clear: both > > 2. Favorites doesn't need to be rendered in a table, it should be more like > git-status the end result should be that git status and favorites can both simply use "createPaneHeading" and get the right rendering. This should be possible once the favorites table is gone.
(In reply to comment #23) > the end result should be that git status and favorites can both simply use > "createPaneHeading" and get the right rendering. This should be possible once > the favorites table is gone. done. pushed. We now have good visual indication/separation of the panes and commands are right justified, so it's more clear what's happening. What remains in this bug is to finalize on command style rendering in pane/section headings and in local items (button vs link etc.) Linda is working on mockups.
We've looked at various UI guidelines within IBM, some MS guidelines, and also looking at google, github, facebook, etc. There is a lot of literature on "buttons vs. links" and it seems to mostly agree: - action buttons look like buttons in the primary toolset (toolbar) - text "buttons" don't use link color (and have button visual or button hover) - action buttons look like icons or links in a secondary toolset (sections, items) - some styleguides suggest item level actions are always links (Lotus) - if real links and action links are mixed in the same context (row), an action link is bold and a real link is regular - both real links and action links use link color and underline hover I would add this Orion rule: - if it's not an honest to god link, it is not rendered with an <a>. Even if it looks like a link and gets link color and hover, it wouldn't have the "open in new tab" browser menu. This pattern is used in facebook, but not used consistently in, say, jazz So I think we are saying: - in the toolbar (primary actions): Actions are "buttons". Left side is task action, right side is navigation actions. They are always text only unless the action is a spatial/navigational arrow. We will probably style them plain text and button outline on hover/activation. Activation hover is also used when the slideout is open on the command (slideout should look good with activation hover). - in the slideouts: Any actions in the parameter content should be text "buttons" unless they are spatial/navigational arrow. (ie, next/prev in find/replace would be icons, but "replace" and "replace all" should be text.) The "More" "OK/Submit" "Cancel" buttons are "special control buttons" (TBD if they are icons or text, we will mockup) - in the section headers: Actions are "buttons". Section title is on the left, action buttons are on the right. If we ever need "section control buttons" (such as close, expand/collapse) these might be icons. - in line items: href commands are real anchor tags, use link color, and underline hover. action commands are iconic buttons, just an image and then the same button hover as text has in the toolbars. The thinking is that this conserves horizontal real estate and we will rely on the icons being self evident or at least learnable with hover. It also means tooltips (for now) should start with the name of the command.
(In reply to comment #25) > - in the toolbar (primary actions): Actions are "buttons". What is an "Action"? That is: What does the Orion user think when they see "button" vs linked text? > Left side is task action, right side is navigation actions. > They are always text only unless the action is a spatial/navigational arrow. So: Only spatial navigation buttons have icons? > href commands are real anchor tags, use link color, and underline hover. > action commands are iconic buttons, just an image and then the same button > hover as text has in the toolbars. So an 'action command' is not an 'action'? All 'actions' are 'buttons', and all 'action commands' are 'iconic buttons', but what about the reverse (which is what the user has to figure out)? Are all 'iconic-except-navigation-buttons' === 'action commands'? All 'non-iconic-buttons' === 'actions'? Is would be neat if, say, every time I click a button it meant "the URL will not change. and vice versa, every time I click a link it means "new page".
(In reply to comment #26) > (In reply to comment #25) > > - in the toolbar (primary actions): Actions are "buttons". > > What is an "Action"? That is: What does the Orion user think when they see > "button" vs linked text? Hopefully the user doesn't think about this at all. Users click on things and I think the only important thing is that they know... 1. Is the thing I'm clicking on going to take me to a new page?/can I control click this to get a new tab? OR 2. Is something going to happen on this page when I click it? So in some sense we are talking about buttons vs. links but the tricky thing is that there are DOM buttons and anchors, and then often styling that makes them look like each other. (For example facebook has buttons that are styled to look like links, but if you click the browser context menu, you won't see "open in new tab" because in fact it's a button underneath). There are even web UI's (errrr...even us right now) that make an anchor, have an anchor look, but clicking pops up a dialog or otherwise modifies your data, and I think is is bad. We shouldn't have anchors for things that just modify the page. So what we are doing now with, say, "New Folder" in the navigator toolbar is not right. This is what we're trying to fix. And it's clear to me that icon vs. text is not the differentiator. Icon vs. text is a spatial thing (how many of these do I need to fit somewhere). It's also a matter of whether the words to describe a concept are clearer than the picture. Both of these factors lead to icon vs. text choices. > > Left side is task action, right side is navigation actions. > > They are always text only unless the action is a spatial/navigational arrow. > > So: Only spatial navigation buttons have icons? In the primary toolbar, section headings, and slideouts. We want to use text except for very special cases (spatial movement is such a case, it's easier to look at an arrow pointing right than read "move to right." On the other hand, reading "Next Page" is pretty simple and in fact a down arrow might be confusing.) > > > href commands are real anchor tags, use link color, and underline hover. > > > action commands are iconic buttons, just an image and then the same button > > hover as text has in the toolbars. > > So an 'action command' is not an 'action'? All 'actions' are 'buttons', and all > 'action commands' are 'iconic buttons', but what about the reverse (which is > what the user has to figure out)? Are all 'iconic-except-navigation-buttons' > === 'action commands'? All 'non-iconic-buttons' === 'actions'? > > Is would be neat if, say, every time I click a button it meant "the URL will > not change. and vice versa, every time I click a link it means "new page". That is what we are talking about exactly. The only thing that's "funny" is that our buttons won't always look like buttons in the interest of reducing noise. But they will NOT look like links. In the toolbar they will be text, non-link color and look like a button when you hover. They will never pretend to be a link. That is really the crux of this guideline.
I'm going to make a picture for all this, comment 25 is me recording (during a meeting) what we looked at and what we think our guideline will be. It clearly needs to be written up in styleguide form (with pictures) to explain the rationale. Much of this will be implemented in the command framework itself. The goal is that the command definer specifies text, icon, href or code. Then the right thing happens in the framework. The page which contributes the command to the DOM might have to specify something, and if so, it will be documented. For someone contributing a command via plugin there's hopefully nothing to do, they supply the metadata and we do the right thing in the contribution. For the user, hopefully a link is a link and all the places where we have pretend links are gone and they look more like buttons (at least on hover, maybe not a persistent button shape and certainly not link color or underline).
this epic bug is now closed. In a nutshell: for users: - if it looks like a link, it's really a link - in toolbars and section headers, other "actions" are usually text, but sometimes you'll see an arrow for navigation. - in rows in a list, other "actions" are usually icon buttons. The exception case (none known) is that if we don't have an icon, we use bold text. Either way, it gets a button hover. for page implementors: - in general, toolbar and section header commands are rendered in "dom" scope with "button" style - items in list are rendered in "object" scope in "tool" style - if you need to render commands with multiple item targets/handlers in the same dom id, it should be possible. There is no need to create separate spans for each one. The caveat is that you will have to call renderCommand with each item target and handler, so you want to make sure your visibleWhen expressions are set up to deal with each kind - if you have a command that is a navigation arrow then do not put a name on it so that we get the icon. We may develop better API for this post-0.4. This is documented in bug 370014
