Use left-aligned thickened panel with IOTM populated with some apps by default
Needs RevisionPublic

Authored by ngraham on Wed, May 6, 11:44 PM.

Details

Summary

D27845 seems to have turned into a compromise that nobody is happy with, so I'd like to
propose a bold alternative to it that in my opinion is superior and fully implements the
proposal from T12441: put the default panel on the left, thicken it, and use an an IOTM
pre-populated with apps.

This yields all of the benefits brought up in T12441. Compared to D27845 it allows the
Panel can be made thicker and therefore display larger, prettier icons without feeling
wasteful of space. A thicker panel makes it more touch-friendly since the IOTM buttons
are larger and closer to the size of a finger. Finally, putting the panel on a vertical
edge is more suitable for typical modern widescreen displays where vertical space is more
scarce than horizontal space--especially for the ultra-widescreen displays with 21:9 and
32:9 aspect ratios.

It's a lot like the arrangement used by Ubuntu's Unity, or their current GNOME setup. I
have been using this arrangement for over two years and I think it's fantastic. I also
see a number of other KDE developers using this exact arrangement or a similar one so it
seems to be reasonably popular and battle-tested already.

If we move forward with this, we will need to fix https://bugs.kde.org/show_bug.cgi?id=387775
or work around it by disabling the default left touch screen edge or move it a different
edge. We would also want to consider relocating or disabling the current top-left
hotcorner, as it would slightly interfere with the Kickoff button. My recommendtation
would be to move it to the bottom-right corner, to preserve the ability to trigger an
action in every single screen corner without looking, which we have right now.

Test Plan

Diff Detail

Repository
R119 Plasma Desktop
Branch
left-panel-iotm-by-default (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 26486
Build 26504: arc lint + arc unit
ngraham created this revision.Wed, May 6, 11:44 PM
Restricted Application added a project: Plasma. · View Herald TranscriptWed, May 6, 11:44 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Wed, May 6, 11:44 PM

JFYI I know this kind of thing needs a lot of discussion so I'm not gonna rush to land it if people accept or offer +1s, so don't be shy about that. :)

filipf requested changes to this revision.Thu, May 7, 6:08 AM
filipf added a subscriber: filipf.

This is a major identity change better suited for Plasma 6. We've never had a vertical panel and are moreover defined by offering a layout familiar to Windows users.

Switching to it would also require user data. How many users use a vertical panel? Anecdotal evidence isn't enough, and we shouldn't be using developers as a sample for the whole userbase.

This revision now requires changes to proceed.Thu, May 7, 6:08 AM
broulik added a subscriber: broulik.Thu, May 7, 7:32 AM

Switching to it would also require user data. How many users use a vertical panel?

Yes, please!
It also imho depends on the usecase. On a laptop you're more likely to use a left vertical panel than on a giant desktop setup with multiple monitors.

filipf added a comment.Thu, May 7, 7:52 AM

I'd also be interested if KDE Promo has any insights here. It doesn't seem (?) like we advertise it too much, but I know reviews often praise Plasma for its familiarity for Windows users. Given our major competitor does the opposite and that the majority of our new users are going to be Windows converts (and keeping in mind that the less technologically able people tend to not like unfamiliarity), it seems like a good market share to grab. Changing the layout could mean a boost for other competitors such as Zorin. Thoughts?

This is a major identity change better suited for Plasma 6.

I disagree. I would like Plasma 6 to be a really uneventful release, not one that has a whole bunch of changes. There's going to be enough breakage as it is, let's do things that can be done now, now, instead of waiting for some nebulous "Plasma 6".

There's going to be enough breakage as it is, let's do things that can be done now, now, instead of waiting for some nebulous "Plasma 6".

That's a good argument when it comes to adding new code.
For flipping defaults it doesn't really apply. We support both styles of layout both now and will continue to do so in Plasma 6. There's no extra breakage potential.

I don't know if I agree that "Looks like Windows" is a part of Plasma's brand identity, or should be. If anything, we're like ancient Windows, with a Windows-95-style Task Manager that everyone else has since moved away from; even Windows itself has used an Icons-Only Task manager with a thickened panel for the past decade.

However if that's your thing, arguably this makes us more like Modern Windows (as does D27845) with the only difference being the screen edge of the panel. IMO this is really not rocket surgery for a person to figure out even if they've only ever used Windows 10 for their whole life. It's basically the exact same thing as the default Windows taskbar, just on a different screen edge.

