There are two different scenarios for sidebars explained in T11093: Improve Consistency across the Board. Just to be clear: This task is only about the second one, right? I would tend to think these can be viewed as separate issues for now (roughly quoting @niccolove):

1. Sidebars with many different pages that can be navigated through tabs - (we might want a separate task for this)
   
2. Sidebars used to help the user navigate through the pages of an application - (this task)
   

So talking about the second kind of sidebar:

Let's unify these to have the following characteristics:

• White background (with default breeze color scheme; obviously it should follow the color scheme
• Full width and height; top touches titlebar/tools area, bottom touches bottom window edge or status bar, left side touches left window edge, etc.
• Single-pixel vertical line separates the sidebar from the content area on the right
• When icons are large, they should be colorful

+1.
I would think we only need two different sidebar appearances for this: The one used in System Settings when there are many entries and D20908: Redesign QML applet configuration windows when there are few.

I would think we only need two different sidebar appearances for this: The one used in System Settings when there are many entries and D20908: RFC: Redesign QML applet configuration windows when there are few.

I will guess that sidebars should use the systemsettings-like list as sidebar vs configuration-like big icon above text when there are lots of elements. What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

In T11153#191838, @niccolove wrote:

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course),

Yes, in cases in which tabs can be replaced by sidebars without detriment we certainly should aim for unification to a single ui design. Aside from that I don't really have an opinion yet on when tabs should be used.

thus switching ksys to to big icon above text style, correct?

I think it could work for KSysGuard but I also think that it is in the awkward position of having exactly two tabs. This makes a sidebar seem a bit excessive with the benefits of having big icons for both pages (and unification).

In T11153#191838, @niccolove wrote:

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

Forget that, there's a much better definitions. Tabs should be used when the views are editable from the user, aka when the user can add, close and move tabs, such as in falkon, dolphin, etc. Also, tabs should be used when different views do not display different content: if you open multiple tabs on dolphin they are all about file viewing, while sidebars with big icons should be used when your are dividing different things in categories which should not change over time nor be user-editable.

In T11153#192966, @niccolove wrote:

In T11153#191838, @niccolove wrote:

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

Forget that, there's a much better definitions. Tabs should be used when the views are editable from the user, aka when the user can add, close and move tabs, such as in falkon, dolphin, etc. Also, tabs should be used when different views do not display different content: if you open multiple tabs on dolphin they are all about file viewing, while sidebars with big icons should be used when your are dividing different things in categories which should not change over time nor be user-editable.

If there was an agreement on that, those apps be changed:

• Heaptrack
• Kalgebra
• Kbruch
• SymbolEditor
• Digikam
• Kontact
• Ktorrent
• Elisa (list looks a bit different than other kirigami apps?)
• Kaffeine
• Skrooge
• Kwalletmanager

Not sure on Kmymoney (does not work on my machine), but it seems right.

That definition doesn't really make sense to me. In an app's main window, we use tabbed interfaces primarily as a method to quickly switch between multiple self-contained documents or views, not different parts of the app's own main view. It wouldn't make sense to use tabs for Elisa's sidebar view selector, or Dolphin's places panel location selector, or similar user interfaces.

In T11153#202270, @ngraham wrote:

That definition doesn't really make sense to me. In an app's main window, we use tabbed interfaces primarily as a method to quickly switch between multiple self-contained documents or views, not different parts of the app's own main view. It wouldn't make sense to use tabs for Elisa's sidebar view selector, or Dolphin's places panel location selector, or similar user interfaces.

Wait, that's not what I mean :-)
(NB: I'm ONLY talking to main view right now, so not the subtask)
Right now there are three main ways to navigate the application (plus the various inconsistencies):

• List

• Big Squares

• Tabs

I propose to define those use cases:

• List: use when you have to navigate a good number of views that would not fit in big squares at a normal application size (such as, system settings and its long list or discover)
• Big Squares: when there are top 5/6 elements, so it's possible to easily show big icons
• Tabs: ONLY use when navigating multiple views of the same concept (not different pages with different stuff and different buttons, but generally folders/webpages/documents) that are user-editable (so you can create new tabs or close them).

This means, for example, that KSysguard should switch from tabs to Big Squares on the left, which I think really makes sense and would be more consistent. I am not proposing to "use tabs for Elisa's sidebar view selector" (as I said, tabs have a very different use case). I was more thinking to use Big Squares for Elisa but, now that I look better at it, there are probably enough elements to justify the list, so mistake on my side there :-) (it looks different from SySe or Discover list though). Regarding "Dolphin's places panel location selector", I would never propose tabs for sure, and the list is absolutely fine, especially since it's a panel with a bit different behaviour than the tipical application navigator on the left.

Yeah, that all makes sense to me.

@niccolove KSysGuard has tabs because you can add and edit as many views as you want.

In T11153#202546, @ndavis wrote:

@niccolove KSysGuard has tabs because you can add and edit as many views as you want.

TIL! I'll remove it from the list :-)

I'm a bit unsure about many KCM using tabs though. Adding another list on the left would leave little space to the KCM since there are often already 2 lists on the left. On the other hand, you can open a single KCM and it doesn't make sense to have tabs there. Furthermore, Kirigami can hide lists if there is not enough horizontal space.

In order to navigate through views, Maui uses this interesting concept instead of a sidebar:

This should be easy to implement with toolbars even on non-kirigami applications by using toolbars on top and will provide a very consistent look once we have T10201. I think this should be preferred on applications when having few elements rather than using big icons on the left, which can be used in popups, as they would waste quite a lot of horizontal space in applications.

I always try to make a desktop and mobile mode for all my mock ups. I think these are kept consistent.

Those look really, really good.

https://phabricator.kde.org/F8668986

in the above mockups, the 1st sidebar will look cleaner without the separators IMO

Yes. I and Manuel have been debating separator lines and without them it looks cleaner indeed.

There has been a short discussion in the VDG group chat room about those separator lines in the past. If I remember correctly, the consensus was that they might benefit of some improvements. There were some people preferring to have them, I guess to have more clearly visual separation while maintaining low spacing between items (which is also requested by some of KDE's users).

The solutions included making the separators lighter, maybe also thinner and not touching the edges. @ngraham has started a merge request for this, but it turned out to be not easy to implement.

I would recommend to either make the line lighter or remove it completely. Not making it not touching the edges. I'm personally would be happy if we could embrace some 'modern' web design tricks of using different background colors and shadows to separate sections instead of lines. This would also make it easier to remove the frames from all the QWidgets :)

if our goal is going to be consistency, we need to also see where all we are currently using separators and also if we can come up with some kind of rule sets for implementing separators... like can be used for separating sections but not individual items in a list

In T11153#242842, @ognarb wrote:

I would recommend to either make the line lighter or remove it completely. Not making it not touching the edges. I'm personally would be happy if we could embrace some 'modern' web design tricks of using different background colors and shadows to separate sections instead of lines. This would also make it easier to remove the frames from all the QWidgets :)

That might also be a good solution. Currently I don't have a strong opinion about the touching edges thing. Regarding embracing web design: Personally that is also what I would favor. I think there are some good solutions in web design out there that also might look a bit more "modern". It might also offer the benefit of more consistency with other design elements.

This is obviously desirable, but I doubt that this is actually possible unless all of KDE's software switches to tree-views. I would love this, because it would provide one consistent method of navigation and would mean that all of KDE's software would reuse the same module for this important ability.

...However, I know that @ngraham dislikes trees anyway. Consequently, has anybody considered a sidebar kpart? I believe that if it were to support trees, miller columns, and dynamically removing the arrows of the tree-list when no sub-elements exist, the 1st option would support dolphin and kdevelop, the 2nd systemsettings5, and the 3rd everything else, whilst allowing the user to choose which they want.

Now, somebody might state that for an unknown reason this is impossible, because the sidebar formats are too inconsistent. I possess an existent solution to even that! Currently, instead of an application-launcher, I use a desktop-file that contains the URI of "applications:/", which I have dragged into my plasmashell taskbar. If you try this with dolphin, you shall notice that it spawns a tab/window that contains all of the application-groups that your application launcher would otherwise present. Consequently, if somehow the formats for the sidebars were truly too inconsistent to be interoperable, this level of abstraction would provide all of the necessary standardisation.

After all, it is why we possess the lovely launchers that we do today: thanks to KDE and freedesktop. KDE's kparts extend this wonderfulness to their own beautiful Qt applications, so I am certain that we should use this method!