Tag Info

Hot answers tagged

103

As with everything: user test! Thankfully, usability hero Jakob Nielsen jumps to the rescue here in his Alertbox article about OK/Cancel buttons: Should the OK button come before or after the Cancel button? Following platform conventions is more important than suboptimizing an individual dialog box. Kostya was right on the mark in advising ...


67

The answer is in user interface guidelines for the system you use. For Windows Present the commit buttons in the following order: OK/[Do it]/Yes [Don't do it]/No Cancel Apply (if present) Help (if present) So Cancel is always on the right of OK button. For MacOS A button that initiates an action is furthest to the right. The ...


46

While Microsoft and Apple aren't explicit on this issue, Java Swing Look and Feel Guidelines explicitly state that the label/value should be to the right of the control for languages read left to right. The same applies to radio buttons. The ancient OSF Motif Style also explicitly says that the label is to the right of check boxes and radio buttons ...


32

I think this applies to this question too and answers it: (Spoiler: It doesn't matter.) In cases like this, it often doesn't matter what you do. Either choice has good arguments in its favor, and no choice is likely to cause usability catastrophes. It might save some users 0.1 seconds if you pick the "right" choice for certain circumstances, ...


28

Think "reading" metaphor. Westerners read left to right, our brains are conditioned to flow left to right. CANCEL is basically a step backwards (left) and OK/SUBMIT/YES/Etc., are a step forward (right).


21

When strictly speaking about alignment, there is no right answer other than to be consistent. However, the alignment of buttons is related to the positioning or logical order of the buttons. There are two general paradigms that can be applied to the positioning of buttons**. Reading Order - The first button encountered in reading order is primary (Ok) ...


21

Left-aligned buttons below the fields would provide a clear path to completion. Luke Wroblewski discusses clear path to completion in his book "Web Form Design" (PDF that contains some of the images). Here is an example from the book on how alignment can make the path of completion clearer: Similar to the example above, you may consider having "Next" ...


20

Do what fits in with your application and the target OS. However, as you point out, being consistent across your application is probably more important.


15

If you're going to bother localizing your interface, you might as well do it fully and respect the language or region's common practices. As you mention localization, I assume this means that you will change the placement of the currency symbol based on the locale setting of the user's interface, rather than the locale of the currency symbol used. Take ...


14

In this case, people are commenting about the restaurant rather than responding to comments about the restaurant. So there is no requirement for someone to read the existing comments before adding their own. In fact people would probably find it quite tedious to trawl through all the comments and would thus be less likely to add their own if the comments ...


13

I think this is one of those things where you should do what the user expects. What do they expect? Well that's sometimes the tricky thing to figure out. Eye movement studies have been done in excess to determine the best placement for the most important call-to-action buttons. And users often start in the upper-left hand corner. On the other hand, ...


13

Putting navigation on the left is very orthodox and through repetition it has become enshrined in the cannon of UI dogma. However that doesn't necessarily make it true. Jared Spool wrote on this subject: In my opinion, you shouldn’t care what I (or potentially most others on this list) like for navigation. I don’t even think you should care what your ...


11

For users whose language is read left to right, I would suggest putting the OK button to the left, since those users would ascribe greater importance to the first thing they see. This would allow this subset of users to complete their task as quickly as possible.


11

Luke Wroblewski wrote a book about web forms (Web Form Design: Filling in the Blanks) and he also covered some principles like: "Primary & Secondary Actions" ( http:// www.lukew.com/resources/articles/psactions.asp ), "Top, Right or Left Aligned Form Labels" ( http:// www.lukew.com/ff/entry.asp?504 ) or "path to completion", etc. (you can read also ...


11

If we ignore the possibility of right to left reading order (used in some languages), I believe that the label should always be on the right-hand side of the checkbox. In Windows, it is in fact impossible to put a label to the left of a checkbox, from a technical point of view. In any Windows software development environment a checkbox's label will be on ...


10

1. Is the standard for both Windows and OSX. You should go with this. Update: (Note that when clicking at extreme bottom of screen it will automatically display as 4,when at extreme right it will display as 3, and at extreme bottom right it displays as 2.) This seems to make sense, you right click, and are at the top left position of the list of options. ...


10

Because these instructions are supposed to be read after the user has tried and failed to interpret a field, not read first of all by every user. In the case of the Twitter examples, these texts often don't actually explain how to fill in the field, but rather how to make a decision. That is, they are supposed to be read only if a user struggles with a ...


10

Horizontal menu's don't readily support more than one level. Nesting or indentation are difficult to achieve, leading to many hard to use solutions widely documented in many articles and here on UX.SE. I'm no big fan of the Windows 8 website for instance, at the third level deep it just becomes weird. Web documents are usually laid out for scrolling ...


10

Android developer docs has a section titled Advertising Without Compromising User Experience Unfortunately, it only highlights the don't do's rather than the do's: When deciding where to place ads within your application, you should carefully consider user-experience. For example, you don’t want to fill the screen with multiple ads that will quite ...


9

For picking one or more choices, label to the right. This allows for easy visual scanning and let's the user's mouse/finger flow in a straight line: [ ] option 1 [ ] this is option 2 [ ] #3 If the label were to the left, it'd be a bit of a mess: option 1 [ ] this is option 2 [ ] #3 [ ] Furthermore, you will often have a 'group' label and while ...


8

Every answer so far is way too far fetched in my opinion. The answer is in fact very simple. In which direction do we turn the big wheel when we want to turn down the volume? And in which direction when we want to turn up the volume? Even when the UI does not have any indication such as on the great piece of hardware pictured above, nobody will have a ...


7

I'm surprised the article doesn't mention Fitts' Law, which states that the bigger the target is, the easier it is to acquire. (That's only half of the law, but it's the part that interests us here.) A menu bar may be considered infinitely large if it can be activated by clicking anywhere "above" the screen. You should read A Quiz Designed to Give You ...


7

Luke Wroblewski wrote about this issue in detail in his book Web Form Design. I really recommend reading his in-depth article: http://www.lukew.com/resources/articles/psactions.asp


7

I wouldn't worry about an artificial limit on the number of keyboard shortcuts. Such a limit assumes that a user is expected to learn the shortcuts first, and apply them only afterwards. In reality, users learn shortcuts as they go. And they will learn only the shortcuts that help them accelerate their workflow, while ignoring the ones that they would ...


7

My instant answer is the that checkbox should be on the left of the label, but before answering I wanted to validate the recommendations. Sadly Microsoft's, Sun's and IBM's UI guidelines aren't explicit in this regard (they tend to talk about when to use checkboxes over radio button etc.) but all their examples use the control-then-label convention. So I'd ...


7

If your error message display is dependent on a page submit (rather than in-line), I would very strongly advise against putting it at the bottom. A user's automatic reaction on seeing it next to the "submit" button will be that their errors have not yet been resolved and that there's therefore no point in clicking that button again. The most likely scenario ...


7

The error message should be wherever the user is most likely looking. If your technical design requires that the entire page reload to show the error, then chances are the user will be looking at the top, since that’s where users eyes naturally go as they see the page flash or clear. On the other hand, if you can do partial page refreshes (e.g., with AJAX), ...


6

Note, incidentally, that just trying to detect the user's OS doesn't necessarily help-- at least not if you detect the OS as being Linux. Because of the two most popular Linux desktops out there, KDE uses Windows button ordering, and GNOME desktop uses Mac button ordering.


6

The basic assumption is that you want to use the most readable option. One important aspect is scannability, how easy it is to get an overview without consciously considering each item in full. For this purpose it is relevant that checkboxes have a constant width. so if you align one side of the checkboxes vertically, the other side will also be aligned ...



Only top voted, non community-wiki answers of a minimum length are eligible