Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
We have often said that in Orion, the work a user is doing on a particular page can be thought of as "task + resource." As we design more complicated pages, it has become important to formalize the anatomy of an Orion page, so that we can define a common page layout that lets the user work with the resource+task at hand, and use well known mechanisms to navigate to other resources within a task page, or choose related tasks.
Our original work in Orion 0.2/0.3 focused on designing a common header and footer, but we didn't have a fully specified "anatomy." This left developers building individual pages to make a best guess as to where certain parts go that may not have been present in the pages already built.
For Orion 0.4, we need to revisit the anatomy of our pages to ensure that we are consistent in showing various elements. We want to formally describe the elements on the page, with terminology that makes it easy to talk about this structure without necessarily referring to visual positions such as "header" or "footer."
Problems with current page structure
- Header content. The header is too crowded for some views (that are trying to cram multiple levels of "where I am"), yet it is still considered too tall when editing or trying to work on a small screen/tablet device. We've just added a feature to hide the banner/footer when editing. We should consider using more vertical space to address the additional context information, since the user can get rid of it when needed. Perhaps the "where I am" and breadcrumb navigation should be placed below the header. This is more in line with what other sites do, and also means that if we collapse the header when editing, etc., some of the more useful bits currently in the header will still be visible in a secondary layer beneath the header.
- Footer content. The footer content was never designed with any structure in mind, and some of the elements that appear in the header could be moved to the footer.
- Resource switching beyond the breadcrumb. We use the breadcrumb for scoping the information on the current page, but there are additional ways to look at the page data (for example, git branches and local/remote). We need multiple levels of "where I am/what I'm looking at" and a way to switch between these. Using "task commands" in the toolbar to accomplish this clutters things up. An early mockup tried to solve these problems in the current header anatomy and it does not seem sufficient. We also need a way for plug-ins to contribute contextual "where I am" information, such as being able to know in the editor which git branch the file came from. Bottom line is we probably need the header to be more static (it could even be smaller) and then the "where I am" moves just beneath.
- Subsection affordances. The commands/links that appear for subsections of a page do not visually relate to the subsections, and it's not always clear which subsections belong together. Users have trouble orienting themselves in pages like "Git Status" and may not notice certain commands (such as push) because the affordances are not clear.
- Links to related pages. In some workflows, it's very common to open a related page. For example, the "Git Status" page includes mini-logs and links to those logs. But one cannot get to "Git Status" from a "Git Log." We need to be specific about the relationship between pages and provide a place where the user can quickly access "related links." These links are different than discovery or primary nav links. Need to understand how this relates to favorites, and how favorites can be accessed from anywhere.
- Page Navigation Commands. In 0.3, the page navigation commands appeared alongside the task commands. In the 0.4 stream, we've moved navigation commands to the right on the toolbar. It seems logical to separate these, but we should revisit the location in the context of the larger redesign.
Defining Page Elements
For Orion 0.4, we further expand on the page elements and introduce semantic elements (such as "Legalese") for info that we used to refer to visually ("the footer.")
- Branding (typically the top left corner)
- Legalese (usually in the footer)
- Discovery links appear prominently/consistently on the page to teach you what can you do. These links may even link to other sites. They are the least related to the task at hand, but you should know about them.
- Expected links appear less prominently, but still consistently, on the page. They are links to less important places, such as user guides, documentation, support info, etc. The user expects them to be there, so is willing to go looking for them.
- User info shows who you are and lets you manipulate your Orion environment
- login, logout, account profile
- sometimes Help goes here
- Notifications alert the user to error messages, progress or status info, etc.
- Search the location of search may depend on whether it is scoped to the current page.
- Task (aka "Page Title") describes the user task you are on. It is static.
- Resource (aka "Where I Am") indicates what resource you are working with.
- Primary dimension (optional) defines the main context for viewing your resource. (Need a better name). For some resources, there may only be one dimension (such as the workspace) so there is no need to name/show it. However, once you introduce source control, which can populate your workspace, you have an added dimension, such as the git branch name. Part of showing primary location is allowing user to switch it. Also note that the dimension might be provided by a plug-in so it needs to be able to annotate other pages with the dimension switching.
- Secondary dimension (optional) further refines the context if needed. For example, local/remote branches in git.
- Hierarchical location is shown in a breadcrumb. Once the primary/secondary dimensions are established, the breadcrumb is used to scope into the hierarchical content. This statement suggests that in something like a git page, the breadcrumb information should appear lower in the page than the branch and local/remote info. (This also seems to jive with the Jazz approach of putting the breadcrumb in the resource area). We also need to think about the breadcrumb in the editor. It does not do scoping, but rather takes you to the navigator. In other pages, it scopes the current list. We need to reconcile this. Perhaps we just define breadcrumb behavior for lists vs. single resources.
- Resource Name is the "thing" that you are working with, having resolved the various dimensions and containment.
- Related task links offer to take you to another page based on what you are currently doing.
- Task+Resource Commands (links, tabs or buttons) help you manipulate the entire task/resource at hand. These are now specifically defined as commands that change the state of the resource and do not include commands that navigate, change the view, or the "where I am"
- Resource View Controls
- Pagination Navigation
- View switching
- View options
- Outliners help to navigate through a large resource
- Sections show different parts/aspects of the same resource/task that one may want to work with.
- Resource/edit commands (links, buttons, gestures, etc.) appear inside the main resource or sections you are working with and help to edit/act on that resource
Note that this list captures the atomic semantic elements that will get combined into a visual area. For example, Jazz defines an area on a page called the "Page Control & Resource Header Area" which contains the "Where I Am," "Task Commands," "In-resource navigation," etc. The important thing is to establish the visual hierarchy and ensure that we have room for the various atomic elements. It's not clear that any one Orion page contains all of these elements, but we need to determine that when keeping room for them...
The following wireframe repositions the page elements by including all static information in a smaller top area, with task and resource information in a separate area below. The notifications are moved to the footer. This wireframe includes a full content area (the entire wireframe is 1024x768) for perspective.
Please note this is a color-coded wireframe, not a proposed style! It's not assumed that the things shown as boxes will in fact have borders or colored trim.
Simple Pages (non-sectioned)
The following example shows the header for an Orion editor using this new anatomy. (This is the last wireframe that shows the whole screen. For the rest of the pictures, we'll just show the header and resource part since the footer is basically the same.)
Here's an example of git log using the new header. Note that the branch and local/remote switching can now be done in the second section without a massive breadcrumb.
When the resource is large enough to require a dedicated outliner, a command toolbar is applied to each pane separately.
Pages that have distinct "sections" include a command area (toolbar) with each section. There is no "global" toolbar since there is not a "default" section. Again, note that this is a wireframe and it's very likely the sections wouldn't actually have boxed headers. What's important is that we get common styling and conventions for the associated commands, etc.
Here is the "sectional" page wireframe applied to the new "flat style" repository page.
Outliners with Sectional Pages
For pages with many sections, we expect that we'll need an outliner for navigating the sections. It remains to be seen whether the outliner would show only one section at a time (master/details pattern) or just navigate to the selected section. It's not clear that every page with "sections" should default to an outline view, we'll need to figure this out.
Apart from doing the visual design (color, fonts, trim, etc.) for the header and the command sections, some other issues need to be determined:
- What are the conventions for representing commands in the various scopes? Links, icons, buttons, etc.
- command toolbar
- section commands
- item level commands
- How does a navigation pane like "Favorites" fit into this model? Do we consider it the "super outliner"
- How would you get to Favorites when you already have an outliner, does it "swap in?"