Bug 494578

For reference: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4640

Thanks for the context! This definitely is an improvement in this regard. Especially, I can relate to the first reply - I also use unusual fonts for better visibility. When one does so, it's not uncommon to notice that it can have an unexpected effect on the UI. It's nice that KDE considers these kind of things. 

The A/B screenshots do a very good job of illustrating the problem that it's introduced. The problem with label widths is mitigated by making each labelled element wider, and, to maintain similar overall density, shorter - but it also moves the label, and now the icons are separated by the width of the label, not by the height of the label. This last part is very significant.

In other words, there's a lot more space between the icons, *and* it's filled with the greatest of the label's dimensions. But in the vertical, there's a lot less space between the icons, *and* there's no label there at all. These matters compound, because it's less comfortable to search horizontally because scanning in that direction is blocked by text, while there's far less friction in the vertical because all of the padding and the label have been removed, and we're forced to 2 columns, so we end up scanning through two vertical lists.

This change has solved a real problem, but it's exacerbated an existing one. I'm scared to mention it, but... this one, specifically : https://bugs.kde.org/show_bug.cgi?id=384782 The inability for the user to order the list is the entire reason that the user is required to search the list, which is now far more difficult than before. It wouldn't matter so much, that it's more difficult to search the list, if the user rarely needed to search, because the list was ordered with relevant items in an accessible location. 

I'm trying to think of ways to resolve this, and that one seems most effective, but I'd like to hear how others might solve it!

I'm not sure I understand the actual problem you're experiencing here. You said:

> With the new design, the icons are reduced in size, and text takes the focus. This is visually cluttered in comparison
But I don't understand what that means.  How is it cluttered? The icons and labels are now arranged nice neat left-aligned columns. If anything, this new design should be substantially less cluttered than the old style where we center-aligned everything, with the result that both left and right edges looked ragged and didn't align to anything

Let's make sure there's an actual problem here before we start thinking of solutions and redesigns.

Created attachment 174825 [details]
kolourpaint ftw

(In reply to Nate Graham from comment #3)
>  How is it cluttered? 

In 1 word: density.

Sketch attached because words are hard for me to explain pictures :)

Objectively, to compare the two designs:

~2 * density in the vertical axis (green/blue lines in my sketch 1/2* length)
~1/2 * density in the horizontal axis (green/blue lines in my sketch 2* length)
N * obscured by non-icon elements (red lines in my sketch N* length)

Result: uniform grid became distinctly separated columns of doubled density, which is effectively two lists of doubled density. So now we have to search two things, and it's twice as hard to find stuff in either of them. 

> Let's make sure there's an actual problem here

I wasn't always sure. This isn't my first rodeo with UI changes, so I know that I should assume PEBKAC from the very start, and I see you wisely doing the same.

In spite of significant effort, that assumption just isn't holding. On the contrary, I've identified objectively measurable changes that are well known to have exactly this effect, and recognised that this is an exacerbation of the existing problem with the items being unordered and thus unpredictably located. In other words, those icons were always lost, and we can take out a ruler and measure why they're even more lost, now. But they were always lost. 

That's why I understand that this is not PEBKAC, the problem really exists, and especially, this is NOT a problem root-caused by the new UI layout. This is a problem with the content within it. The new UI just made that worse. If we could order the items in those columns, this problem wouldn't exist, because this problem is about the increased cost of searching for information, and if we sorted the list ourselves, we wouldn't be searching at all, because the location would be predetermined.

But it's not predetermined, so we do have to search, and lists are slower for that, than grids, so now that this grid has become a list, the searching is slower, as is normal for lists, and it's a problem because we need to do this search frequently.

I could get started on other consequences of the new geometry and how I was using a 6xN grid before this 2xN grid was enforced. That usage was a workaround for the sorting problem. It just so happened to give me the least-unpredictable movement with the apps I frequently open and close. The dimensions are not relevant, the relevant part is the reason that doesn't work any more - because the items are still horizontally sorted in spite of being vertically arranged. That also causes a behaviour where a single app unloading makes every subsequent entry swap from the left column to the right column. So, now we need to search horizontally, through vertical lists, which is unweildly enough, but on top of that, we have to jump over the entire length of the label to do it (previously, we had to jump the height). 

I could go on, but... I'm trying to not be difficult. I hope this much is enough to illustrate the nature of the problem.

I'm afraid neither that description nor the image comparison help me understand what the problem is here. :/

