hugo.pereira@free.fr wrote: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)

Hm, thanks for your answer, great work. Is a runtime switch possible between different implementations? What about adding a tiny frame or a separator to avaoid "side bars icons floating in the middle of nowhere"?

kdeuserk wrote:

hugo.pereira@free.fr wrote: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)

Hm, thanks for your answer, great work. Is a runtime switch possible between different implementations?

Yes: http://wstaw.org/m/2014/09/22/plasma-desktopjk4808.png
widget style -> configure -> draw frame around side panels

hugo.pereira@free.fr wrote: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

Perfect. Thanks Hugo. Is there an API option in the sidepanel widget for developers to turn on/off the frame? Just curious. That would allow the application layout designer/developer to decide show/hide the framing if sufficient visual alignment references exist elsewhere in the application layout (like in the "A" option).

- 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)

+1 for 1px

If there's the issue of things seeming to fly in nowhere why not add a 1px border with a slightly darker grey delimiting the Sidebar and included scrollbar but maintaining everything else the same in B and C? Or would that look too terrible?

One issue that I always had with the Oxygen sidebars is that the visual distinction makes it look like the sidebar and main content are completely independent, when in reality the selection in the sidebar determines the content of the main area.
Actually from a functional perspective, the sidebar is nothing other than a vertical tab bar. But whereas a tab bar goes to great lengths to create a visual connection with the content it controls, the sidebar does the exact opposite.
Therefore I'd like to see if we can come up with a design that visually connects the selected item in the sidebar with the content.

colomar wrote:One issue that I always had with the Oxygen sidebars is that the visual distinction makes it look like the sidebar and main content are completely independent, when in reality the selection in the sidebar determines the content of the main area.
Actually from a functional perspective, the sidebar is nothing other than a vertical tab bar. But whereas a tab bar goes to great lengths to create a visual connection with the content it controls, the sidebar does the exact opposite.
Therefore I'd like to see if we can come up with a design that visually connects the selected item in the sidebar with the content.

+1, I couldn't have summed it up better.

ugly sketch, bad paddings, colors and there're artifacts
http://sta.sh/01wp9pb2zmvx

Edit: at some point somebody has to tell me how to add an image to this stupid board (no: [img] tags don't work)

luebking wrote:ugly sketch, bad paddings, colors and there're artifacts
http://sta.sh/01wp9pb2zmvx

Edit: at some point somebody has to tell me how to add an image to this stupid board (no: [img] tags don't work)

I really like the idea, only thing that feels weird is the scrollbar, I think instead of the scrollbar the idea I presented would fit really nice here:

kdeuserk wrote:My idea (though this would require the widget to be changed, since I find that scroll-bar inappropriate):



SVG: https://drive.google.com/uc?export=down ... 2ZIZGEyMmc

The icons of the sidebar are from Cantata (http://kde-apps.org/content/show.php/Ca ... ent=147733) by Craig Drummond.

With this approach you could also implement the tab bar without any problems, though like I said, I am not sure about the tab bar.

The solution for getting rid of horizontal scrollbars could be similar.

If you do not like that approach, I would try to leave the scroll-bar, see the above screenshot how it's currently done in dolphin and I am okay with it.

Luebking & kdeuserk,

I like the idea of luebking's mockup but with the scrollbars replaced by the ones that kdeuserk suggested (the up & down arrows) - two suggestions:

In luebking's mockup the tab 'Frames' is selected - what about changing the appearance of the unselected items in the sidebar? Reducing the opacity, greying out or something to make the unselected ones less obvious and stop them drawing your eye away from the selected tab, at the moment the blue triangular icon in the sidebar for 'Buttons' dominates the sidebar a bit and draws your eye to it.

What about fading (a graduated fade) the icons at the end of the list if there's more icons than will fit in one page? In luebking's mockup if there were more icons down below the 'Benchmark' icon at the bottom of the sidebar it could be faded out so it's bottom edge is transparent to make it obvious to the user that there are more icons down there - although the appearance of the downward pointing arrows in kdeuserk's mockups do that too - I'd just find having the bottom icon a bit faded a bit more obvious!

colomar wrote:One issue that I always had with the Oxygen sidebars is that the visual distinction makes it look like the sidebar and main content are completely independent, when in reality the selection in the sidebar determines the content of the main area.
Actually from a functional perspective, the sidebar is nothing other than a vertical tab bar. But whereas a tab bar goes to great lengths to create a visual connection with the content it controls, the sidebar does the exact opposite.
Therefore I'd like to see if we can come up with a design that visually connects the selected item in the sidebar with the content.

So I went off to try to come up with visuals that might address this concern. As I was working on it, a few thoughts emerged. Get out your boxing gloves colomar!

If we look at the widgets as widgets, I tend to agree that they might look disconnected. But I'm wondering if that's really how the user looks at the UI when they're using it. It seems to me that the user engages with the UI for a conscious purpose, and interprets elements of the UI with that purpose in mind. With a purpose in mind, I'm thinking it's often quite difficult for the user to conclude that the selection on the sidebar list could mean anything other than what it actually does: the selection that corresponds to what's visible in content area. It doesn't come for free though. It does require something visual to make the connection. Here are some examples that seem effective after surveying a few apps:

• Repeat the name of the list selection in a content-header element
• If the list selection is icon-only, repeat it somewhere in a content-header element
• Make the content visuals communicate a distinct message corresponding to the list selection. e.g. Make music albums look visually distinct from songs.

I also took some time to review how other platforms have dealt with this over time. I noticed a trend, especially in tablet apps. Many tablet apps did something like this to connect list selection to content:


It looks great and actually works quite well. I also noticed though that many app designs as slowly going back to a simple list without the "pointer". And I think it's partly because, in the context of the application, the user with a purpose understands that the list with a selection provides no intrinsic information value by itself. It has to be connected to something else in the interface for it to have value that is relevant to the user's purpose. I think the functional co-location of the content next to the list will almost always lead a user with a purpose to cognitively connect the two elements. As a bonus, their interaction with the UI immediately confirms that.

All that to say, I'm not sure an overt visual connection is necessary even if it might be aesthetically desirable. So I'll be the old-fogey stick in the mud and suggest that maybe ye olde boring list isn't so bad after all.

alake wrote:All that to say, I'm not sure an overt visual connection is necessary even if it might be aesthetically desirable. So I'll be the old-fogey stick in the mud and suggest that maybe ye olde boring list isn't so bad after all.

I don't say it's a big usability problem. Of course it does work. It just looks slightly weird. And this quite long forum thread tells me that I'm not the only one who thinks that way.
Since when do we keep things the way they are visually with the argument that they are "not so bad after all"?
The sidebar is used in many places in Plasma and KDE applications and I never found it looking good. There have already been quite a few quite interesting ideas been produced in this thread, and I already find some better looking than what we have now. They might still have some kinks to iron out, but that's what we're here for, right?

Could it be that the sidebar would feel more at home if all the icons on it weren't colour icons?

Colour draws a lot of attention, but if we switch to just greyscale, like we've done for other parts of Plasma, wouldn't that help to emphasise that the sidebar is part of the UI, and not the content?

colomar wrote:

alake wrote:All that to say, I'm not sure an overt visual connection is necessary even if it might be aesthetically desirable. So I'll be the old-fogey stick in the mud and suggest that maybe ye olde boring list isn't so bad after all.

I don't say it's a big usability problem. Of course it does work. It just looks slightly weird. And this quite long forum thread tells me that I'm not the only one who thinks that way.
Since when do we keep things the way they are visually with the argument that they are "not so bad after all"?
The sidebar is used in many places in Plasma and KDE applications and I never found it looking good. There have already been quite a few quite interesting ideas been produced in this thread, and I already find some better looking than what we have now. They might still have some kinks to iron out, but that's what we're here for, right?

Ok as primarily a visual enhancement that's totally fair I think .

Hi all,

Some screenshots from my latest experiments, based on (part) of the feedback recieved here

1. http://wstaw.org/m/2014/09/24/plasma-desktopcN2032.png
When the sidepanel actually has focus

2. http://wstaw.org/m/2014/09/24/plasma-desktopOj2032.png
When it doesn't has focus (i.e. the focus is on the right side, where something is edited

3. http://wstaw.org/m/2014/09/24/plasma-desktopiG2032.png
With scrollbar
Obviously the scrollbar breaks the connection between the selected item and the vertical line, but since scrollbars are (should be) a corner case, I don't think it matters too much. Also, the fact that it is left of the vertical line, makes it clear that you will scroll the side panel.

... now these screenshots are from some of my 'own' configuration panel.
In KDE land it looks a little bit different, due to margins, toolbars, etc:

4. http://wstaw.org/m/2014/09/24/plasma-desktoptn2032.png

Comments/suggestions are welcome,

Hugo

I think the focused and unfocused sidebars look beautiful.

But I'm still highl skeptical of the scrollbar: I think it is a bad idea to use the same kind of scrollbars on the sidebar and on the content. It looks immediately cluttered and confusing.