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:
[Back][Next] [Back][Finish]
This is something that any browser user will find intuitive and that is 100% of computer users.
or
[Finish][Back] [Next][Back]
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: [Back][Next] is the way we are used to. It is intuitive as it complies with other experience. 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 decision. 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. -- Regards, Rajko -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org