A UI challenge for you
I’m working on this little challenge right now. How would you design the user interface for it?
It’s a pretty common situation: there are a large number of records of some sort, enough to really bog down the browser if you try to display them all at one time. You want to give the user the ability to search through these records as well as page through them (though they can view the records without any search). They also need to be able to tell where they are as they page through the records. Those are the basic requirements.
Nice to haves, but optional:
- The ability to jump to an arbitrary place in the set of records.
- A way to get to the start or end of the set of records.
- The ability to change the number of records displayed per page.
In terms of the visual design, this control or set of controls needs to be pretty compact, and flow nicely with the table of records. Also, the control needs to be visible, even when the content is very long horizontally.
Would you use icons to jump back and forth? Links? Buttons?
Would you integrate the search and paging into one control, or would you seperate them visually?
Where would you place the control(s) relative to the large data table? Under the header row and before the data rows? Sitting on top of the table? Underneath the table?
Here are ideas I’m throwing around for the parts of the control:
Of course, those are only pieces of the puzzle. What’s harder is to figure out how to fit those pieces together.
| My Data Table | |||
| Search: | |||
| Previous | Page 5 of 12 | Next | |||
| 12345 | My first data row | 2897423423 | I never saw a moor, I never saw the sea… |
| 92838 | My second data row | 209348747 | Whose woods these are I think I know… |
| My Data Table | |||
| Search: Page of 12 | |||
| 12345 | My first data row | 2897423423 | I never saw a moor, I never saw the sea… |
| 92838 | My second data row | 209348747 | Whose woods these are I think I know… |
What kind of design would you prefer to use? What configuration seems easiest to understand? If you had to find some information in this large set of data, how would you want it to work?
May 12th, 2004 at 3:00 pm
I saw this post last night and thought “I ain’t touching that with a ten foot pole”. I hate seeing posts with no comments though, so here goes nothing…
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?
May 12th, 2004 at 4:30 pm
Hey Hass, thanks for the input (though you don’t have to comment just because there aren’t any comments - it’s ok, I won’t cry
).
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.
May 12th, 2004 at 5:07 pm
Looks good, make sure you post the finished prototype and we’ll test it for you, OK?
May 12th, 2004 at 5:08 pm
Oh, and Emily Dickinson, heavy…
May 12th, 2004 at 5:45 pm
Sorry for the late post. I have been thinking about this one on and off all day.
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??
May 12th, 2004 at 7:03 pm
Hass - those lines are from the two poems we were assigned to write lieder for in one of my composition classes. Other then those, my knowledge of poetry is rather limited.
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.
May 12th, 2004 at 7:06 pm
Oh, I nearly forgot the issue of semantic markup that you brought up, Phil. That’s a good one. I can’t really think of any good match. I guess you could use some unordered lists, but it doesn’t seem like that would be much more meaningful than just a bunch of text and br tags.
May 13th, 2004 at 10:21 pm
I have no idea how I found myself here, but now that I am, the question is nagging at me.
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.
May 14th, 2004 at 9:25 am
Hey Jennifer,
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 14th, 2004 at 6:27 pm
Hey Andrew, thanks for visiting! Great comment! I think you’re probably quite right about the ability to jump to arbitrary pages. It’s probably something that would be a lot more useful if it told you what exactly you were jumping to, like
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.
May 14th, 2004 at 6:37 pm
Hi Mike! Gee, something about that site seems awfully familiar!
It really looks nice! I like the beachy color palette. Interesting solution to the problem of a large number of pages.
You know, maybe when you click on the View Apartments or View Town Houses, etc. from the home page, maybe you should populate your property type dropdown with the corresponding value. Also, is there some way to search for keywords within a set of search results? That seems like it could be very useful.
P.S. Saw your comment about adding the RSS feed to your site and you are now added to my list–thanks!
May 15th, 2004 at 4:27 pm
Glad I made the list!
I appreciate the feedback on that site. Not sure if you clicked thru to the other languages, but the old version of the site is there.
We’ve been contracted to build a more search-engine friendly site with integrated user-tracking and a whole-lotta other whoopla to try and improve site performace.
We started by building a rough equivalent of the old one, improving what we could, but trying to move fast. Suggestions like yours (nice ones!) will be looked at and built in over time, along with some new ‘non-coffee-table-brochure’ content development.
Glad you like the colors. After a while I couldn’t really *see* the site anymore.