Background
One of the things that Linux ‘used’ to suffer from was many extremely minor but, sadly highly exotic user eXperience UX issues, which back before AI assistance, it was that ‘apparently’ exotic nature that made them extremely painful and costly, and could render Linux (desktop) an unworkable exercise of death by 1,000 papercuts.
I’m been using Linux on and off for a long time for target needs, mostly headless, but only comparatively recently for my daily driver desktop/GUI needs.
I just experienced one such issue which thanks to an AI query was comparatively quick to fix but even so, it had me baffled longer than it should have frankly, given the feature in play.
The experience was as follows:
- suddenly out of the blue I notice my view was mildly zoomed in and cropped, following the focus (it was only mild so perhaps I had not noticed for a minute or so)
- I fat fingered some guesses at hotkeys combinations which might work for zoom… no good.
- I tried mashing Esc… no good.
- I checked task manager for zoom application… nothing.
- I tried scanning for utility popup window to close… nothing.
- I tried session log off, log on (NB: my Session Restore is set to manually saved) … no good.
- I tried restarting, and logging back in… no good. Given my session restore config, this is now looking bizarre, ‘exotic’.
- I tried logging as other users, their sessions are not affected, so again given the restart and my session restore behaviour, this is looking bizarre.
Now I just decide to AI it (the modern equivalent of googling it frankly) which renders it an easy fix ‘Meta’ + ‘0’.
Problem
The problem is that the ‘exact’ origin of the behaviour is not clear, is this Zoom? Is this Magnify? It persists over restart so is this a default behaviour somewhere even much deeper when there is some mismatch when its time for plane assignment? Then you login as another user and it vanished, is this some exotic interplay among any of the above?
Its turns out that the cause very much simpler than that, so perhaps it should ‘appear’ that simple.
Suggestion
Zoom should be kept simple so that it is robust and reliable. However,
- should some attempt should be made to notify of what function has just been engaged, its name, and how to leave it?
(even if that is not as reliable, and relies on a separate utility, maybe even that is trapping the hotkeys and not even the function itself)
- This could be a KNotification, freedesktop notification?
- This could be a notice window, that isn’t even attached to the Zoom function, although at that point it could have its own functionality as a cockpit utility to control zoom.
- It may be important, as an accessibility feature, that Zoom should persist to be activated in its last state upon session login, however, should such persistence behaviour be a configurable option in itself, that is off by default?
like i said in a different thread, the default effect should be magnify instead of zoom.
then when users are confronted with a magnifier lens on their screen it will be rather obvious what is going on.
Very possibly skyfishgoo. I’m not a UX design expert, so the solutions aren’t my forte, however as a user I’m able to experience a problem. It sounds like I’m not the only who this has attracted the notice of.
I found your thread , issue 46304 (I don’t have link post privileges. A bit of a nuisance as its a discuss_kde_org public URL.)
It seems that while the nature of the occurrence of the OPs issue ‘may’ have been different (and it may not), that among their issues what that they too were not clear what ‘function’ was occuring, and it does again sound only after the fact, like ‘zoom’.
(I would also add that like that OPs issue I could have sworn I tired other valid zoom hotkey combos and they didn’t work, as they are pretty obvious, but just as likely my combos were invalid.)
Yeah. I think what I’m saying is that by way of options, there is probably some low hanging fruit in terms of an improvement that could be made to the ‘experience’, including possibly leverage Magnifier.
I’m not familiar with magnifier though, KMag? Just looking, my Fedora 43 does not out of the box have magnifier. So if magnifier is a whole separate greater endeavour, I would empathise that where it might be needed for some for accessibility reasons, then the built in option being default probably should remain mandatory.
Something should be possible though.
it should.
settings > desktop effects
it’s listed right there next to zoom, but zoom is the default (they are mutually exclusive).
I can understand the frustration not knowing what function you accidentally activated hitting some shortcut. But showing that every time would not be practicable for users like me who use it on a regular basis. If at all, there could be some kind of “learning mode”, which, when turned on does that or does it on the first time some function is invoked.
But frankly, I think kde plasma’s real strength is that you can configure almost anything you’d want related to shortcuts (and other things), i.e. you can re-assign them or turn them off completely. As you correctly noticed, nowadays you just AI and describe the phenomenon you see and the platform/desktop environment you use and get an answer within seconds. If you give a good prompt, you’ll usually get a good answer, e.g. where/how can I configure this behavior etc.
1 Like
@ line
Indeed. But I think these matters are better viewed as a prioritising of degrees of constraint, and I’d argue the greatest degree of constraint is on the least expert user.
You mention just put a prompt together, but my elderly mom bless her does a fantastic job of using Windows 11. I think it should be the ambition of KDE for it be just as usable. This scenario… would have made it impossible for her to easily even launch a browser to get at an AI prompt. Then we have the fat that AI remains to put it politely ‘rubbish in’ > ‘rubbish out’, so I’d argue an assumption that prompt is ‘easy’ might be too naive.
So we establish that the current behaviour is the greatest constraint, so we then ask is this solvable and how much would it cost.
Well your particular problem I’d argue is easily solvable (at least in terms of design, I can’t comment on implimnetation). For example, an option to display notification or whatever, which is on by default, which users such as you would go straight in and turn off.
Now, the last constraint is dev time and priority, which does become the ultimately overriding constraint, but that comes after you have put the need in the queue for consideration.
In short, I think it is a hazard to be too quick to view software design/goals as a zero sum game.
Edit
…does a fantastic job of using Windows 11. I think it should be the ambition of KDE for it be just as usable…
To be clear, I’m not suggesting KDE needs to be ‘like’ Windows 11. Treating software goals as a zero sum game is exactly what appears to have happened there, and its lead to an OS that suits no-one all at the same time. They’ve constrained them selves to marketing’s wishes, and whatever off-the-books stakeholders have lead to the current horrorscape of attestation.
Ahh yes, ‘Magnify region’. Could be, but the behavior of that is far enough removed from that of zoom, that I couldn’t even begin to think I had enough expertise in user’s needs to have an opinion on whether that could replace Zoom as the default. That’s not to say you don’t have enough expertise. I can only defer to other.
i’m not suggesting magnify region… we already have that as an alternative to zoom (tho i think if magnify region were the default, there would be far less confusion about what was just accidentally activated).
i’m just talking about a semi transparent icon overlay on the screen somewhere while zoom is anything but zero… this overlay could of course be turned off in settings, but it would be on by default.
Yes, the “magnify as default” would solve that particular problem.
FWIW I saw a plasma-welcome package on Tumbleweed, that, according to the description, introduces users to the DE and stuff like configurability. That said, I haven’t tested it and don’t know whether it keeps what it advertises.
most of those “tutorial” or walk thrus are wasted effort as few ppl take the time and even if they did, they are usually so overwhelmed with everything that subtleties like this would blow right past them.
the KDE approach is to utilize discoverability and to empower curiosity.
so presenting a “new” thing on the screen when you use something for the first time encourages ppl to explore it, and in doing so, they can often find a way to turn it off if it’s bothersome.
I second skyfish.
No one should rely on a tutorial to make something as foundational as a GUI usable, no one should expect a tutorial to be used. I’ve never had to follow that kind of a tutorial and I’m not about about to start. You can argue I should, but the reality is I’m not, and if anything that applies even more to less experienced users. Less experienced users would either need a bigger tutorial to spell everything out (which will overload and drown them) or will expect them to have context knowledge, which they won’t have. Pop up guides are for ‘new bells and whistles’ for those who are interested.
KDE is fantastic and does ‘not’ resemble the following, but many GUI user experiences have forgotten the one problem above all others that they were first invented to solve, which is to replace the secret language of CLI with a “user friendly” experience. (Trendy, elegant, stylish mono-color icons that are indistinguishable from one another other; the elimination of plainly descriptive menu headings to make dev localisation easier at cost to the user experience; menu levels that are so needlessly deep that you end up resorting to keyboard short-cuts; arcane languages of secret control gestures that would make an Illuminati sorcerer feel inept).
It is no exaggeration to say that CLI is literally easier to use and explore than many GUIs, and that is not just a matter of power features, and its not that CLI is significantly easier to use than it used to be because its not. Many GUIs have just forgotten their main reason to exist.
If a GUI needs a tutorial, or a guide, or a manual, it has very probably already failed, to a limited extent the same is the case for keyboard short-cuts. Manuals are mostly excusable for CLI only. Manuals should be there to inform you the feature exists in the first place, and recipes for how to use them, from there the GUI should want to make finding and leverageing the feature “self explanatory”
Now granted, the above does not withstand that all things have limits, and that includes what can and cannot be made easy to some ultimate degree, and oversimplification of a problem is dangerous as a limiting dead end.
“User Friendly” is an expression that used be part of common daily parlance, I don’t hear it used ever any more in the wider computing world, and I think it very much warrants being resurrected.