I don't think it makes sense to wait for kuserfeedback metrics before touching this. For one, we don't have those metrics and collecting them will take years due to the bureaucracy around changing what kuserfeedback collects and rolling it out to a statistically significant share of our userbase. Once we have those metrics, how will they help us? I can guarantee you that they aren't going to show then 35% or more of our users already use a left edge panel with an IOTM on it. So we'll end up getting data showing that maybe 5% of users do and 80% of users haven't changed the default panel at all. Or alternatively the data might show than 3% already do and 70% have not changed the defaults at all. But how will this help us make a decision? It won't, really.

filipf added a comment.Thu, May 7, 2:08 PM

If user data would show low vertical panel usage, what are we really fixing and for who? Extrapolating from that and presuming that a fair share of them are content with the current default, why do we go against that? And if it's just a matter of not touching defaults, can you guarantee users are going to be equally content with a left panel as a default?

It seems to me this would boil down to touch usage. (My hunch is most people don't care too much about saving some vertical pixels). We're still only talking about a smaller subset of users, who we could equally benefit by finishing D27845, which is less risky.

If user data would show low vertical panel usage, what are we really fixing and for who? Extrapolating from that and presuming that a fair share of them are content with the current default, why do we go against that? And if it's just a matter of not touching defaults, can you guarantee users are going to be equally content with a left panel as a default?

Design of software and its default settings is hard because you have to anticipate people's needs, not ask them what they want (they don't know what they want or their ideas are bad) or reflect what they've already done (most people don't know what's possible).

Most users never change more than a small handful of default settings, if any. This is practically a universal constant that is borne out by data wherever it is collected. So the fraction of users who have changed a default setting is rarely a useful metric for determining whether the default setting is a good one or not, because even if something is a bad default, most people will still not have changed it. The only case where this kind of data can be useful if the it shows that, say, 50% of users have changed a default setting--this means that it's so catastrophically bad that the system managed to overcome the inability or disinterest of most people in changing default settings because it was so bad that they went out of their way to seek help in changing it. At that point changing the default setting in the next release becomes a pants-on-fire emergency to prevent all of these irritated people from leaving your platform (if they can) or trashing it in their communications with others (if they can't).

It seems to me this would boil down to touch usage. (My hunch is most people don't care too much about saving some vertical pixels). We're still only talking about a smaller subset of users, who we could equally benefit by finishing D27845, which is less risky.

Not sure I understand the risks involved in this patch. Can you explain?

+1 to this change.
Having the exact same panel and buttons on the left instead of at the bottom is a change that IMO even the most computer-illiterate Windows user should have no major trouble adapting to. Anyone else can change the panel position if they want to. In any case I can't picture a scenario in which it would stop someone from getting work done so I wouldn't be too worried about changing this default.

niccolove added a subscriber: niccolove.EditedSat, May 9, 10:47 AM

Generic +1 to the idea, but:

  • I would not go higher than 50 as panel width
  • The clock is too small, it probably needs a version where there's a new line between hour and minutes
  • We should check that all widgets work correctly in a vertical panel
  • Panel should stay in the same edge when screen is autorotated
ndavis added a subscriber: ndavis.EditedSun, May 10, 11:53 AM

I agree with the size chosen if we are doing a vertical panel since that size allows app icons to be 48px and makes the systray more compact by using 2 columns. However, I can't think of any way to justify this change in a way that I find satisfactory. There's no clear improvement over using a horizontal panel, just tradeoffs.

I agree with the size chosen if we are doing a vertical panel since that size allows app icons to be 48px and makes the systray more compact by using 2 columns. However, I can't think of any way to justify this change in a way that I find satisfactory. There's no clear improvement over using a horizontal panel, just tradeoffs.

The advantage of moving the panel to the left is that it's actually feasible to raise the thickness to the proposed size. With a horizontal panel, the proposed size is way too thick, especially for people with low resolution screens (since the panel height doesn't scale at all with anything). So the left panel is the only way to use this thickness by default IMO.

That's a good point. Is there a way to choose a different default layout based on info about the user's setup? I think choosing layouts based on the user's hardware may be necessary to get defaults that please most people while still being touch friendly in contexts where that is needed.

That's a good point. Is there a way to choose a different default layout based on info about the user's setup? I think choosing layouts based on the user's hardware may be necessary to get defaults that please most people while still being touch friendly in contexts where that is needed.

Yes, apparently there is. See https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/10/diffs

And on that subject, it seems like doing this for ultra-widescreen displays would have some benefit since there a horizontal panel is sort of absurd because it's like 90% empty space most of the time, and the things you want to click on are waaaaaay far away in the corners. See also T13156.

However I still think this makes sense as the default for everything. It's notably better for certain use cases (touchscreen, ultra widescreen display) and IMO no worse for others.

ngraham edited the summary of this revision. (Show Details)Tue, May 26, 2:33 PM