Bugzilla – Full Text Bug Listing
| Summary: | Accessing page sections using a sidebar | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> | ||||
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | antonm, edyta.przymus, john.arthorne, ken_walker, libingw, Mike_Wilson, simon_kaegi, susan | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 349328, 369057, 369605, 373143, 374284, 374400 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Szymon Brandys
From Susan: My two cents on this specific case: I favor (2) for the repo page for the same reasons Szymon mentions. Also, I think that someone who favors (2) probably wants the outliner collapsed by default. (I do). However I could see that in some contexts (pref page?) a variant of (1), or at least the outliner defaulting to being on, would be helpful, for a couple reasons. - When the sections on the page are very heterogenous (such as preferences) the user task is probably related to the selected state of the outliner. For example, I want to go modify the plugins list. If I last was looking at the "plugins" list on the pref page, then when I go back to the pref page, I probably want the plugin info to show first. (Especially if I navigated away from the page and then used history to get back.) - for performance. If it's expensive to generate the information about a section that the user might never visit. For the general case, I like (2) because I think of this as just another "outliner" and of course the editor outliner works this way. From John: We have two quite different navigation metaphors here. 1) is an outline metaphor where I have a contiguous large document and the pane helps me jump around. 2) is a tab folder metaphor where I conceptually have a pile of documents and clicking a tab brings that one to the front. I think we need to avoid using the same presentation style for both cases since they are conceptually quite different. We will probably have uses for both of these metaphors but they need to be visually distinct. The presentation given by Anton definitely looks like 2). We wouldn't change the background colour of the selected tab if the user could scroll to another section and cause the tabs and document to no longer match. Having said all that I don't know what I would prefer for the repository page. I think I would opt to keep it as a single page for awhile and see how that feels (as it is now). I kind of agree that splitting it up into multiple pages adds back some of the extra clicks we were trying to get away from with this new layout. Another random benefit of 2) is it works in cases where the categories are not mutually exclusive. For example if I had information that I wanted to have appear in multiple tabs, or a meta-tab like "Recent" or "Search" that shows content from multiple sections. From Susan: There is also a middle ground between 1 and 2 that I've seen used a lot on the apple site (for example, if you are buying a MacBook and trying to configure it.) The sections are collapsible, so you can navigate through a massive pile of sections or you can collapse them. For example: http://store.apple.com/us/configure/MC968LL/A?select=select&product=MC968LL%2FA Last year, they used an "outline on the left, expandible/collapsible sections on the right" mode. Thought it was an interesting analogy to "Preferences." But checking the site today, it seems the "outline" is now "section links" on the top, which are less useful, because as soon as you use one of them, the links scroll out of view. I could imagine adopting (1) all/most of the time and then see where it doesn't work. If there were performance problems generating content that the user might not want, then a pane could stay collapsed by default until the user selected it. I'm not sure I understand the advantage of mutual exclusiveness that you are talking about. We could decide to put the same information in multiple sections regardless of what UI is used, couldn't we? From Anton: Personally I don't think the volume of content should always determine what justifies a section - also isn't the volume of content variable here? Note that content is divided into sections on github's website itself. I would say for the flat 'report' like approach of #1, we might need to consider making the sections stand out a little more from one another with a css tweak. I also wonder about the use cases for this too. I'm only just becoming familiar with git ( have experience with svn, rtc, clearcase up to now ) - but so far I've been primarily interested in commits. I would say that for someone not greatly familiar with git, it can be a little overwhelming seeing all of this data collected together. I'd think that when someone accesses repository information, that they'd be going there for a specific reason, not to see a report of all data. That said - you guys have used git more than me, so may have a more realistic understanding. I'd also question what the best approach is for tablets - and would suggest the proposal that I make is more friendly for tablets. Just some thoughts. From Szymon: Another thought. Each section on the new repo page may be in one of three states: non-visible (none), showing the recent data (recent), showing the full view (full). The displayed resource defines the section states. When page shows a repository resource (e.g. "/gitapi/clone/file/ag/"), sections are: - repo (full) - working dir section (full) - incoming/outgoing commits for active branch (full) - branches (recent) - remote branches (none) - remotes (full) Clicking "See all" changes the resource for the page. The page shows now a branch resource (e.g. "/gitapi/branch/file/ag/") and sections are: - repo (full) - working dir section (none) - incoming/outgoing commits for active branch (none) - branches (full) - remote branches (full) - remotes (none) I think we could add the collapsed state (collapsed) and change sections when a repository resource is displayed to: - repo (full) - working dir section: if no changes (collapsed), otherwise (full) - incoming/outgoing commits for active branch: if no commits (collapsed), otherwise (full) - branches (recent) - remote branches (none) - remotes (full) Note that if the user collapses or expands sections, it would be per session only, unless we use some preferences to store sections states. I wonder if we need any outline for switching between Repo, Tags, Branches? For me just "See all" links are enough. But maybe an outline with these links would help in navigating on the page? Anton said: >I would say for >the flat 'report' like approach of #1, we might need to consider making the >sections stand out a little more from one another with a css tweak. Agree, it's hard to wade through the sections without more emphasis. Linda is working on this in bug 360986 and I expect us to have some kind of gradient, more toolbar-like treatment. We can adopt this for all sectional pages (note that the user profile page has a gray bar for its sections and it is really helpful.) I'd also like to see pane-like area like git status get this treatment, once we decide what it is. Now that I've had a chance to play with the new settings page, I'm less interested in thinking about the categories selector as an outliner. It sounded good to me in theory, but I agree with John's point that these are two different metaphors completely. I'm not sure having expand/collapse and trying to treat it like an outliner will help. I think it might just clutter things. And going back to look at the Mac example, it really is more similar to the repo case (showing different aspects of the same item) then it is preferences, where you are looking at completely heterogenous things that aren't related to each other. So here's a suggestion. What if on the sectional pages, the navigator pane on the left let the user pick how it worked? There could be a little menu/chooser in its toolbar and you could run it in "outline mode" or "selection mode." If we are marking up the selection pages similarly, it should be pretty straightforward to implement both modes, and the user could pick which style they liked per page. Some other issues Do we name the section navigator? (note that Anton uses "Categories" as a title but I'm not sure its necessary). Do we want to provide a splitter for it? see also bug 369605, I'm not sure that this problem heavily favors an outliner vs. the master/details pattern, but I find myself wishing I had either one today. Susan this feel overly general but there is some good discussion here. Moving to 0.5 but this needs to be chopped into deliverable pieces. (In reply to comment #9) > Susan this feel overly general but there is some good discussion here. Moving > to 0.5 but this needs to be chopped into deliverable pieces. What I'm hoping is that we can have a UI discussion about this early in 0.5 and then this bug can be a tracking bug for the various changes needed. (In reply to comment #10) > What I'm hoping is that we can have a UI discussion about this early in 0.5 and > then this bug can be a tracking bug for the various changes needed. Szymon, Anton, and I discussed this together. Some thoughts: - Anton would like to let Settings page scale up before deciding whether it shares navigation patterns with the sectional pages that have lots of content - We acknowledge that there is not "one navigation style fits all" but Susan wonders if there are maybe 2-3 navigation styles that do work, and whether the user would ever want to change between them on a given task page. Anton wants to wait for the use cases. Susan agrees. - We discussed section heading styling differences. Anton does not see the need for the extra heading shading on the settings page. Given that this page shows only one section at a time, it seems reasonable you wouldn't need the styling that helps contiguous headings stand out. For the other pages that do have contiguous sections, Szymon will make sure there is a common sectional style sheet in use. (bug 374284). Szymon will make sure the user page uses this stylesheet, and I'll make sure that the section heading creation utils do the same. - Anton likes his styling better. At some point if/when settings gets multiple sections we should revisit this issue. Does he like it better now since it's single section or is he debating the aesthetics of the current section treatment? (If the latter we need Anton talking with Linda) - The question of how to navigate a page with lots of contiguous sections: we think that git status and git commit page might help us come to a good idea here. Git status uses "master/details" to select a change and then replace the diff viewer. Pros: easy to see what changed, Cons: not much space to look at the code. Git commit puts the diffs in contiguous sections. Easy to view the code, but difficult to see "at a glance" what changed. We think it's a good idea to work this issue in terms of git status usability(bug 349328) and git commit usability(bug 373143, bug 369057). We think the answer is in some kind of overview outline that takes you to the relevant section. Anton likes this idea if there is good animation to help you. Susan notes it will only work if the outline is pinned (at the top?) in some way, and thinks that there might be a mode where you would want to popup up the outline while deep in the content. - It's less clear how the repo page fits into all this, so we can look at it after we make some progress with git status/git commit - Anton will add links to places where he has seen and liked the outliner animation. The apple link I mentioned is http://store.apple.com/us/configure/MC968LL/A?select=select&product=MC968LL%2FA however I think it's an example of what "doesn't work" as far as not pinning the outline to the top. It also doesn't provide much animation. (In reply to comment #11) > Szymon will make sure there is a common sectional style > sheet in use. (bug 374284). Szymon will make sure the user page uses this > stylesheet, ... Done. Created attachment 212861 [details]
Pupup navigation when hover on a change
I thought that maybe the navigation should popup when you hover on a change. Then you could click on any change there and you would be taken to the selected change.
(In reply to comment #13) > Created attachment 212861 [details] > Pupup navigation when hover on a change > > I thought that maybe the navigation should popup when you hover on a change. > Then you could click on any change there and you would be taken to the selected > change. The hover idea is interesting but I'm not so sure about doing it when you hover on a change. I would expect to see more detail about that change when I hover on it rather than the list. Maybe a tool button for "show outline"? I think in usage it will typically be invoked by keybinding....(see discussion in bug 374400). I like the idea of "show outline" button. One comment about keybindings. I do not use them in web as often as in Eclipse SDK or other desktop apps. I would expect to have an easy way to navigate through changes using just a mouse or a touchscreen. (In reply to comment #11) > - Anton will add links to places where he has seen and liked the outliner > animation. Anton just pointed me at https://www.simple.com/ Here they use animation and a "current location" pointer to move you vertically through the sections. (And thankfully they pin it to the top so you don't lose your place.) Yup I like it. I think we should try the poping up navigation anyway, then add the navigation at the top, then ask people for feedback. I committed some widgets for scrolling like the website linked ( in my work for making an app to create plugins ). When I'm in the office next week, I'll try to make a demo. (In reply to comment #17) > Yup I like it. I think we should try the poping up navigation anyway, then add > the navigation at the top, then ask people for feedback. I think that simplebanking-like navigation would work well for both settings and git pages. Does it make sense to work on pop-up section navigation then? I would like to wait for widgets from Anton and use them on git pages. What do you think? Should this bug be assigned to you Susan or Anton? Just to note, that I made the scrolling container widgets for a wizard/plugin creation concept. I did think that the scrolling container would be an interesting paradigm for other sectional navigation too, so I worked to make the container reusable. Next week when I'm at the new lab, I'll put together some documentation. I did try to design this for re-use, as a set of dojo widgets, but we'll likely see areas that are not immediately perfect and will need to refine them. I wasn't sure that it would be something everyone wants - and I think we should review the prospect of using more widely first of all. It also took a bit of research and implementation to create the scrolling effect. My pointer to the banksimple website was not a direction - it was an idea for talking about more than anything else - but it was the inspiration for a more modern wizard concept for plugin creation. I've seen this kind of animation in a few places, and more than anything I was trying to come up with a concept for guiding a user through steps on a single web page. I'll document it more next week so we can see how it applies to this case if we're interested. I think the settings approach that we have with a split page is an approach that most users will be familiar with. I looked at settings in other web and mobile applications and tried my best to come up with something that would be quite familiar and would work well on desktop and tablet. So I'd be reluctant to see adoption of a scrolling container approach for settings. In addition settings could grow quite a bit, especially when we extend it to plugins - we wouldn't want that all on a single page. We've talked before about the Git page layout - where I think opinion seems to differ from user to user. Personally, I'd prefer a split page like settings for Git too. I'd prefer to view one section at a time. When I've aired that point of view before it hasn't met with any warmth. It seems important to have all the information on one page. I don't know why. I proposed the 'banksimple' scrolling container concept because it could offer the best of both worlds - a single page but with navigation, and also a modern twist. I would not propose it though for a page with too many sections ( more than 5 I'd say ). I also think we need to be careful if sections behave very differently from each other. It's confusing when they're on the same page, look similar but behave in different ways. (In reply to comment #20) > Should this bug be assigned to you Susan or Anton? I'd like to keep this bug for now. It's a really a tracking bug for all the things we can do to improve/make consistent navigation for these sectioned pages. I don't know how much I'll end up implementing, but it also affects our common page template, and we need to ensure we carry over ideas to other places like editor outliner. I also think it's critical that the API shape of these widgets is the same. I should be able to plug in an outline widget (or write new ones) to any sectional page, and they all know how to insert themselves, how to hide/show or scroll the sections, etc. I think it's very important that we all kind of get to shared understanding of the different circumstances that require different styles. I've always imagined several different "canned" styles based on the amount of data, etc. The simple.com example seems like a much slicker implementation of the Mac one I posted. Top level outline of scrolling sections (but pinning it rather than losing the outline, which I can't believe apple does). I think the top level navigation is good when you have a relatively short list of static sections of equal merit/use. Kind of like "browsing/learning" what the page can do. The current master/details pattern in the settings page is using a different visual, but I think for the same kind of scenario, where you are learning what you can change. To me, the main distinguishing feature of left hand side master/details is: - it is presumed that you aren't trying to reference several at once/the sections are not tightly coupled. - it is presumed that you don't need all the horizontal pixels. (I can't imagine using a left sidebar if I'm navigating git commits/compare views). I personally find the simple.com example a bit too much animation for my liking...it's a bit jumpy. But that might be because there's so much contrasting/dark content moving around. I wish it were smoother. But that is a minor point, and we know from the splitter animation that our users have different tolerances for this. We should try to stick with CSS transitions vs. dojo animation, so that it works consistently on platforms/tablets. But the idea of the list of sections, a current pointer, some animation to help you keep context...all good. But for git commit, git status, I don't see this necessarily working, or at least....we need to figure out the case where there are 15 sections. I don't think having a horizontally presented list up top helps to grok things like "7 deletions, 4 additions, etc." So here is where I picture a popup outliner being absolutely necessary to move around, and perhaps an ability to pin it somewhere. So I see us proceeding on several fronts here (see all the blocking bugs): - evolve the popup outliner for the data/code intensive navigation - evaluate how popup outlining can work with the editor - evolve alternate outlining for the static/small sectioned pages And my holy grail is that we'd have outline widgets that can be pointed at a div, discover the sections, and outline, whether that is content replacement (settings) or scrolling (simple, or a popup outliner). Even if the editor is necessarily a different implementation, we should style the outliner to belong with these other styles visually. They should seem like they are from the same family. So in my mind our next meeting could look at Szymon's popup, Anton's plugin stuff, other examples. One question I have...has anyone seen a good visual pattern with these characteristics? - navigates through a large set of sections - maximizes horizontal space - shows one at a time Right now I'm working in a git status with 53 changes. Imagining our mockup, there's no way I would expect to see all 53 compare widgets on the page. Instead I might want to see only one at a time, but I don't want a left sidebar because I need the horizontal space. Tech aside about my scrolling container. I did build it as custom dojo widget, but the animation used to scroll is not based on Dojo animation or css. I'm actually not sure it is possible to use css to scroll in this manner - I researched it. Instead I am programmatically setting the scroll top of the sections - otherwise, with css we can translate the page, but I think it isn't possible to set the scroll bar position with just css. The animation comes in by catching the scroll event and influencing the speed/motion. Also I wanted to use page anchors so that we could get to a section traditionally if we wished. In the case of building the plugin so far, I have only two sections. I dynamically added the second section as a step and called the widget's function to scroll animatedly to that step. I like the effect of it especially for a wizard type approach, because I think it helps as a visual guide, while also keeping the previous steps on the same page, and allowing the user the freedom to select a step independently from navigation, or just move the scrollbar if they prefer. I haven't entirely thought it all out - but I am encouraged about where it was going. I showed it to a few people in the lab, but it wasn't quite enough to make it for the last iteration cut. And it started to shake out more questions ( and neat possibilities ) for the plugin strategy than I think we're ready to answer. So it needs just a bit more flexibility for sites and some more thought for extension points as we progress. I was trying to solve the problem of making it easier to create plugins - rather than need to follow the wiki to create a plugin, you can have a simple working plugin to build on in a matter of seconds. Ultimately my motivation is to make it easy to add settings to plugins using this tool - I was also trying to achieve a user experience that would coral a user in a direction, whilst allowing them to see their data on a single page. As an aside I try to use as much raw css3/html5 in my work as I can at the moment. I use dojo widgets as a structure/discipline for creating my components. Perhaps what I'll do is try to host an independent sample of it, and write a blog post about what my hopes for it are. To be honest I was reluctant to share too much of it without experiencing it first in action - and in fact knowing that it could be built at all. Now I think that it would be a helpful thing for us to have, and the way that I'd like to solve the problem of allowing plugins to contribute settings - I could see the settings components play into the creation part. Wrote way more here than I planned to - this has sort of turned into a blog post. Mostly just wanted to write about the animation note in Susan's comment. (In reply to comment #25) > Wrote way more here than I planned to - this has sort of turned into a blog > post. Mostly just wanted to write about the animation note in Susan's comment. I was thinking about our old slideouts which used transitions on the left/top properties to get animated movement. I can't find my original reference on this, but this is similar...good site for seeing what can be done. http://css3.bradshawenterprises.com/ Not sure this applies to what you are doing, mainly I just wanted to point out that we should keep it in mind. moving out of 0.5M2 to 0.5 milestone until we have more specific buckets for future 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 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 |