: What is the correct order of previous - next buttons in paginated results? We are developing an XML DITA content system that allows users to view their search results in a paginated form and
We are developing an XML DITA content system that allows users to view their search results in a paginated form and navigate through these results backwards and forwards, page by page and we have placed the "next" and "previous" links in this format:
Previous Search Result Next Search Result
Our customer has now asked for the order of these two links to be reversed so that the Next Search result precedes the Previous Search result.
Next Search Result Previous Search Result
We and our customers are both English speaking companies and we feel that the obvious and correct way to display these links is the back link to the left and the forward link to the right. The same as if you were reading a book and wanted to go to the next page. Or the undo and redo buttons in applications eg Microsoft Word.
But, I have seen some people state that the primary function, which is Next, should be the first button/link as this is what users will be looking for and using most. Also for those users with screen readers or who are tabbing through the page it is easier this way round. But.... "Previous" being placed to the left of "Next" is such a strongly accepted convention in Western culture that I feel changing it will confuse a considerable proportion of our users.
In the same vein, we could ask about the form buttons: clear and submit. I always expect the clear button to be on the left and the submit submit to be on the right but as filling out a form is a linear process and I always Tab through the fields, would it not make more sense to have the submit before clear so you can tab once from the last field and submit?
I know this is a bit of a subjective question, but it is key to web usability and I was wondering if anyone can point me in the direction of studies that give credance to either view. Or is there an overwhelming yay or nay from users?
More posts by @Karen161
2 Comments
Sorted by latest first Latest Oldest Best
It does not pay to fight clients on UI - this is generally the one aspect of the project which the client feels he or she knows best about, particularly if he or she will be using the interface.
Share your reservations and then implement exactly as requested - time will tell if the client reneges on his or her judgment call, but I can assure you that only experience (or extensive testing) will prove to the client that he or she is not a usability expert.
As for cancel/reset buttons, this is an instance in which Jakob Nielsen's research might be of use:
The Web would be a happier place if
virtually all Reset buttons were
removed. This button almost never
helps users, but often hurts them.
Reset clears away the user's input on
a Web form, but why would people want
to do that? The Web is characterized
by frequent movement between pages and
users rarely encounter the same form
twice. Thus, a Web form is almost
always cleared when the user sees it.
Even when a user revisits a form in a
single session, it is usually faster
to edit the old data than to erase it
and start over.
Reset and Cancel Buttons
It really doesn't make much sense to include an inline self-destruct button at the end of a particularly long form - the "Back" button has been around from the dawn of browsing and most users have accepted it as the self-destruct button of choice.
I agree that previous needs to be on the left and next on the right. You can probably find many sites that use that convention as evidence. One way of getting round the objection about screen readers is to place them the other way in the HTML and then use CSS floats so that they look the way you want (previous - next) on the screen.
I see less and less clear buttons these days.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.