If you must display 64 fields to all users in a table, then your design for the columns is the standard solution (or, at least, it should be). Observations of Excel use indeed shows that such large tables are workable. I don’t understand the row “problem” –1000 rows is not too many for a single window for modern large displays, especially if you fit those rows In a vertically scrolling pane that keep column headers in view (again, like Excel). 64x1000 fields is only about a meg of data to load –not too much even for a web app by today’s standards. So don’t use paging in this case.
However, whenever you get a questionable demand from users, that’s a sign to research why. Once you understand why, often you, with the imagination and experience of a designer, can think of a better way to meet the user’s needs. “Research” doesn’t stop with asking users why, although that’s good start. You should also find out what the users actually do with these 64 fields by such means as direct observation or log analysis.
Is it really true that you must display all 64 fields to all users in a table?
First of all, could it be that some users need some fields and others need others, and you can adapt the table to different user roles (e.g., employee positions). Don’t trust users saying they “don’t mind” if there’re extra fields, or “it would be nice” to have extra fields because “some day they might need them.” Instead, look at your task analyses and determine what fields each user group truly needs. Users are not good at anticipating the effects of information overload, especially for hypothetical designs.
Second of all, could it be that only some of those fields need to be in a table? Only fields used to identify, select, and compare rows need to be in a table. Other fields can go in a “overflow” detail pane below the table in the window, where they can have a form-like layout (e.g., the bottom third of the screen has four columns of 14 fields each, leaving 30 rows of only 8 fields in the table). And/or low priority fields can be placed in a separate window accessed by clicking a link in the table or selecting a menu item. For more details, see Taking Panes.
Third of all, could it be that they are using these 64 fields to mentally (or with paper!) derive some aggregate value for each row? If so, is there some way you can do that aggregation for them, replacing many fields with a single field?
Chances are once you find out why users are insisting on viewing all columns at once, another alternative I haven’t imagined will become obvious.
