In invent.kde.org/plasma/kmenuedit/-/merge_requests/42, the undermentioned is depicted. Why was it decided that the new tabs expand to fill their available space?
I ask because it’s the first tab implementation I’ve seen do so, presumably because the older design should be easier to read due to the space between items never differing.
It’s “unified design language” bodge that favours garbage looking mobile fat fingers functionality over elegant desktop design.
the basic recipe is to take an established mature desktop app, remove the finely honed and refined UX elements and replace them with super sized boxes for fat fingers and bang, you have an unified app that’s ugly on all platforms and enjoyable to use on none.
notice how much more brain power is needed to parse that thing on the right.
now, the line under the tab headings disconnects the page from the tab.
the blue shading makes the selected tab more difficult to read, totally ignoring any considerations for the vision impaired.
the dark shading which previously mellowed the unselected tabs is now a giant rectangle of glaring white, buring the retinas and causing migraines. I’d bet it makes theming more of a pain in the butt too.
@jamesfrederik, that’s somewhat harsh, but you’ve made a good point that it’s an increase in touch target size, which is important.
Though, I agree with you that it probably shouldn’t be at the behest of readability, too. I don’t think I would have lamented the new tab design’s general padding increase, had them not expanded to fill their available area.
Likewise, you must be correct to some extent about readability, although whether that’s problematic in practice isn’t evident to me.
I think that your statement that using a white background for unselected tabs could feasibly cause migraines is misguided, however. Was it facetious?
Was it facetious?
I’ll concede to a mild over-egging of the pudding. But considering the recent Dolphin navigation bar update exchanged a very nice and considered design for a row of disparate white rectangles, I think the trend needs stomping on before KDE suffers the same “unification degradation” that has happened to Gnome over the last couple of years.
My general feeling is converting point and click designs to unified binaries is a cursed endeavour that can only lead to degraded experience for all users, whilst making development a misery for designers and developers. Phone designs don’t work well on tablets, and tablet designs are not good for laptops with touch.
@jamesfrederik, you’re not alone whatsoever, as I presume you’re aware of, despite the potentially apparent trend toward what you describe.
Luckily, Union and Kirigami should actually make the same controls being rendered differently for different devices possible.
Currently, modifying a control to render differently across platforms is in most circumstances infeasible, due to the amount of reimplementations in different Qt toolkits necessary for consistency.
I like the new navigation bar. It requires improvement as all does, but I despised the old one, actively. It had no border, and nothing communicated interactivity.
The immutable tab redesign sounds like it was motivated by finding controls that worked with frameless designs. At least on the face of it, I don’t see “let’s make this for mobile” anywhere in these discussions - more about making Breeze more consistent:
Helpful feedback about design decisions is good and necessary - constructive help implementing improvements is even better. Please be mindful of how we all, as members of the community, talk about the work that’s being done. A collaborative approach can work wonders.
As a general reminder, folks who are passionate about improving these aspects of KDE software should consider joining the Visual Design Group: Get Involved/design - KDE Community Wiki
