Bugzilla – Full Text Bug Listing
| Summary: | Hard to see which part is "active" in an inactive stack | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> | ||||||||||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | P3 | CC: | emoffatt, gheorghe, Mike_Wilson, pwebster, remy.suen, stephan.herrmann | ||||||||||||||
| Version: | 4.1 | Keywords: | usability | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Bug Depends on: | |||||||||||||||||
| Bug Blocks: | 293481 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Dani Megert
Created attachment 175217 [details]
Screenshot
I always considered this a problem myself. I'm also not a big fan of those random vertical lines that get drawn when you hover over the tabs that are "behind" in a non-active stack. The original design calls for the vertical lines (that Remy doesn't like) to appear even when the stack is inactive. (For example, see mockup in http://wiki.eclipse.org/E4/CSS/Visual_Design). We just didn't get to this. This is also covered in bug 314157 comment 1, but as that bug needs to be cleaned up and separate issues spawned, we'll leave this particular issue open. Created attachment 175234 [details] A possibility? (Screenshot) (In reply to comment #2) > I always considered this a problem myself. +1 for both editors and view. Once upon a time when changing renderer code I got an interesting effect that seemed to look better to my eyes - see the attached screenshot. I would be the hovers were drawn as as tabs or something. Right now, with all the white, it's like the tabs are pointing up and down to no man's land. (In reply to comment #5) > I would be the hovers I would be _fine_if_ the hovers... Same problem with inactive view stacks: it's hard to see which one is the one which becomes active once the stack becomes active. See bug 325937 for the similar issue of detecting the active part in the active stack. This is still one of the bugs that makes me not use 4.1. Created attachment 194253 [details]
Screenshot depicting the state in question.
This is what it looks like now as of I20110428-0200.
(In reply to comment #9) > Created attachment 194253 [details] > Screenshot depicting the state in question. > > This is what it looks like now as of I20110428-0200. Didn't try in the build yet but based on the picture it looks a little bit better but the active part is still not easily detectable and the inactive ones now look sort of disabled. Created attachment 203214 [details]
Picture: Guess the active component
This picture is the latest 4.2 build and to me it looks like a hard puzzle to see which part is active.
For me this is still a blocker for using 4.2.
I assume this discussion has stalled because everybody believes that this is a matter of taste and thus no conclusion can be achieved any way. However, I strongly believe that this is much more a severe issue of usability. If ppl don't agree regarding usability, there's a simple remedy: user testing. Define simple tasks and measure the time ppl need to finish. Has any user testing been performed on the new default theme? How many milliseconds does it take to recognise the active part / tab? (In reply to comment #12) > I assume this discussion has stalled because everybody believes that this is a > matter of taste and thus no conclusion can be achieved any way. I don't think it's taste. It makes using 4.x harder than using 3.x. (In reply to comment #13) > (In reply to comment #12) > > I assume this discussion has stalled because everybody believes that this is a > > matter of taste and thus no conclusion can be achieved any way. > > I don't think it's taste. It makes using 4.x harder than using 3.x. My point exactly. I was just trying to find a reasons why this trivial blocker is not being addressed. I'd like to make the request a bit more specific: visual perception associates brightness with distance: bright colors signal near objects, darker colors signal distant objects. Thus anything that doesn't have the current focus MUST be marked with darker colors / shades of gray. A design that doesn't respect this rule is unprofessional. If everything is white its like all parts are yelling "I'm important". That's a bad message, actually makes me angry. (In reply to comment #12) > I assume this discussion has stalled because everybody believes that this is a > matter of taste and thus no conclusion can be achieved any way. > This was changed (included in M6) so that the active part of the inactive stack also include a gradient to help differentiate it. PW Fixed in M6 PW For me this is not fixed yet. Given the active part is more important, its tab should also be more eye-catching that inactive ones. Maybe it's just me, but the gray-shaded tabs jump much faster to my eyes than the white one. I would be willing to close this as being a matter of taste, but only if bug 355946 got fixed. Created attachment 213848 [details] Git Staging as inactive tab (In reply to comment #17) > For me this is not fixed yet. Given the active part is more important, its tab > should also be more eye-catching that inactive ones. Maybe it's just me, but > the gray-shaded tabs jump much faster to my eyes than the white one. In the inactive stack, git staging has the gray rendering, setting it apart from the rest of the pale white tabs. Am I misreading your preference for gray tabs over the white ones? PW (In reply to comment #18) > Created attachment 213848 [details] > Git Staging as inactive tab > > (In reply to comment #17) > > For me this is not fixed yet. Given the active part is more important, its tab > > should also be more eye-catching that inactive ones. Maybe it's just me, but > > the gray-shaded tabs jump much faster to my eyes than the white one. > > In the inactive stack, git staging has the gray rendering, setting it apart > from the rest of the pale white tabs. Am I misreading your preference for gray > tabs over the white ones? > > PW Ye, the grey tabs are set apart and I can at least now distinguish them from the active part, but they jump more to my eyes than the white (active) tab. For me the active tab must be the attracting thing in the workbench. Note, that I'm not voting to invert the logic, grey is not ideal to denote the active part. (In reply to comment #19) > > Ye, the grey tabs are set apart and I can at least now distinguish them from > the active part, but they jump more to my eyes than the white (active) tab. For > me the active tab must be the attracting thing in the workbench. Note, that I'm > not voting to invert the logic, grey is not ideal to denote the active part. active part in the active stack is covered by bug 325937 PW > active part in the active stack is covered by bug 325937
I know :-).
Let's clarify it with a picture. That picture will not have any stacked parts.
Created attachment 213883 [details]
Picture showing active tab not recognizable
Sorry Paul, your of course right. This bug is about the inactive case, and this is indeed OK now. Mea culpa! Verified in 4.2-I20120411-2034. |