Home_greyopenFATE - openSUSE feature tracking > #120373
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Unified Button Labels

Feature state

openSUSE-10.3
Rejected Information
openSUSE-11.0
Rejected Information
openSUSE-11.2
Rejected Information
openSUSE-11.3
Rejected Information

Description

Unify button labels

YaST currently uses several different button labels
for basically the same action, i.e. 'Ok', 'Accept',
and 'Finish'.

Decision: Only a single label per action should be used. Labels should be generally "OK" and "Cancel" for standard modules
and "Back", "Next", "Cancel" and "Finish" for wizards.

Documentation impact

check YaST descriptions in manuals and update screen shots

Discussion


icons/user_comment.png G. P. wrote: (12 years ago)

I'm moving this from "future" to 10.3. 10.2 will share much with SP1, so we cannot make this kind of change there. Adding Coolo and Edith for usability and YaST, respectively.

icons/user_comment.png T. R. wrote: (11 years ago)

This would also have documentation impact - we would have to check the YaST parts of the manuals and to redo a lot of screen shots, I guess.

icons/user_comment.png J. S. wrote: (10 years ago)

I don't think that we can solve this issue now, this must start being solved at the beginning of release cycle. Please, move to 11.0.

icons/user_comment.png S. K. wrote: (10 years ago)

the release cycle of 11.0 just started. Please kill Reject and Accept soonish.

If I may add here: please do not overuse Ok and Cancel, but rather use explicit actions where appliying.

"Do not delete 11 files? Ok/Cancel" is no-go, Delete/Cancel helps the user much more.

icons/user_comment.png J. S. wrote: (10 years ago)

I don't think that such cases can be handled a different way than on the per-case basis as bugreports.

icons/user_comment.png J. S. wrote: (10 years ago)

This is the list of files which contain the Accept or Reject words (probably not complete and probably some of the files are superfluous due to non-perfect regext). Please, get rid of as many as possible of them.

./add-on/src/add-on_proposal.ycp 
./add-on/src/inst_language_add-on.ycp
./apparmor/src/include/subdomain/reporting_archived_dialogs.ycp
./apparmor/src/include/subdomain/reporting_utils.ycp
./dhcp-server/src/dns-server-wizard.ycp
./fingerprint-reader/src/users_plugin_fingerprint_reader.ycp
./firewall/src/dialogs.ycp
./firewall/src/subdialogs.ycp
./ftp-server/src/complex.ycp
./ftp-server/src/dialogs.ycp
./inetd/src/dialogs.ycp
./installation/src/clients/inst_network_setup.ycp
./installation/src/clients/inst_proposal.ycp
./kdump/src/dialogs.ycp
./kerberos-client/src/dialogs.ycp
./ldap-client/src/LdapPopup.ycp
./ldap-client/src/ui.ycp
./live-installer/src/inst_live_simple_proposal.ycp
./ncurses-pkg/src/pkg_layout.ycp
./network/src/lan/complex.ycp
./nis-client/src/ui.ycp
./ntp-client/src/dialogs.ycp
./packager/doc/display_driver_popup.ycp
./packager/src/clients/inst_packages.ycp
./packager/src/clients/inst_productsources.ycp
./printer/src/common/dialogs.ycp
./registration/src/modules/Register.ycp
./restore/src/ui.ycp
./runlevel/src/runlevel_proposal.ycp
./samba-server/src/ldap-widget.ycp
./sound/sound/src/complex.ycp
./squid/src/complex.ycp
./storage/storage/src/inst_custom_part.ycp
./storage/storage/src/inst_prepdisk.ycp
./storage/storage/src/modules/StorageControllers.ycp
./system-update/src/system-update.ycp
./tune/hwinfo/src/newid.ycp
./tune/hwinfo/src/system_settings_dialogs.ycp
./update/src/clients/system_update.ycp
./update/src/clients/update.ycp
./update/src/include/rootpart.ycp
./users/src/dialogs.ycp
./users/src/users_plugin_ldap_all.ycp
./users/src/users_plugin_ldap_passwordpolicy.ycp
./users/src/users_plugin_ldap_shadowaccount.ycp
./users/src/users_plugin_quota.ycp
./yast2/library/modules/Label.ycp
./yast2/library/wizard/src/Wizard.ycp
./ycp-ui-bindings/examples/Wizard2.ycp

