Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334191

Summary:

[client] visual organization of commands on Orion Pages

Product:

[ECD] Orion

Reporter:

Susan McCourt <susan>

Component:

Client

Assignee:

Susan McCourt <susan>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

bokowski, eclipse.felipe, john.arthorne, malgorzata.tomczyk, Silenio_Quarti, Szymon.Brandys

Version:

0.2

Target Milestone:

0.2

Hardware:

OS:

Windows 7

Whiteboard:

Bug Depends on:

334189

Bug Blocks:

Attachments:

Description	Flags
screenshot of problem described by Szymon	none
suggested changes	none
facebook and twitter examples	none
screenshot of editor with annotations	none
screenshot of navigator with annotations/ideas	none
screenshot of navigator with annotations/ideas	none
screenshot of editor with annotations	none
screenshot of editor with annotations	none

Description Susan McCourt

2011-01-12 21:48:36 EST

Capturing some interesting discussion points from a screencap review with Linda.
Interestingly enough, it seems like she was observing inconsistencies in the way we present commands of different scope and the resulting discussion aligned very well with the API notion of global, page, dom, and object scope in the command service.

Initial observations by Linda:
- why are commands on the top right (new project, undo/redo) mixed in with more global things like search in the top bar?
- why isn't there a search bar on the editor page?
- seems like "page level" commands should be moved to an area underneath the top banner, and reserve the top banner for logo, user info, search
- what is the relationship between favorites/searches and the navigator? On the one hand, it drives the navigator page content. On the other hand, it could be generally useful on any page. The current placement (on the left of the nav info) implies a tight coupling with the navigator. Another design approach would be to list the favorites in a dropdown from the top, rather than dedicating space to it at all times (and this might be more mobile friendly). This would more clearly indicate that there is not necessarily a tight coupling between favorites and the navigator (some favorites would open the navigator, but other favorites would open a file, or a random web page, etc.). Preserve the left hand space for tight couplings with content (such as the outliner/editor relationship)
- unit test icon looks like a "go" button related to search. Need a better strategy in general for presenting the "major task pages" available to a user. Since these are major tasks that the user might not know about up front, we should consider using text rather than icons
- think about a "blank slate user" who logs in for the first time. How do they discover the various tasks?

The main advice is to consider defining three distinct areas.
1. Banner - orion logo, search, user info, dropdowns leading to major tasks - this is task discovery
2. Page header - area below the banner. This is where editor status line, page title (same as in the tab), page-level commands should go
3. Page content

Discussion points:
- we had an interesting discussion about "resource/task based" UI and how this approach effectively "gives the organization of primary navigation to the user" (via browser tabs or separate windows) and "instant integration of other sites into primary nav" (by virtue of opening a tab). (This is nothing we haven't said before, just another way to say it)

- where is the "cutoff" for this use of browser concepts? We wanted to discuss/justify use of a "favorites" pane vs. just saying "use bookmarks." The reason is one of context and scope. It is useful to present the user with things discovered while working in the web context vs. having to use bookmarks to manage it. Also, we have the ability to scope favorites, though we aren't doing so now. (I could attach a defect link to a particular editor page/resource). Would it make sense to preserve the groupings of favorites (navigator-scoping favorites vs. random links vs. searches)

Comment 1 Susan McCourt

2011-01-12 21:52:04 EST

More input:
SZYMON M. BRANDYS Dec 13, 2010 7:14 A.M.
On the navigation page the most important parts are: the tree, actions for creating new tree elements (folders, files) and the search field. Now they are quite dispersed on the page. I think we should reorganize it to 1) place them closer to each other, 2) place them in the top-left corner of the page.

Probably Orion users are not typical Web app users, but anyway I think we could follow principles described in http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-web-design/ and other similar articles.

Another things I noticed are:
- the width of the navigator seems to be fixed. I think it should scale to the page width.
- The user profile name and actions should be in a separate bar. It looks like a common standard to separate User details, preferences and Help from the rest of a web app.

MALGORZATA M. JANCZARSKA Dec 13, 2010 8:52 A.M.
I think user should be able to hide the Favorites section. It takes a lot of place and I think that some users won't be using it at all.

The other problem is that user marks something with a long name as favorite be default the name "hides" under the navigator - favorites pane does not resize automatically. This moves the column with actions on favorites (delete, edit) outside of the users view, not only for the long item, but for all of the favorites.

The other concern is that by default the name of the favorite item is a name of folder or file name without any context in the project. If user would like to mark all the "readme.txt" files in his project (to do some mass edit on them) he will have no distinction between them. We may at least display the full path with project name in hover text.

I'd even consider making the "favorites view" something like Mylyn context view. User could choose whether he prefers to see the navigator or if he chooses "favorites" he would see the navigator view but only containing the favorite files and directories.

Comment 2 Susan McCourt

2011-01-12 21:54:34 EST

Created attachment 186697 [details]
screenshot of problem described by Szymon

Comment 3 Susan McCourt

2011-01-12 21:55:01 EST

Created attachment 186698 [details]
suggested changes

Comment 4 Susan McCourt

2011-01-26 20:20:56 EST

regarding the separation of global and page-level commands.
Boris pointed out that a number of sites are moving toward a top-level menu that handles the global account stuff (account management, logout, settings) so that you have more room. 

Facebook and Twitter both use this approach.

Comment 5 Susan McCourt

2011-01-26 20:24:02 EST

Created attachment 187705 [details]
facebook and twitter examples

screenshot of account stuff being consolidated in a menu.
(On our editor page, our only global commands are these kinds of things, so we could potentially keep the editor-level commands adjacent to that menu if we wanted to avoid having two vertical lines for top-level and page-level commands).

Comment 6 Susan McCourt

2011-02-09 21:15:40 EST

as part of working on bug 334189, small steps have been made.  They are big improvements/reduce code duplication in the command service and navigator, the UI is just only slightly improving until I finish the command service.

Improvements:
- the actions column is moved closer to the name now
- instead of right justifying the nav commands, they are moved underneath the breadcrumb and left justified
- the navigator has fluid layout (you can tell by the nav toolbar, but note that the columns in the nav widget resize dynamically based on need).
- the top toolbar only has global commands now (search and account management)

Things that are only temporary:
- the rendering of the nav toolbar commands is ugly and there are no separators yet (we should have a separator between file commands and the change view command)
- there are lots of action icons available for folders, it is very cluttered.  The file commands (new file, new folder, import, delete) need to be grouped.
- we still need to sort out which file manipulation actions should be available in the nav toolbar that apply to the selections (checked) items.  For example, we could offer a bulk delete.

The next steps will be to render the nav-tree and editor commands using the command service.  That work is part of bug 334189.  Once that is done, we can start polishing the layout/appearance of these things on the page.

Comment 7 Susan McCourt

2011-02-22 11:58:56 EST

Created attachment 189514 [details]
screenshot of editor with annotations

I've finished the work to allow grouped menu contributions in the toolbars and local command areas, so now we can start polishing.  Here's a screenshot of the editor (with a few plug-ins installed, hence those extra icons and the "More" menu).  Some ideas about layout are annotated on the screenshot.  I've sent this to the visual designer, but of course any ideas are welcome from others here.  I'd like to have a more polished look for the banner and local command areas for M6.

Comment 8 Susan McCourt

2011-02-22 11:59:59 EST

Created attachment 189515 [details]
screenshot of navigator with annotations/ideas

Comment 9 Susan McCourt

2011-02-22 21:30:24 EST

Created attachment 189568 [details]
screenshot of navigator with annotations/ideas

This replaces the last nav snapshot.  I made some tweaks:
- brought back the shaded row styling 
- tweaked the breadcrumb current location color to match the logo better
- fixed the bogus spacing and scrollbar in the top banner area
- played with different ways to integrate the breadcrumb bar and its toolbar.  See annotations in screenshot for discussion.  

I think this is a nice improvement, still more to do.

Comment 10 Susan McCourt

2011-02-22 21:37:54 EST

Created attachment 189569 [details]
screenshot of editor with annotations

a few tweaks, still work to do

Comment 11 Susan McCourt

2011-02-22 21:41:39 EST

Created attachment 189570 [details]
screenshot of editor with annotations

Comment 12 Susan McCourt

2011-03-08 13:09:19 EST

Marking this bug fixed given the work that is completed in bug 338830 and bug 338483.

We now have an organized presentation in the banner.
- page title and page info (status line, etc.) in upper left of banner
- primary nav, global commands, user info in upper right of banner
- page-level commands in lower right (dark strip) of banner

There is still some font and spacing polish to work on in bug 338483 but we've achieved the "visual organization" that we needed.