Wouldn’t the UI differ somewhat depending on the type of data you have? Is it something that will be sorted alphabetically or just numerically? In your examples, I don’t understand what that second string of numbers is supposed to be.

That said, I’m not sure it matters that much how you arrange it as long as the user can quickly learn to navigate whatever system you choose (I like the first “my data table” example, the “jump” button in the second one isn’t as self explanatory to me). Where’s the input for the number of records shown? That’s a useful feature.

Control placement…again, I think it depends on the type of data. Am i going to be able to tell in a moment if the data I need is on that page? Then top controls. Will I most likely scroll through the whole page? Bottom, or how about off to the right? Nope, you said you might have long horizontal outputs, strike that option.

Icons, links, buttons, that’s just icing on the cake, no?

I was just using dummy data in the example tables - they don’t mean anything. The actual data in question is a server log, which would be in reverse chronological order (most recent log output first). So most typically they will likely only look at the first page or two, if there was a recent error or such. Though it is possible the user would want to search back through the logs looking for older entries.

Thinking about it some more last night, I decided maybe it would be best to contain the data table in a scrollable div (using Javascript to set the height and width), then I can left-align the search box and right-align the paging controls, without having to worry about how wide the rows can get. Also, this way I can be sure that the footer will always be visible, and can therefore put the search/paging controls at the bottom of the table, where they make more sense.

It’s interesting to know that you found the Jump button somewhat confusing - I wasn’t sure how intuitive that would be. The reason I had that possibility is that it’s a compact way of jumping to an arbitrary page.

It’s true I didn’t have much of any ideas as to how to present the user with the option of specifying the number of records per page. Maybe if I had another link, like so:

Page 5 of 12 (Set page size) | Previous | Next

And that could maybe just bring up a dialog box where the user could enter their desired page size.

I use very similar navigation types as you.

This is what I use:

Search: |INPUT| Records per page: |SELECT| |BUTTON|
Page 5 of 20
First | Previous | Next | Last
Page Jump: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

DATE TABLE HERE

Page 5 of 20
First | Previous | Next | Last
Page Jump: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

The navigation underneath would probably be set to only appear if the records per page is a large number, and the jump menu would probably be coded to just show the 5 pages before and after the current page. A bit like google does with its gooooooooogle. Or have they stoped doing that now?

I think the next question is what is the most semantic way of marking these kind of things up??

Phil - that solution pretty much covers everything. It seems like it would use a lot of vertical screen real estate, though. But maybe I’m just too stingy with screen space.

In general, with this web app, I’ve been trying to fit almost everything above the fold, making it less like a web page and more like a non-web software application.

It can be pretty challenging trying to get the design right, especially since I’m the only user interface person in the office. The QA team can be helpful sometimes, but it would really be nice to actually be part of a user interface team, with people who specialize in design, information architecture, usability, and such.

Here’s a couple of half-baked thoughts on the subject that might help a bit…

First, when dealing with a large number of results pages, providing the option to arbitrarily ‘jump’ to a particular result page implies that the sorting is very obvious. Even then, it’s hard to jump to the right one. But if the sorting is not obvious, it’s nearly impossible to pick the right page.

For most data sets, this isn’t a problem. For instance, those sorted alphabetically. In your example, if they are sorted by date, it would be somewhat relevant to indicate what date they start on and what date they end on so that you know how many days are on each page and can estimate the right page to ‘jump’ to.

Might want to indicate at the top of each page what the beginning and end timestamp for that section are.

Having said that, I’m not entirely convinced that jumping is all that terribly valuable in large data sets anyway. If I’m looking for a specific enough piece of data, isn’t it easier to filter the set down to the point where I have a narrow enough set to work with? If you have 20 pages of data, is it possible that that is too much data?

With log data, I imagine users would find the ability to restrict the timestamp to a specified range to be valuable. Also, to have text searching so they can return specific errors.

If that still returns a very large set, then I would imagine that the nature of log analysis means they just have to view it, page by page. In which case putting as much of it on a page as possible is a good thing. That’s where the results per page thing is good.

And one final thought on that results per page widget - set it high. I’m working on a site now where we set it optimized for low bandwidth connections so as not to overwhelm people. All we get are complaints that it’s not high enough. One thought we had on that was to set the value to a cookie so that once you set your preference it sticks.

We had a similar problem a while back and e-mailed the Web Design list about it.

This was the question, the result can be seen here (note: that site, though live in English, isn’t officially finished yet! And, you may recognize something there ;-]).

Try simply clicking the search button and see how the result bar changes - not good to change something, I know.

It’s based on the way that phpBB works, I believe. We wanted to make sure that people could always find their way back to page one and the final page.

There were a lot of what’s and how’s with this page, as well as people who ‘knew how it should be’. We’re collecting numbers to see what gets clicked and what doesn’t for an August redesign.

May 1-2 April 28-30 April 16-27

or

A-D E-G H-M N-Q R-U V-Z

I guess it’s hard to come up with a general solution that will fit all scenarios - it just depends on what your data is, as you said.

In this specific case that I’m working on, the log files are actually already seperated by date - you can only see the logs from one day at a time. Unfortunately, that wasn’t enough to cut the page size down, since there can be very many transactions going through the system per day.

As far as the results per page goes, I’m thinking around 500 records per page. More than that and it starts significantly slowing down the browser page rendering, regardless of connection speed. I think I’ll take a wait-and-see approach to letting the user set the page size. If QA or customers mention it, then I can go back later and put it in.