Mailinglist Archive: yast-devel (108 mails)

< Previous Next >
Re: [yast-devel] YaST module for journalctl


no longer strictly related to "YaST module for journalctl"
but an example how UI/UX development can fail:

On Nov 20 19:00 Christian Boltz wrote (excerpt):
Am Donnerstag, 20. November 2014 schrieb Johannes Meixner:
In the initial phase of my YaST Printer redesign I also played
with the idea of "inline buttons" directly in meaningful text as in

I think you can imagine what an UI or UX expert told me...


Of course with that fat button design it looks horrible but what
I actually had in mind were links in HTML - i.e. "clickable text"
but I guess that idea was much too disruptive at that time ;-)

I think the bigger problem is that you had 5 lines with buttons - that
and having the buttons at different places in each line is what makes
your draft a shock therapy for UX experts ;-)

It does not matter how a very first proposal looks.

But it does matter what the intention behind a proposal is.

From my point of view the biggest problem was that the idea behind
my initial proposal was ignored so that it was "simply rejected"
and the 'good old design' of plain buttons without meaningful text
in the dialogs was enforced where all meaningful text is banished
into help texts regardless that users usually do not read them.

The consequence of not providing meaningful information directly
in the dialogs are severe UI/UX issues when users misunderstand
a dialog and click wrong buttons leading to wrong results.


I had
"Configure [Printing via Network] if a desired remote printer is not shown"
but what our users actually got is a simplified until uselessness dialog
that results bugs like
that require a YaST Printer re-redesign
See in particular
and compare that with my very first initial proposal idea
Guess what: It was a UI/UX "expert" who spent some effort to convince me
it is better to mix up local and remote queues and their matching buttons.

I had
"If no sutiable driver is shown, try [More Drivers] ..."
but it was simplified until uselessness that results confused users
and various bug reports so that in the end [More Drivers]/[Find More]
was re-added (but of couse without any additional meaningful text)
Guess what: It was again a UI/UX "expert" who convinced me
the [More Drivers] is not needed.

I do not say that my initial proposals had been already perfect.

But I do say that simply removing stuff that smells like an issue
instead of a real effort to develop a real solution for the issue
results dialogs that may look nicer/cleaner and even work in
simple cases but with insufficient usefulness in non-trivial cases.

If there had been efforts to develop real solutions for the issues,
progress would have happened (of course not an ultimate solution
in the first step but step by step into the right direction).

I almost never got real constructive contribution from UI/UX "experts".
Almost all I got was negative like what not to do, what looks not nice,
what to remove, what those "experts" do not like and so on ad nauseam.

The only thing what they seem to really like are automatisms that
"do the right thing automatically" but when such automatisms exist,
there is no need for a user dialog and no need for UI/UX "experts".

I would not mind if it was not me who has to fix all the mess that
useless UI/UX "experts" introduce. If I had only to fix my own mess and
those UI/UX "experts" fix their own mess, everything would be perfect.

Kind Regards
Johannes Meixner
SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >