Mailinglist Archive: yast-devel (74 mails)

< Previous Next >
Re: [yast-devel] YaST Dialog Button Order in KDE
On Wednesday, August 31, 2011 05:39:01 AM Jiri Srain wrote:

My opinion is that the Wizard dialog is in some regards special (looking at
KDE applications, the text editor does not have OK/Cancel buttons in the
main dialog, but in pop-ups, where YaST is consistent; the main YaST
window is in this regard different than KDE windows which I can recall).

When a button has a specific meaning (and it does not really matter whether
the label is Next, OK or Finish), it should not move (I mean, when you
click Next, in the next dialog there should not be Back button at the same
location). From this perspective, we have only two options:


This is something that any browser user will find intuitive and that is 100%
of computer users.



Even though being a KDE user, I feel better about the first one (just a
personal opinion).

It is correct observation, not only a personal opinion.
Intuitive is what we are used to.

We read from left to right and having:
is the way we are used to. It is intuitive as it complies with other
How that works in RL written languages I can't even guess, as browser habits
could be strong enough to create new habit to treat online content in a
different way than all other written text.

An alternative may be to put the [Next] button to a different place than
[Finish]; when one of these is not present, its place in the dialog will be
empty (avoiding accidental clicking of button with different meaning). Not
sure how good idea it is, maybe others can comment.

Putting buttons as [Back][Next][Finish] where buttons keep their positions
across all wizard screens is improvement over having [Next] and [Finish] at
the same position. That order will prevent accidental click and problems in
some scenarios.

In almost all scenarios it would be better to have visual control where in the
configuration process we are, like in a system installer, where we have list
of items on the left side with indication of status; done (normal gray font),
current (bold black), pending (normal white).

What would be good to add is indication where action [Next] will jump. That
way would cover not only linear processes, where [Next] means also next item
in the list, but also those with conditional branching where next point in
configuration depends on results of answers on a current screen.

Problem with non linear processes is that you need history to know what is
done, which would be another piece to keep on the screen.

As a note to the KDE button-order: I fully agree that we should try to be
as consistent as possible with the environment which we want to integrate
with (in this case KDE), and it includes, among other, also the button
ordering and labeling. On the other hand, it does not mean that we should
take over every single convention; If there is a good reason to behave
differently, we should behave differently.

This is correct, but then what is a good reason. Who and what should drive

Ask developer that has to code solution and answer will be simple code.
Ask user and solution will be simple software usage.
Simple code and its usage are usually on the opposite sides of the street.

Everyone follows its own energy conservation; use less energy for the same
effect, so somewhere there must be a judge that will tell where is the middle
of the road; what is the best for majority.

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups