Pagination on navigation links?

Question

On a web application we have two ways to navigate to our collaborative project sites. One is the “recent visits” and the other is alphabetical. That navigation element has a fixed element height of five links. If you participate in more than five projects, pagination sets in – and you have no way to view all project links at a time.

The reason for having pagination in the first place is to make the navigation less prominent and allowing other content below the navigation avoiding a longer web page. I disagree with the technique to use pagination of the navigation in the first place and I’m thinking of different alternatives to improve navigation:

1. Disregarding the pagination all together, showing all the list at one time (pushing other content further down on the web page).
2. Insert a “view all” link above these project links, redirecting the user to another page with a detailed description of each link.
3. Insert a “view all” link where the pagination used to be, working like “read more..” links on wordy content.

Still I’m in doubt which one of these three options to suggest getting a better navigation for our users.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 1

Options 2 and 3 make a lot of sense if the users often don’t remember the exact name of the project they’re looking for. I’m inclined to go with Option 3 only because the user is likely to first scan down the Recent list to see if the project is there (it’ll change dynamically, after all), and then choose to scan the comprehensive list. Thus, their eyes will usually be at the bottom of the Recent list when they decide to View All.

While the comprehensive list can by default be alphabetical, if there’s potential for a very long list (> 20 items), consider putting it in a table that’s sortable on various fields that the user may use to find the project they want (e.g., dates of operation, project manager). If the user doesn’t know the name, maybe they can identify the project by some combination of other information.

So Option 3 sounds fine to me, but here’re a few more options:

Option 4: Alpha-labeled Links

You correct that paging would be awkward in this context for reasons given in the answers to Is scrolling better than clicking to reveal more content? However, it may be acceptable to have paging if the links to the pages are labeled with the range of initial letters for the names of the projects that the pages comprise, rather than arbitrary numbers. That would be adequate if the users know the names of the projects they’re after. My hunch is that is won’t work all the time –what if a user has a lot of projects with names that all start with the same letter or even the same word?

Option 5: Scrollable Nav Pane

If pushing the “Other Content” pane down the page is unacceptable, you may want to consider making a div for the navigation pane and give it its own scrollbar. That would allow you implement a version of Option 1 but keep “Other Content” in a static position. In fact, maybe all your major panes should be separate divs with their own scrollbars (e.g., so the top Messages are never pushed out of view by lots of News). That will prevent having a scrollable region nested in a scrollable region (i.e., the browser’s scrollbar), which can be awkward and confusing.

If you make the navigation pane scrollable, you may want to combine the Recent and Alphabetical list into one menu using a Sears & Shneiderman split menu like seen in the MS Office Font dropdown, eliminating the need for users to explicitly switch between Recent and Alphabetical. When you remove the controls for sorting and paging, you should have room to show (without scrolling) 5 most recent projects plus a sample of the alphabetical list to prompt uses to scroll for more.

Option 6: Comprehensive Pulldown

If users almost always know the name of the project, then put an All Projects pulldown menu at the bottom of the Recent Projects list, where the All Projects list is sorted alphabetically. This will be faster that loading an entirely new page for all projects but take little more space than a View All link. This may be preferred when the total number of projects is almost always less than 15 or so.

If the user has only 6 of fewer projects, hide the pulldown and, if necessary, use the available space for a link to the sixth project. This will prevent a pulldown menu that’s annoyingly redundant. If the user has only six projects, they don’t need both Recent and Alphabetical sorting.

Answer 2

The ideal answer would satisfy ALL of your objectives.

Obj 1 - Make the navigation less prominent. Obj 2 - Allow other content below the navigation. Obj 3 - Avoid a longer web page. Obj 4 - Allowing for direct access to projects. (Eliminate Paging) Obj 5 - Allow viewing of all projects at once.

Here is an amazing solution that would almost accomplish all of this! Use a switch to satisfy all of the users. Using the .length() of the project list for each user.

If the user has five or less projects, eliminate the paging. All projects will show and they will have direct access to them. All objectives accomplished!

For the users with 6-10 projects, shrink the button heights, and again eliminate the paging. Reduce the button height, and with the extra room from the elimination of the paging, you should be able to fit in 8-10 buttons comfortably. All objectives accomplished again.

Hopefully, from user statistics you will accommodate a high percentage of your user base with ALL of the objectives.

In the last rarer case, with users with more than 10 projects. Revert to paging with the smaller height buttons. This will reduce paging, increase directability some, and be the only compromise. Only the users with many projects will be hindered with all the visual noise the paging brings. And All other users will meet all of your objectives.