https://bugs.kde.org/show_bug.cgi?id=494578

--- Comment #5 from pallaswept <pallasw...@proton.me> ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to