(In reply to Nate Graham from comment #6)
> I'm afraid neither that description nor the image comparison help me understand what the problem is here. :/

Dang I'm sorry. Words are hard.
One way I thought of to hopefully explain it: Have you ever lost something in a backpack, or maybe seen a lady try to find that certain object in the bottom of her big handbag? Maybe you've tried to find a Lego in a bucket? Most people have the same reaction: first, we rummage around in the bag, moving things apart from the other things. Eventually, we take the bag/bucket, and we empty it out on a big surface like a table or the floor. 

We spread out the lump of objects, so we can separate the objects, to isolate them, to identify them, so that we can identify the specific search target.

Putting visual empty space between the elements separates them not only geometrically, but logically. Conversely, taking away space joins them. 

Is this familiar at all? I feel like you know all this already, so I hope this doesn't come across as condescending. I'm not trying to tell you 'how to suck eggs' I'm just trying hard to explain a mental concept, and I find that's tricky in pure text. 

Actually, I just looked up and realised I'm typing in paragraphs. That! :D The difference between "geez that guy talks tooo much" and "unreadable wall of text" is largely just pressing enter occasionally.. nottomentionthespacebar :) 

I'll try moar pictures... I hope some part of this helps.

Created attachment 174829 [details]
The actual position of the icons

Created attachment 174830 [details]
How my brain sees them

Created attachment 174831 [details]
How they are geometrically grouped, objectively

Kinda explains how my brains sees them!

So in a nutshell:
- You navigate by looking at the icons, largely ignoring the text
- There's now less vertical spacing between icons, making them visually blend together a bit

Do I have it?

(In reply to Nate Graham from comment #11)
> So in a nutshell:
> - You navigate by looking at the icons, largely ignoring the text
> - There's now less vertical spacing between icons, making them visually
> blend together a bit
> 
> Do I have it?

Yes, this is the nuts and bolts of it :) Thanks for sticking with me there!!

I don't mean to nitpick about semantics, so if you weren't being specific about the terminology, feel free to ignore this - but it might explain the 'why' of my usage, and might influence any potential solution to this problem:
I do think it's important to recognise, we are not navigating here, we are searching. To navigate implies a known destination. If I knew that I needed to navigate to eg the third box in the right column, this layout would be awesome, as-is. But I need to first determine the location of the icon which looks like a speaker, to know that this time, it is in the left column, 4th box from the bottom... Of course, I could use the text for that job, but the icons are much faster.

Created attachment 174841 [details]
Current medium size

Created attachment 174842 [details]
Large size icons

Nate, maybe we could use bigger icons? Please don't ask me if it looks nice or if it's good from a UX perspective, I'm really bad at UI design :) I also haven't checked how it looks in German or in any other language with long texts

Large feels too big to me; the icons no longer have any semblance of being related to the size of the text labels' font. I'd experiment with increasing the vertical spacing between list items, or making them taller.

I put together a wireframe for a different kind of approach, have a look: https://invent.kde.org/teams/vdg/issues/-/issues/83

This one doesn't do away with vertical density, but it does do away with a second column so it turns out easy to navigate anyway. We're already buying into vertical lists everywhere from app launchers to System Settings, might as well double down on it.

I have been going, 'idea > type reply > realise idea won't work > delete reply > repeat > repeat > repeat', for three days straight. This one is a minefield of ways to fail. I may go crazy :D

I've had one idea that sticks: Frecency sort the list. It's not perfect, but it would be largely effective, and seems relatively (to my untrained eye, compared to total redesigns, or custom sorting like 384782) quick and easy, and portable to other designs (eg it would work here, and in Jakob's design). Any thoughts?

So far we haven't received any other negative feedback about this. Given the difficulty of coming up with anything better, I think at this point we have to accept the status quo for now. At least until we get more negative feedback from more users, or come up with anything obviously better.

(In reply to Nate Graham from comment #18)
> So far we haven't received any other negative feedback about this. Given the
> difficulty of coming up with anything better, I think at this point we have
> to accept the status quo for now. At least until we get more negative
> feedback from more users, or come up with anything obviously better.

I'd say that silently accepting the status quo is already the status on tray clutter, and probably at least part of the reason why I can't find any feedback about this change, negative or positive.

I am still seeing new threads about this, eg 10 days ago: https://old.reddit.com/r/kde/comments/1gt0i7s/suggestion_system_tray_groups_or_prehaps_multiple/ Mostly, users know it isn't getting fixed, suck it up, and suffer in silence. I've even seen suggestion that it is cluttered intentionally. Users are beyond giving up, and beyond bothering to report it. Obviously, I'm the type to speak up and try and improve stuff, and even I only bothered to mention it because I mistakenly assumed it was a bug.

Any way, after having discussed this at length, I feel like this bug report can be closed as a dupe of 384782. Status quo ftw. Sad. I tried!