icons/user_comment.png M. S. wrote: (10 years ago)

Cool!

When we are already touching the navigation buttons maybe we can also try to work out Feature #303446 "Button order, positioning, labeling in YaST".

Button order should be according to the selected desktop. If another desktop then KDE or GNOME is selected either KDE or GNOME button order should be used.

The help button should be aligned left and the navigation buttons should be aligned right. Having too much space between the navigation buttons as we have no doesn't support grouping of buttons, which makes navigation difficult for the user.

Labeling should be as stated in this feature.

icons/user_comment.png L. S. wrote: (10 years ago)

Fixed in yast2-sound-2.16.4, yast2-tune-2.16.0 and in yast2-packager-2.16.27

icons/user_comment.png A. S. wrote: (10 years ago)

Is the decision documented in some style-guide?

icons/user_comment.png M. S. wrote: (10 years ago)

It is documented in http://en.opensuse.org/Image:Ysg.pdf
However this is just a first draft which needs to be approved (FATE: 303041)

icons/user_comment.png J. S. wrote: (10 years ago)

Done in yast2-ldap-client, yast2-fingerprint-reader, yast2-kerberos-client, yast2-nis-client, yast2-users

icons/user_comment.png J. U. wrote: (10 years ago)

Fixed in yast2-kdump-2.16.10, yast2-ftp-server-2.16.10 and in yast2-dhcp-server-2.16.7

icons/user_comment.png A. S. wrote: (10 years ago)

Done for storage.

icons/user_comment.png J. D. wrote: (10 years ago)

In case of registration the word "Reject" is used in context of a certificate. The user is asked to "Trust" or "Reject" the certificate.
Changing it to "Trust" and "No" or to change the question and switch to "Yes"/"No" is not quite intuitive I think. So I'd keep the word "Reject" for registration.
Btw: It will appear never in openSUSE but only during manual installation of a SLE product with registering agains a registration proxy aka. SMT.

icons/user_comment.png K. M. wrote: (10 years ago)

And what about installation proposals and installation clients? Are we suppose to substitute word "Accept" by something else there, too? If so, what is the suitable word in such case? Clearly not "Finish" (as it may let user think that it will finish the whole installation), is "OK" the right one then?

icons/user_comment.png M. S. wrote: (10 years ago)

What about using "Next"?

icons/user_comment.png J. S. wrote: (10 years ago)

Next sounds to me like another step in a workflow should follow, which is not this case. I personally prefer simple "OK".

icons/user_comment.png L. O. wrote: (10 years ago)

I personally still prefer "Accept" as it was in the previous YaST Style Guide TM. But "OK" might work too. "Next" is definitely _not_ the right way to go. We have to distinguish between the main workflow and the step-workflows.

icons/user_comment.png M. S. wrote: (10 years ago)

Why is it necessary to distinguish between main workflow and steps workflow? To the user it is just one installation process.
Just out of curiosity: why is accepting the proposal not considered just another step in the installation workflow? basic settings => accepting proposal => perform installation

icons/user_comment.png L. O. wrote: (10 years ago)

For accepting the installation proposal, I'd even rather use [Install] than anything else. [Accept] has been used there because it's so important decision that in needs emphasizing.

icons/user_comment.png J. S. wrote: (10 years ago)

Katarina's question was about the button e.g. in the partitioning dialog, not about the installation proposal as whole (if I understood it correctly).

icons/user_comment.png M. S. wrote: (10 years ago)

Sorry for the misunderstanding and thanks for the correction!

I suggest to use Cancel/OK as the only two buttons.
Reason: the dialogs are side-steps from main installation workflow.

I think now I got Lukas' comment about main worklfow and steps-workflow. :-)

icons/user_comment.png K. M. wrote: (10 years ago)

Right, the partitioning dialog (or networking, gfx card, whatever) that is launched from installation proposal. For example, in yast2-network, we use (in the very same dialog) "Finish" on running system, but "Accept" in installation. My q. was whether to substitute the installation client's "Accept" button with something more suitable.

