Windows and OS X have always bumped heads on this, but what is the general concensus on whether a Save button or Cancel button goes first in a web application?
[Save] [Cancel]
or
[Cancel] [Save]
Note: I have these buttons at the top of the form flush to the right.
Follow the principle of least astonishment: do it the Windows way ([Save] [Cancel]) unless you have reason to believe that Mac users make up a greater portion of your user base.
The key here is that we are talking "web" usability. To that point, I think it is pretty clear that the principal of least astonishment referenced in the accepted answer would suggest that right is the forward action (save) and left is the backwards action (cancel), and not what the accepted answer suggests.
The web browser is the user interface web users are most accustomed to, and 15+ years of web browsing has made it pretty clear that the back button is to the left of the forward button. It also jives with the left to right based languages that the web was initially developed for. The right is where you are going, the left is where you have been.
Even in general computer vernacular, a forward slash, /, leans right while a back slash, \, leans left.
The windows UI is the outlier here, and I think it is a poor decision to base your UI design on Microsoft's precedence.
I might point out that your top right corner positioning of the two buttons is non-standard, but I don't think it bears on the ordering of the buttons themselves.
Instinctively I always put the Save button as the rightmost element.
I think there are other things to consider. Primarily whether a Cancel button is actually needed, or whether another element (such as a breadcrumb trail pointing to the previous page) might be more appropriate.
Edit: http://www.lukew.com/resources/articles/web_forms.html - The section 'Primary and Secondary Actions' shows how visual weighting can be used to good effect as well.
For all the heated arguments this issue can generate, it doesn’t seem to make much difference in actual human performance. The advantages and disadvantages of each work out to a wash. Users appear equally likely to expect Cancel on either the left or right in web forms. There appears to be a bias to favor Cancel on the left if the buttons are widely separated, but you don’t want to do that since putting the Execute button the far right is associated with slow responses and high error rates on web forms.
I’d say the most important thing is to be internally consistent in you app, and be sure Cancel is always labeled “Cancel” (not, say, “Return” like I saw in one web app). Otherwise, put the buttons next to each other and near the last field the user will look at (which is probably not in the upper right of the form).
And don’t worry about it too much.
It's probably not a big difference either way, as long as it is clear what the buttons do.
My personal vote would be to have save on the left, as that is what people do the most often, and people read left-to-right.
Also, I would also put some space between the buttons, to make sure users don't accidently click one when they are trying to click the other.
Why do you need a cancel button at all?
On a web form, the user can almost always cancel through some other action. Putting "Cancel" near "Save" is creating a situation where the user has a good chance of firing the ejection seat when all they want to do is save.
I generally put the button which will cause the most actions to occur farthest away from the center. If your buttons are top-right, my order would be [Cancel][Save]
Familiarity is often more important than being objectively correct, since things that are unfamiliar are often, by default, less usable.
People use their Windows PC or their Mac more than your app or website. So if I were in your shoes, I'd pick the order which you think will be familiar to the users you care most about. If it's a mostly-mac audience, do it the mac way. If mostly PC audience, do it the PC way.
On a normal form, Save should be under the form fields. Cancel should be to the left or right of Save, but not too close to avoid tragic mistakes. Luke W's Web Application Form Design page has some illuminating diagrams.
Your form is unusual in that you want the buttons to be at the top. In this case I'd need to know what the page looks like and how it will be used. But since you're already breaking any flow between form fields and Save, I suspect Save should be on the right to support the natural left-to-right path.
(Windows and Mac have differing standards for button placement on dialog boxes, and they both have the buttons at the bottom. These standards do not apply to web pages.)
Related
TIL that screen reader users rarely use tabs for navigating web pages and instead use specific keyboard shortcuts from their screen reader software (e.g. CTRL + OPTION + Arrow Keys in VoiceOver). This would mean that optimizing for tabbable navigation does not always make sense.
However I've seen some web pages adding tabindex="-1" to their headline elements or for elements that are not directly viewable due to overflow: scroll.
So my question would be: When does it make sense to optimize for tab navigation and when doesn't it?
E.g. in our current use case we've created a questionnaire that basically shows a question (h2 element) that can be answered with 2-5 answers (button elements). Clicking the answer will lead to a new page with the next question. When activating VoiceOver it seems like a good idea to have the question element set to tabindex="-1" and auto-focussed when the question is opened. But the learning above seems to challenge this a bit.
Thanks for your help!
So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.
Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.
Hopefully that clears that bit up for you.
As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.
I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.
Notice I say the <input> and not the heading.
What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.
You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.
That way someone has the choice to stop the auto focus if they wish.
Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.
Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.
So focus the input if this is a multi page form, not the heading level 1.
Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.
Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.
So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.
Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.
You are making a confusion between screen reader user and keyboard user.
One doesn't necessarily implies the other.
People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.
People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface.
They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape).
A joystick in some form can be such a device.
Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.
I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.
As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.
UX point: does page reload fully or dynamically change?
This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.
From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.
Now, I will use screen reader tools to read the question (be it TTS or braille output).
Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.
If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.
Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.
Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.
What are pros and cons of this technique (see Softfolio for an example). Two things I personally thought of are as follows:
Impossible to tell someone where an item of interest is located (like, you probably won't say "324-th row, second column")
Broken navigation when you return back to an infinitely scrolled page.
What else can you think of? And what do you personally think of this approach in general. Would you use this in you projects?
I think it is "neat" but requires more visual clues as to what is going on... and in many circumstances isn't what the user wants.
If I want to get to "page 7 of the results" I don't want to move to the end of the page 6 times to trigger the reload of additional data. (e.g. in an alphabetical list... If I want "M"'s, don't make me wade through a,b,c,d,e,f,g,h,i,j,k,l
Ensure there is a visual clue of more loading if you do use this (when I press CTRL+END I expect to be at the bottom)
I often find I'm still waiting on these types of pages because the "loading" of the next set of results waits until I'm very near the bottom... thus I often get there before the data is loaded/ready/rendered
(pro) I think this kind of thing would be good for certain scenarios... e.g. when I scroll down my Twitter list... I don't want a "more" button, just load it...
I would prefer better "search" filtering over fancy ajax-infinite scroll results. If I can filter down to 25 results that actually match what I want, then I won't need to scroll!
When results are served randomly, it's a great idea. People are asking, "How do I get back to where I was?". Well, you don't. The results are random, so when you return to page six, you won't be seeing what you did last time.
If you think about it, paging Sortfolio would be a bad idea, because it would imply to its users that the order of its listings are fixed, as many of you have made the mistake of assuming.
For those asking, "How can I return to a result I liked?", well, you click the 'Save to my favorites' link. As for, "How can I share a result with a friend?", you click on the result and grab its URL. Kinda simple really.
I'm not saying this infinity-scrolling business is the way to do it, I'm just saying that some of you guys are unfairly discrediting Sortfolio for usability problems which the site—given its random nature—really needn't concern itself with.
Personally I HATE that example. It makes the site much less usable than if the results were paged.
You're right too, when you hit back, you will have to page by scrolling down again, and while page down works it doesnt work well - I cant remember how many page downs i pressed to get to the site, secondly, what if the ordering changes the number of scrolls would differ anyway - I know paging would too, however its much easier to scan a few pages than keep scrolling.
Lastly, even though I am a developer I scrolled down, and the first few times I actually thought maybe if i leave it long enough it will download all the images/samples...then scrolled down and again the same thing happened AAAAAARG!
I would NEVER use this approach in projects.
I wouldn't use infinite scroll on search results. But it's really nice for casual browsing, or in a random output situation such as psychological test where it's important that items not show up in a constant order. Something like a market preference survey skews towards early choices, so randomizing the order of options is essential.
Where it gets frustrating is when the user leaves a page via a link and then wants to come back. For a browsing situation, I'd probably address that with overlays rather than linking away.
I personally find it gimicky and quite annoying. It diverges from standard navigation techniques that users are used to (such as pagination) and breaks navigating back, which is very annoying (you can't get back to a result without starting again). On top of that it doesn't conform to accessibility guidelines as it is totally reliant on JavaScript to work (which goes against the "progressive enhancement" theory of the modern web). This also has SEO implications as I doubt content "beyond the fold" would be indexed, unless it was linked to directly from elsewhere.
I can see a few limited circumstances where this might be OK, such as a very long text page, but personally I doubt I'd use it in the current form. Kind of reminds me of those Flash sites that are all style and no substance and end up annoying the user rather than enhancing their experience.
I agree this is a mess. If there is a finite list, there should be some kind of pagination mechanism that lets you know where you are.
Alternatively, or in addition, add a filtering mechanism so you can weed out the stuff you don't want to see.
SO provides a handy example of how to do it right.
Actually, It doesn't matter whether we (designers/developers) like it or not. The only thing that matters is the users perception of this. If the user finds it useful, well, then the solution is OK. If the user gets confused and can't accomplish the primary task, then redesign...
I think the cons are that when you hit the back button you lose your place on the page. Could be annoying especially if you are deep within a page.
Etsy discovered the hard way that infinite scroll isn't good for conversions. Recommend reading this article.
Does anyone know the correct place of the cancel button in a form?
Does it have to be on the left of the submit button or on the right?
This article by Jeff may be of interest http://www.codinghorror.com/blog/2010/03/the-opposite-of-fitts-law.html
It's not specific to the Cancel button but still a good read.
Most people read left to right, so it's normal to have OK on the left. At least, this is the Windows convention. OS X does it the other way around, I think.
Jakob Nielsen is widely considered an expert on usability and user interface design. He gives his opinion in this article:
"OK–Cancel or Cancel–OK?".
The summary of his answer is: It's actually not an important UI issue, but if you are designing for Windows, put OK first; on Mac, put OK last; on the web, put OK first unless the majority of your users are not using Windows (but see also this article on Reset and Cancel Buttons for the web).
We are designing a web site and have run into some UI challenges that would be neatly solved with a tabbed interface. Users will interact with different elements of the site (there are some basic view/edit/copy/paste functions available) and having only one object in one tab visible at a time simplifies things quite a bit.
We are, of course, completely comfortable with tabbed interfaces but what about novice users? I've searched the web for guidance and I haven't found anything definitive. Do you have experience presenting a tabbed interface to novice users and did they have trouble with it? Or, have we reached the point where everyone is comfortable with tabs and we can use them without reservation?
Usability is important-- more so for this project than most. If naive users are confused by a tabbed interface it just won't work and we'll have to find another way.
In his excellent book "Don't Make Me Think" (Sensible.com), Steve Krug discusses the benefits of using a tabbed interface:
They're self evident
They're hard to miss
They're slick
They suggest a physical space
He goes on to describe the keys to successful tabs as demonstrated by Amazon.com:
They were drawn correctly
They were color coded
There was a tab selected when you enter the site.
Obviously, he provides details to each of these bullet items in the book (I won't plagerize him here). The book is definitely worth a look if you want guidelines for creating web sites for novices and experts alike.
Tabs are becoming common place enough that I wouldn't worry about using them, as long as you implement them correctly. Make sure that you make the active tab visually distinct from the other tabs.
Also, try to create the tabs using progressive enhancement so that the content is still there with JavaScript disabled. There are two main ways of doing this:
Load every tab but the first using
AJAX. The tabs themselves should be
links to the content that the AJAX
fetches.
Keep all of your information on the
page, but hide it using JavaScript.
When you cycle through the tabs,
they are populated from the hidden
parts of the page.
A design resource you might find helpful is the YUI Design Pattern Library and their section on tabs.
I think as long as the tabs are visible as such it's understandable by the user. I have seen websites where they present a vertical bar with links that act like tabs but it's not immediately visible to the user and found that very confusing.
I would have to disagree with those are in favor of tabs. In a design test we did for a fairly high-traffic website (over 1mil uniques at the time), we found that tabs have not been used. Tabs were clearly marked, located to the right of the main content area. Based on that experience I would suggest either finding an alternative or, as staticscan suggested run usability tests to figure out which ones work.
Don't think you can decide a-priori what is usable and what isn't. Do usability testing
"It takes only five users to uncover 80 percent of high-level usability problems" Jakob Nielsen
Google usability testing and start learning. It's not hard.
I tend to agree with lothar and ricebowl - people seem pretty familiar with it these days. The most important thing with any GUI element is clarity - the user must innately know what will happen when they press something (they know that clicking an inactive tab will make it active); and in navigation - it must be very clear exactly which tab they are currently on. As lothar said, if it's not immediately visible to the user, it's very confusing. If you address those issues, then it should be fine.
Just wanted to note SmashingMagazine has a new article showcasing tabs: Showcase of Tabs
I think people are used to the metaphor (from binders, or card-indexes and so forth) of tabs. Especially those that use the web for any length of time. I think that, if IE's adopted a metaphor, it implies a common familiarity with that metaphor.
So, no, I'd suggest that they're not confusing and suggest that you go for it. Just, maybe, post a welcome/first-time introduction (or a prominent 'help' link to such an intro) to the use of the tabs.
I've been a developer for an intranet app that used a tabbed interface, generated with HTML and controlled by JavaScript. This was way before IE7 and Firefox. In fact, it was a bit of a novelty on websites in general, too.
Fortunately, a previous developer had discovered that if you made it look like a dialog box - even down to using a grey background, then people usually understood the metaphor. We also loaded all the content for all the tabs in the initial page-load, and had the Save/Cancel buttons outside the tabbed structure. Because of this, most people immediately understood that they could move between tabs (we used JavaScript to hide and show the DIVs) and a Save would save changes to all of them.
If you want to deviate from such an obvious metaphor, then you need to do some usability studies.
A well implemented Tab interface should not confuse users.
In line with what others have said one of the most ipmortant things to consider with Tabs, or any other navigation interface is for it to be obvious where they currently are in the navigation scheme.
Another important point is not to break the browser! Many AJAX or javascript implemtations break the back button. This is a minor annoyance to some and a major inconvieniece to others. Make sure to consider your target audience here.
Personaly I prefer the oldschool method of not preloading all of the tabs but having each tab as its own page and using a templating methodology to manage the navigation interface, be it tabbled or otherwise. This maintains the browser history and works fine with or without javascipt.
Tabs, etc are just tools. How we decide to lay them out and use them is what determines their effectiveness.
What I try to keep in mind is:
1) Keep it close. The things we use the most should be on the front or up close to the top as much as possible and bury the rest based on how often they are used/adjusted.
2) Easy enough for Mom to use. All interfaces are confusing if they are not laid out in a clear and logical manner.
3) Organize how it's used, not how you think it makes sense.* I often use tabs to break up steps in a process, or to break up areas such as basic / advanced options. I group them based on similarity or usage depending on what works better
4) Keep them few Either way I try to stay below the 7-10 range tops as the human brain has a hard time jumping beyond 7-10 digits, so I assume the same for pieces of information. Vertical Accordians might be something you want to look into as well.
I have also embedded tabs within tabs before. Works well but only one layer deep most of the time.
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)