alake,

My vote would be for either 'A' or 'D' - either way with the scrollbar like it is in 'E' (you're right it looks more obviously attached to the sidebar).

I think choosing between the two i'd go for 'A', it just feels more familiar having the content presented on a white background, the white pulls your attention to the content rather than the sidebar like it does a bit in 'D' but i'd be happy with either.

IMO 'B' & 'C' do look a bit odd & seem a bit 'change for changes sake'.

ken300 wrote:alake,
I think choosing between the two i'd go for 'A', it just feels more familiar having the content presented on a white background, the white pulls your attention to the content rather than the sidebar like it does a bit in 'D' but i'd be happy with either.

Yeah, I think "A" that would be my personal preference for most application designs as well. However, there may be some legitimate cases where "D" might be desirable or practical (like the current kcms). If the implementation allows for either approach then I think it'll be flexible enough to meet most application design needs.

A

There is a nice separation between icons & navigation and the content. A would also work nice with a status bar.

How should A look like like with scrallbars in the navigation AND content area. I'd prefer blue colour for the active area (content for example) and for the other areas grey or no visible scrallbars (navigation).

Ok here my take on the sidebars
Most of the time the sidebar interacts/corresponds to the "content" and not the window itself. So i visually think separating it from the window makes sens.
The sidebar color(g-h+) is something between the window color and the content color.

I think two colours would be enough. But I like the subitems view in H+.

I also ask my wife and she prefer A or D.

I tried making out my vision of what sidebars could be like and how we could interact with them more cleanly. I think that adding too many visual cues will certainly get in the way and I believe people are better at discovering functionalities in a window.



https://www.evernote.com/shard/s10/sh/8ddce900-07fa-4e9c-95da-2e09d99bf471/323280e67d3681ed493662657d814d91/deep/0/Sidebars_export.png

Personally i REALLY like the way the bottom item in each list becomes faded to show that the list is too long to be displayed and that you need to scroll to see the rest of it.

One thing though, if the scrollbars only appear when scrolling how do you start scrolling if your mouse hasn't got a scroll wheel? In Ubuntu they did their scrollbars so that they were invisible and only appeared when your mouse pointer was near where the scrollbar should have been (overlay scrollbars??) and i found them a pain.

If you were using a mouse with a scroll wheel then scrolling was fine (obviously) but if you were using a mouse without a scroll wheel (or a touchpad on a laptop, a wacom tablet or most trackballs) then it just made hovering near where the scrollbar should be, waiting for it to appear and then clicking and dragging it feel awkward - it felt a bit like 'well if you're going to try & use this without a scroll wheel then what do you expect'.

The most annoying bit was when you needed to resize a window by dragging its right edge. When you moved the mouse to the right edge of the window where the scrollbar would have been, the overlay scrollbars assumed that you wanted the scrollbar to pop up which then interfered with the resizing that you were trying to do.

Personally i'd prefer a scrollbar that appeared whenever the list being displayed was too long and stayed visible.

I agree with Ken300. Yes, hiding scrollbars makes things look nicer and mice without scroll wheels are rare nowadays, but laptops without multitouch are still common, and the "slide right edge to scroll" feature doesn't work that well on all touchpads and for all users. Therefore, while hidden scroll bars are great for touch UIs, I would not recommend them for pointer-based UIs.
Apple can do that because they can assume a multitouch pad or mouse to be present on all computers running OS X, but we cannot assume that.

Risking this to become off topic:
I hide scrollbars on inactive unhovered windows, show them faded on active or hovered windows, fade them to ~70% when hovering the attached scrollarea and to 100% when hovering the scrollbar itself.
Also they're only of highlight color when the attached scrollarea actually has the focus (text color otherwise)

Back on topic:
hiding scrollbars when they might be the only thing to provide visual separation between the module list and the actual config page may be contraproductive

Personally I preferred to mitigate frames so that they don't become nasty, yet separating.
Example shots (sorry for the blurry images)
http://sta.sh/214sa4cu29fe

luebking wrote:Risking this to become off topic:
I hide scrollbars on inactive unhovered windows, show them faded on active or hovered windows, fade them to ~70% when hovering the attached scrollarea and to 100% when hovering the scrollbar itself.
Also they're only of highlight color when the attached scrollarea actually has the focus (text color otherwise)

That sounds like a very good balance between cleanliness and discoverability!

I'm strongly in favour of anditosan's version of the scrollbar look. The big, blue scrollbar screams 'content' to me, and I think it makes the GUI extremely unbalanced and very confusing.

I don't have any strong opinions on whether to auto-hide the scrollbar or not, but it shouldn't be the same scrollbar used for content areas.

Summary of where we stand now (with current breeze code), regarding's andrews suggestion
By default: D and E
On option: (uncheck 'draw frame around side panels'), B and C

For A. It looks good, but the background and rendering of the right (contents) panel is the responsibility of the application, not the style (it could be any widget or any number of widgets). So on the style pov, A and B are equivalent.

For F:
- it is technically challenging (though doable) to have some scrolleareas with the scrollbar outside of the frame, and some scrollareas with the scrollbar inside.
- and I would not (IMHO) encourage it, for the sake of consistency
On the other hand, I am not sure we want to make all scrollareas with the scrollbar outside the frame. (Oxygen does this and some people will complain that it disconnects the scrollbar from the contents it actually scrolls).

Also:
- as on the screenshot, I have (hack) removed the use of bold fonts for such items. Honestly this should rather go inside the widget than in the style, but then I am not sure that such a patch will be accepted (will try, eventually, though)

- on a slightly related/slightly off-topic note, I'd like to suggest using only 1pixel for the focus (blue) frame that surround lists and editors instead of 2px as it is now, because I find it more crisp and less 'in your face' (in a way similar to avoiding using bold fonts).
Screenshots below
Before: http://wstaw.org/m/2014/09/22/plasma-desktopQq2055.png
After: http://wstaw.org/m/2014/09/22/plasma-desktopjw2055.png
This also affects side panels, when they have focus (as in some of the screenshots I posted in the past)

My understanding was that the 2px was used in the original QML to distinguish between focus and mouse-over, for which the same color is used. In the Style however (in fact in KColorScheme) you can use two colors for these two things, so that the need for 2px is less necessary.

Comments welcome.

Finally, concerning fading the scrollbars 'a la' Thomas' suggestions, I'll experience with it a bit. I personally like the idea although I also found it a little confusing/distracting last time I used Virtuality (but maybe this is just a question of getting used to it).

Best,

Hugo

Both options B, C, D and E look great with D and E being very similar to what we have nowadays in Oxygen. So all these options should definitely be present.
However, what is more important is to decide what should be the default look.
In my opinion the default for Breeze should be B and C to have a better distinction between Breeze and Oxygen. Breeze is a simpler and more clearer theme than Oxygen and having the white box around doesn't seem necessary unless there is the intention of having something that connects Breeze to the Oxygen theme.
The option should be there to check 'draw frame around side panels' to get D and E.

Then, just add to the design guidelines that content of applications should preferentially have the content area as white.

I also like more having the 1px than 2px surrounding lists and editors.

Please go for A, because the sidebars with the white backgrounds are no option for me since something visually sunken should not control the rest of the application, as often mentioned earlier this thread.
Apart from that A seems the most straight forward to implement, so I would appreciate if we would go for this.

kdeuserk wrote:Please go for A, because the sidebars with the white backgrounds are no option for me since something visually sunken should not control the rest of the application, as often mentioned earlier this thread.
Apart from that A seems the most straight forward to implement, so I would appreciate if we would go for this.

As said above: A = B on the style point of view, and is implemented.
Just: it is not the default.
For the default, I'd like to hear other's oppinion. (Andrew and I already made the comment that at least with some apps/panels, it results in side bars icons floating in the middle of nowhere)

Also note, technically there is nothing visually sunken in the current design, since there is no inner shadow (as opposed to oxygen). Just a white frame surrounded by a uniform (no gradient) grey pixel.