What are some guidelines for displaying information to a user in a web-browser?
I am trying to determine some guidelines and best practices for displaying information to a user.
The exact case is a confirmation button: once it’s been pressed and the subject is confirmed the button is disabled (to prevent users from clicking it again). To be able to click this confirmation button there are some prerequisites that need to be fulfilled. If the prerequisites are not fulfilled, reasons to why the confirmation button is disabled should be shown.
Currently I have this information shown as a tooltip on the button. Is this a typical way of displaying such information?
Another thing that concerns me is the fact that the disabled state sends two different signals
one signal being “everything is in order”
the other signal being “something is wrong, but you need to hover me to find out what is wrong”.
Is this a design flaw in the GUI? Or is this information best displayed in another way (like the status-bar if this was WinForms?) Alternatively, an icon could be displayed above / below or near the button that signals information to be present.
I’m not really sure what the best-practices on this subject are in the world of web.
Regarding UI clues, you can find some good ideas related to form validation.
For instance, you can display explicitly the list those prerequisite with a symbol (red *) before each of them, stating that there are mandatory.
If the button is disabled, and all prerequisite informations have no more (*) in front of them, but rather a green check mark, that can help reinforce the message this button is not definitively inactive.
I would first show the information in some way other than a tool tip since this is somewhat critical information. Also, for the button, I would have two different UI clues. Obviously, the button should be disabled until it is ready to be clicked. Then when the button is clicked, you could have some image or something, with button now gone, stating that the request has been submitted, etc.
Display the message in a div highlighted with some other color and place it above your button.
Once your prerequisites are fulfilled , hide the div.
Related
I have this link:
The Best Page
The ajax-populated and -revealed element that exists within the current page is an "enhancement" and has aria-hidden="true". It would be preferable for screen-readers and assistive tech to follow the link's href to the subsequent static page, rather than triggering the click handler (especially since the element that it will acts on is already hidden, as previously mentioned).
Will this behavior already take place or do I need to add something?
When pressing enter on a link, it does the same as a click, and it's a very bad idea to intercept the enter key in order to do something different.
There are keyboard users, perfectly sighted, who aren't using screen reader. These users will experience an unexpected behavior.
Screen readers may choose to send directly a click event, rather than keyboard events, even though enter has been actually pressed. So idem in the opposite direction.
There may be other ways to activate a link, other than click or enter: spacebar, tap on touch screen, assistive techs to click by winking the eyes, etc. How it should behave in these cases ?
By the way, you can't do something different based on whether a screen reader is used or not, simply because you have no 100% reliable way to detect it.
The questions you should ask yourself are:
Why do you want a different behavior between click and enter ? or between screen reader and normal users ?
Are you trying to work around inaccessible content, or do you have two versions of the same content (an accessible and a unaccessible one) ? In that case, it would be much better to have a single content and make it accessible. Rare are the cases where it's really impossible, and experience shows that the two versions are eventually going to be out of sync, more quicker than you think.
I know that in Microsoft Windows, OK/Cancel buttons normally appear in this respective order. On the other hand, in Linux distros, I often saw Cancel/OK instead.
What about (Yes/No), (Yes/No/Cancel), (Add/Edit/Remove) and other common buttons?
Is there any standard placement order for these?
From the Microsoft Windows User Experience Interaction Guidelines:
Right-align commit buttons in a single row across the bottom of the
dialog box, but above the footnote area. Do this even if there is a
single commit button (such as OK).
Present the commit buttons in the following order:
OK/[Do it]/Yes
[Don't do it]/No
Cancel
Apply (if present)
Help (if present)
From the Apple Human Interface Guidelines:
The buttons at the bottom right of a dialog all dismiss the dialog. A
button that initiates an action is furthest to the right. This action
button confirms the alert message text. The Cancel button is to the
left of this button.
If there’s a third button for dismissing the dialog, it should go to
the left of the Cancel button. If the third button could result in
data loss—Don’t Save, for example—position it at least 24 pixels away
from the “safe” buttons (Cancel and Save, for example).
A button that affects the contents of the dialog itself, such as
Reset, should have its left edge aligned with the main dialog text or
if there is a Help button, 12 pixels to the right of it.
From the Java Look and Feel Design Guidelines:
If a dialog box has a default button, make it the first command button
in the group. For example, in languages that read from left to right,
the default button is the leftmost button.
Some of the above conflict with one another. You may also find that the advice conflicts with the vendors own applications. However, I would follow the guidelines for your operating system of choice and stick with them. At least that way you have consistancy within your own output and hopefully the vast majority of other apps on your platform.
Microsoft recommends one, Apple another.
Survey here shows 50/50 split:
http://measuringuserexperience.com/SubmitCancel/index.htm
This page has also links to official UI guidelines, which answer your question for some OSes.
I have the following set of controls.
Scenario 1:
If you select one of the first 3 radio buttons and click enter, focus will jump to the Passport Number text box. If the user selects "Other", the "Other, Please Specify" textbox is enabled and, for convenience, screen focus (the cursor is moved) to that textbox.
Scenario 2:
The "specify Other" text box is hidden until the user clicks on the Other Radio button. Upon doing so, the textbox is made visible and the cursor is placed in this textbox.
Which scenario do you feel is a better approach? Perhaps you have another variation? Please state your reasoning.
I would also appreciate it if you could make a generalized statement as to when hiding is better than disabling or vice versa, but I am also interested in this particular example.
Thanks.
Afetrthought: Perhaps, in the 2nd example, the "Please Specify" text would only appear after the user has selected the 'Other' radio button.
I find that changing the UI by hiding/showing controls can be quite jarring and confusing to the user. Go with option 1 and enable the textbox when the appropriate radio button is checked.
My initial impression is that number 1 is neater.
it allows for a clear design of the GUI (there wouldnt be inexplicable empty spaces in the input screen)
it makes the colon after the `(Please Specify)" request meaningful.
The only time I advocate hiding UI elements is when it improves the UI. If it's just 'different' rather than 'measurably better', don't do it.
Users may be put off by the fact that the "other" option seems to require that you specify something, yet the UI gives no clue that you can do that.
I would consider number 2... Hiding the text box will make it easier for the majority of people to run their eye down the page (each horizontal line creates a barrier for the eye). When someone selects 'other' a text box could fade in with the words 'please specify' in the box. The form will seem to respond to the users input.
When using icon images without text captions, should the icon represent the current state or the next state? For example I have a block of text that I want to minimize / maximize or I want to toggle showing All User Records or just My Records. I'm sure there are compelling arguments for either side and know that consistency is key, but what are the arguments related to good intuitive user design?
There is neither standardization nor general human tendency on this. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state.
I believe if you test a particular approach on your users, you'll get different results depending on what you ask. If you show them a control and ask them what state the app is in, they'll tend to read the icon as if it were indicating the state. If you show them a control and ask them to change the state (where in some cases the state is already changed), they'll read the icon as if it were the state to achieve. It's precisely because of this they invented toggling buttons.
If you're lucky, users use the icon primarily for either reading the state or setting the state, and not both. Then let the icon indicate whatever the users use it for.
If they indeed use it for both reading the state and setting the state, you're basically hosed, but there are a few things you can try to minimize hosehood:
Use text in addition to or instead of an icon. When labeled with a verb (e.g., "Connect"), the control indicates the state the user gets. When labeled with an adjective or noun (e.g., "On Line"), it implies the current state.
If your lib doesn't support toggling icons, then consider using a checkbox control, if that's allowed.
If your lib doesn't support checkboxes, then consider two controls, one to set each state, where the current state is disabled. Not too good for reading the current state, but there's some precedence for this in pulldown menus.
Fiddle with graphic design or placement to make it consistent with the meaning you've chosen. For example:
Command buttons are always labeled with the action they commit, so if your icon indicates the state the user gets, then give the icon a raised appearance like a command button. If the icon indicates the current state, then give it a flat appearance.
Toolbar controls usually show the state they bring about, so put the icon at the top of the window if indicates the state the user gets. In contrast, icons in the "work area" of the window indicate objects or attributes, so icons there should show the current state. Icons at the bottom of the window (in the status bar) should also show the current state.
This has not been truly standardized. Folder icons, for example, show open folders when they are open and closed folders when they are closed. Same for disclosure triangles, etc.
However, in other contexts, this is not always true. In a movie player, the "Play" arrow shows when the movie is not playing, and it shows the pause icon when it is playing. Probably the thing to do is use your best judgment, then poll your users. If a preponderance of the people you test are confused by your icon choices, switch them around. Then test them again and see if your initial test holds up. :)
If you are just going to have one button to toggle between two states, then the button should represent the next state, because that is the action that the button will take when clicked.
You gave the example of text that is minimized/maximized. Think of any expandable tree interface you ever see in Windows. A minimized tree has a [+] next to it, because clicking the button will expand the tree. And a maximized tree has a [-] next to it for the same reason.
You could also try to make a toggle that is highlighted or "pressed down" like mihi says, but that might be more confusing.
I prefer the "next state" approach (click plus to expand, click minus to collapse).
One reason is that this is the most widely used approach, so doing anything else would confuse users (and me as well).
Another reason is that the "next state" approach looks more inviting for the user to click.
May I present Zoom's mute button:
It shows the current state, as an icon, and the action that will occur when you push the button, as text. In other words, the icon on the button is the current state and the label on the button is the new state. The current state and the new state are opposites, so the button appears to contradict itself unless you read it very carefully.
(I hate that button.)
We are designing the UI for a new line of business application. We have no real constraints and are free to design the UI as we see fit. The UI will be done in WPF and targeted for Windows 7, Vista, and XP Pro users.
Many dialog boxes contain OK and Cancel buttons in their lower right corner. Do you feel it is necessary to have this Cancel button or is the red X in the upper right corner sufficient? We are discussing this as we have been noticing more UIs that do not have cancel buttons, only the red X.
Not only you should add it but also make sure ESC is mapped to it.
Present the two designs to the customer - one with the "Cancel" button, the other without. See what their thoughts are.
Better still present them as partially working prototypes and watch them as they use the dialogs. If you ask them to perform a set of tasks and see if they have trouble when asked to cancel an operation.
Having said that, my preference is to include a "Cancel" button for the reasons others have mentioned:
Accessibility (especially as Esc should be mapped to it).
Convention (users will be expecting it).
Include the Cancel button. The red X is VERY hard to tab to. ;)
Include it. This is very common in other user interfaces. Give the user the choice of which to use; making it for them might make them annoyed with your interface.
Users are used to having standard GUI layouts - otherwise they get confused. They also have different ways of using the standard interface. Some people only use the X, some people only use Cancel. People usually ignore the one they're not using, but get confused if their one isn't present. So be safe and keep them both in - it should only be a one-liner function for Cancek anyway.
Include it!
From a user interface perspective, not including a cancel button might leave some users feeling like they have no choice, which is certainly not the case. Imagine the following simple decision scenario:
Warning: All of the files in the selected folder will be deleted. This action cannot be undone. Are you sure you would like to continue?
How silly would an interface be if the only option was Ok? Also, as noted above, on many platforms the Escape key is mapped to Cancel. It's also probably worthwhile setting a default button so that pressing the Enter/Space key doesn't inadvertently perform the action that cannot be undone.
+1 on including it. If you don't include it now and then need some different functionality on Cancel to Close later on, your users will already be used to automatically closing.
Just like we have 'ESC' button on keyboard, we need 'Cancel' in dialogs.
A matter of usability :-)
Include it. And please also make sure that you make sure that hitting the Escape key does the same thing as the Cancel button.
Also, just because you're designing from scratch, please don't throw out all convention. Take a look at MSFT's UX Guidelines for dialog boxes.
The red button is really for 'Close' rather than 'Cancel'. 'Cancel' canceling a running task. Use a 'Close' button instead. And yes include the 'Close' if there is a reason for people to click on it. The red button is quite difficult to click when you really want to close something quickly.
If you have that kind of freedom, consider eliminating dialog boxes from your application entirely, especially ones with the typical "OK | CANCEL" paradigm. Dialog boxes disrupt the flow of action and generally should only be used for things which absolutely require the program to interrupt the user.
You'll notice how disruptive they are in the web environment -- e.g., Stack Overflow only uses them when it needs to be able to OVERRIDE your action, e.g., when you navigate away from an unsubmitted answer.