What is the correct order of previous - next buttons in paginated results?

Question

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?

Answer 1

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.

Answer 2

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.