icons/user_comment.png L. O. wrote: (10 years ago)

Changing Accept buttons to Install or Update (FATE #120373) >> yast2-installation-2.16.34

icons/user_comment.png L. O. wrote: (10 years ago)

Done in yast2-update-2.16.6

This is definitely going to break something as I can't check every change made...

icons/user_comment.png J. S. wrote: (10 years ago)

Most of the Accept/Reject buttons are gone now. Let's solve the remaining ones as bugs.

icons/user_comment.png M. L. wrote: (8 years ago)

Jiri, how much work needs to be done to clean it up by 100%?

icons/user_comment.png J. S. wrote: (8 years ago)

I cannot tell - it would mean to go through all dialogs. Therefore I suggest to fix those which we get as workreports and asking the community to report wrong labels when they find them.

icons/user_comment.png M. S. wrote: (9 years ago)

It is true that the Accept and Reject button labels are removed from the YaST modules.
However the button labels are far from being unified.
The biggest mess ist the crude mixture of "Cancel" and "Abort" labels and the second issue is the presentation of "Back" buttons which have the same functionality as "Cancel" but are shown in one screen configuration dialogs.
The attempt to solve these issues via bugzilla (https://bugzilla.novell.com/show_bug.cgi?id=478089 ) revealed that this issue seems to aquire some ressources.
One main reason for button labeling trouble seems to be that wizard.ycp is used in many places where the dialog is not a wizard, but where it is an overview.

To get a professional, consistent GUI and in order to reduce translation efforts and development of new YaST modules one possible solution might be the development of two different templates:

  • * wizard.ycp for wizards and installation and
  • * overview.ycp for edit/singe configuration/overview dialogs

Some possible layouts can be viewed at:

Buttons could use something like the button box widget developed sh or the button label widget developed by mzugec.

As mentioned in the bug, it will take some effort and ressources but I think, that the outcomes will be worth it!

icons/user_comment.png M. S. wrote: (9 years ago)

The status of button labels in YaST (based on openSUSE 11.1/SLE 11) can be found at:
http://en.opensuse.org/Media:Unified_buttons_yast.pdf

Some basic numbers:

  • * 10 different button combinations for overview dialogs
  • * 5 different button combinations for wizard dialogs
  • * 3 different button combinations for progress dialogs
Suggestions for a unification:
  • Use Cancel/OK for overview dialogs
  • Use Cancel/OK and Back/Cancel/Next (Back/Cancel/Finish) for wizards
  • Cancel for progress dialogs
Necessary work for unified buttons in overview dialogs
  • Cancel/OK is already used in 28 of 78 overview dialogs
  • 50 overview dialogs which need adjustments (4 x relabeling 2 buttons, 9 x relabeling 1 button, 12 x hide 1 button, 25 x hide 1 Button and relabeling 2 buttons)
Necessary work for unified buttons in wizard dialogs
  • Cancel/OK and Back/Cancel/Next are already used in 23 of 44 overview dialogs
  • 21 wizard dialogs which need adjustments (20 x relabeling 1 button, 1 x add “Cancel” button)
Necessary work for unified buttons in progress dialogs
  • Cancel is already used in 3 of 46 progress dialogs
  • All progress dialogs can be easily adjusted by hiding “Back” and “Next” buttons and relabel “Abort” into “Cancel” in progress.ycp
Final conclusions/questions
  • Unified button labels in wizards and progress dialogs can be achieved by just adjusting wizard.ycp and progress.ycp libraries
  • Overview dialogs need some manual adjustments as they base on wizards.ycp as well
  • Can adjustments be done by copying code from existing dialogs with OK/Cancel buttons (e.g. Date and Time)?
  • Does it make sense to invest into an overview.ycp dialog?

icons/user_comment.png R. B. wrote: (8 years ago)

This is long overdue and should be considered. If not in 11.3, it should be for 12.0.

Last change: 7 years ago
Voting
Score: 18
  • Negative: 1
  • Neutral: 1
  • Positive: 19
Tags
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint