Bugzilla – Full Text Bug Listing
| Summary: | [client] is the breadcrumb too small/subtle? | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, libingw, malgorzata.tomczyk, mamacdon, Mike_Wilson, simon_kaegi, Szymon.Brandys |
| Version: | 0.2 | Flags: | simon_kaegi:
review+
|
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 339558 | ||
|
Description
Susan McCourt
I have often wondered if the breadcrumb text should be blue to indicate a link. Grey on grey text doesn't shout out "click me" the way the blue text in the file names in the navigator does. Related issue. We use the breadcrumb area to show page title. In some pages, we have a navigable breadcrumb even though the page contents are not navigable/scoped. Clicking won't really change the results. So our decision here needs to include two situations: - page has a title and possibly current location/object title, but the results aren't navigable. I think we need a convention for showing this. I suggest we use "page title - object". Examples include: Git Status - orion-client Site - MySite - page has a current location and is navigable up and down the path. Use a breadcrumb. Each segment in the path (except the last/current location) should cause a change in the results shown on the page, or navigation to a new page. If we are using the same area to show both, I think we need visuals to make the dynamic breadcrumb stand out. (In reply to comment #1) > I have often wondered if the breadcrumb text should be blue to indicate a link. > Grey on grey text doesn't shout out "click me" the way the blue text in the > file names in the navigator does. The reason we didn't do this at first was because there are other links in the header (the main navigation links such as "Navigator," "Sites" etc.) and we were trying to be consistent. Having every link be blue was too cluttery, so we went with "subtle underline on hover." But I agree it's time to revisit the consistency issue. In the breadcrumb case, we need to make it clear when that area is actually providing function vs. just showing a page title. After browsing around and looking at breadcrumbs on different pages, I realize we are all over the map. Probably want to standardize on: Page Title - path/if/navigable/foo Page Title - foo Examples: Git Status - orion-client Site - MySite Git Log - orion-client/bundles/org.eclipse.orion.client.core Navigator - user/orion-client/bundles/org.eclipse.orion.client.core There are several things being changed here: - we get rid of "Orion" in front of any page name - the page title is never used as a link to anything. - If there is a root not represented by the path name (like the navigator case, where we want to get to the workspace) we need to represent it in the path somehow. For navigator, we could use the user's name to represent the link to the workspace. In addition to standardizing on usage, I will have Linda look at the visuals to address the visibility problems for: - current location, showing scope of page - making it clear when the path is navigable (In reply to comment #0) > For example we could make the breadcrumb larger +1 from me for using a larger font - typically, we have enough space both vertically and horizontally. changes are in the branch remotes/origin/newVisualLayout Added Simon for review. There are several issues to consider for RC1. 1 - do we think this looks better (knowing it needs polish) I think so. - better idea of where you are, especially in git pages where branch names and stuff needed to be more prominent - lighter feeling - not so cramped - linkable things are now shown in blue to better indicate what is active on the header 2 - should we push into RC1? I think so. We can polish fonts/spacing/margins during RC2 but this contains some changes that affect every page and most breadcrumb implementations: - getting rid of most hard coded page margins - new layout of the banner HTML - splitting the "pageTitle/breadcrumb" concept, which was really inconsistent, into two separate things: "pageTitle" = unchanging title like "Navigator" or "Git Status" "location" = where I am, what I'm editing. It might have an optional path. 3 - does it affect the performance? I would be surprised, as it's mostly a shifting around of dom elements that were already there, you never know. Simon is going to review the code and performance and get others to look at it as far as liking it. Assuming we release this, I'll have a number of visual bugs to close for RC1 and will still have some remaining polish items for RC2 where we go back and really improve the margins/spacing/etc. Boris & McQ - fyi, I first implemented the mockup with the dedicated status area and it just felt like such a waste of space given that most of the time it's empty. So I went back to putting the status line up in the header. Boris suggested a bordered/popup look for status..we could even implement this by inserting into the header but just bordering it such that it looks like its own thing. We might also (in RC2) put the editor's "Line 1 Col 4" continuous status somewhere else as it is different than the other stuff we put in the status area. Simon, after you pulled I realized that some of the corresponding js changes (which fix up the breadcrumb, etc.) had not been pushed. Please pull the branch again before reviewing. simon pushed this |