Complex Data Table Design

9 Apr 2009 - 2:08pm
5 years ago
13 replies
2330 reads
Dave Robertson
2005

Folks

I'm working in an enterprise application with a large table of data
that currently forces a horizontal scroll. This table displays data
contained in a work order. This is the legacy of a previously built
system.

We know we need to eliminate the horizontal scroll, but the business
customers still want to use the table model to maintain some
consistency with the old application.

We're going to try four tactics to try and narrow the footprint to
the 1280 pixel width (minus the scroll bar, etc) we've established
for the application:

Compression: Reducing the size of data display space to the minimum
possible.

Abbreviation: Abbreviating data where required and using

Stacking: Stacking data display space so that the line is no longer a
single row across.

Hide / reveal: Using hide reveal techniques like twisties and tooltip
popups (on hover).

Am I missing any tactics here? Does any one have any interesting
examples?

(And, in embarrassment, is there a glossary of controls posted
somewhere on the Intertubes? I feel like my descriptions of UI
controls are sloppy ...)

Dave

Comments

9 Apr 2009 - 3:44pm
sdboyd
2007

Hi Dave,

It sounds like you've got a really good handle on the process of
"narrowing" the table. Since you've been given the opportunity to
rework the table, you might see how much latitude you have in
reworking the process.

I'd guess that the legacy app table is so big because many different
people use it to make different kinds of decisions. Is it possible to
identify different roles and activities and limit the data views
based on those?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

9 Apr 2009 - 6:49pm
Adam Lerner
2009

Dave -

I can relate to your dilemma. I am currently working on redesigning
an application with a similar massive table of data. I think that
Steve's suggestion of looking at roles and limiting display to the
data points of direct relevance to the user-type is spot on.
Unfortunately, it doesn't work in the case of the system I am
working on.

We have a number of different user types, but this particular screen
is in a shared environment where all the data must be present.
Customization from client site to client site makes it even trickier.

I have had some success in my early prototypes using several of the
techniques you mention. In particular, Stacking rows and using mouse
hover to reveal less essential data points is helping.

I am also playing with expanding rows on click which reveal an
additional couple data lines. But one last avenue of great promise is
the substitution of multi-state icons for some of the data. By having
a graphic that changes slightly according to consistent criteria, I
am sometimes able to show multiple data states in the space of one
image (rather than a couple columns of separated data.)

Don't know if that will help in your case. I'm eager to hear what
you come up with, though. I'm sure it would be useful to me as well.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

9 Apr 2009 - 8:30pm
Michael B. Moore
2008

Is a List/Detail pattern out of the question? Do users really need to see
*every* bit of data in the table, or could the more lengthy, less commonly
used elements live in a detail panel below?
Michael Moore

On Thu, Apr 9, 2009 at 9:49 AM, Adam Lerner <vocable at gmail.com> wrote:

> Dave -
>
> I can relate to your dilemma. I am currently working on redesigning
> an application with a similar massive table of data. I think that
> Steve's suggestion of looking at roles and limiting display to the
> data points of direct relevance to the user-type is spot on.
> Unfortunately, it doesn't work in the case of the system I am
> working on.
>
> We have a number of different user types, but this particular screen
> is in a shared environment where all the data must be present.
> Customization from client site to client site makes it even trickier.
>
>
> I have had some success in my early prototypes using several of the
> techniques you mention. In particular, Stacking rows and using mouse
> hover to reveal less essential data points is helping.
>
> I am also playing with expanding rows on click which reveal an
> additional couple data lines. But one last avenue of great promise is
> the substitution of multi-state icons for some of the data. By having
> a graphic that changes slightly according to consistent criteria, I
> am sometimes able to show multiple data states in the space of one
> image (rather than a couple columns of separated data.)
>
> Don't know if that will help in your case. I'm eager to hear what
> you come up with, though. I'm sure it would be useful to me as well.
>
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=41136
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
Michael B. Moore • Pure InfoDesign • 415.246.6690 M • www.pureinfodesign.com

9 Apr 2009 - 9:07pm
jayeffvee
2007

Have you also thought of allowing the table to be customizable, so
that users can select only those fields that are meaningful to them
-- or in the case of using either hide/reveal or list/detail, they
could choose their own default view of the data and relegate fields
they need less frequently to the hidden section or the detail view.

Allowing people to drag and drop rows into a preferred order might be
helpful, too.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

9 Apr 2009 - 5:31pm
James Pellizzi
2009

How much data in that table is 100% necessary? Kill some columns, see
if anyone complains.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

10 Apr 2009 - 1:40am
Anonymous

You've listed just about all the tactics we've used, or tried to use, for
large, long tables of complex data.

Users of our application didn't like tooltips, and it made sense for how
they needed to view the data. The tooltip obscured data underneath. In this
case, seeing all the data all the time was important. Plus, accidental
hovers caused tooltips when they weren't intended. A click to show a popup
didn't seem to work: users needed the information in the popup but if they
needed the information in the popup and needed the information underneath,
it wasn't a good solution. And then, being able to move the popup elsewhere
on the page still obscured data underneath somewhere else.

We used hide/reveal accordions, for lack of a better term, based on an
80/15/5 rule. Data people needed 80% of the time was always shown. Data
needed 15% of the time was hidden but could be revealed via an accordion (a
hidden row that could be revealed or closed, just a jQuery show/hide). Data
needed 5% of the time, well, we burn that bridge when we come to it on a
case by case basis and we are still burning bridges as I write this.

But to go back, how we figured what data fit the 80%, etc., was to ask the
application's users. We're lucky enough to have built the application for a
relatively small set of users whose representatives all liked each
other--so, discussion over what needed showing/hiding was bloodless. And we
could do the discussion in person in twice-a-month meetings until the
application reached version 1.0.

Another bit of info: we determined that different users needed to see
different data at different times, but needed access to all of it. So, users
can hide/show data, including data within the 80%, and the application
remembers their preferences.

That's maybe more details than needed, but if more are wanted I'd be happy
to discuss offline.

-jody

--
Jody Tate
Interface Designer and Developer
UW Network Systems
http://staff.washington.edu/jtate/

10 Apr 2009 - 8:23am
Ray DeLaPena
2009

Dave,

Along the lines of what Adam and Steve have mentioned, when I've
been faced with this dilemma in both data table display and report
design I've tried to focus on what questions are being asked of the
data.

When there's pressure to include every field under the sun it's
typically because the users wonder "What if I need to know XYZ?"
But more often the questions they need answered only require small
bits of the overall data set. If you can identify the most commonly
asked questions and provide them a way to ask them you'll be able to
tailor the results more directly. It will also probably speed up their
process as well.

In your work order situation, you might then provide a link or button
to expand the full details of a selected work order whenever it comes
up in a (pared down) result set.

- Ray

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

10 Apr 2009 - 1:41pm
Adrian Howard
2005

On 9 Apr 2009, at 12:08, Dave Robertson wrote:

> Folks
>
> I'm working in an enterprise application with a large table of data
> that currently forces a horizontal scroll. This table displays data
> contained in a work order. This is the legacy of a previously built
> system.
>
> We know we need to eliminate the horizontal scroll, but the business
> customers still want to use the table model to maintain some
> consistency with the old application.
[snip]
> Am I missing any tactics here? Does any one have any interesting
> examples?

Couple more for the list.

* Buy the users bigger monitors? Depending on the # users it might be
a cost effective solution - and bigger screens are more useful anyway.

* Use alternative display styles (e.g. sparklines instead of a
sequence of numbers, a single up/down arrow instead of a trend graph,
etc.

Cheers,

Adrian
--
delicious.com/adrianh - twitter.com/adrianh - adrianh at quietstars.com

10 Apr 2009 - 4:41pm
Dave Robertson
2005

Hay Everybody!

Thanks for all the helpful advice. I'm grateful that you all chimed
in like this.

Excellent points on the roles - we had exactly that discussion
yesterday afternoon and that fixed a good 25% of the problem.

We've used the "reveal details" strategy to good effect now, too.

Interestingly, they already bought *some people" larger monitors
because they designed the app and *then* realized they had a space
issue. It's going to a larger user base now, so this solution is in
question.

But just to do justice to your generosity, let me recap that list
with your suggestions. If I've missed one, apologies - please feel
welcome to add it:

Reduction: Display only that data that the end user really needs to
see (and examine a role based solution, if that's helpful).

Customization: Consider whether the user can create or customize the
data display for their own purposes.

Visualization: Consider whether visual aids or mechanisms aid the
display of data in a table or even potentially replace them
completely.

Compression: Reducing the size of data display space to the minimum
possible.

Abbreviation: Abbreviating data where required and using

Stacking: Stacking data display space so that the line is no longer a
single row across.

Hide / reveal: Using hide reveal techniques like twisties and tooltip
popups (on hover).

How's that?

Thanks again!

Dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

10 Apr 2009 - 4:46pm
DampeS8N
2008

I rather like tables that auto-widen the column I am hovered over. But
only when they smoothly animate over around .5-1 second.

That way, it can widen to show the widest item without drastically
reducing legibility. Provided of course the other columns are still
mostly understandable while not hovered.

There is no easy solution. But this can go a long way as you can
shrink any long text column dramatically. Enough to make sure the
label is the catching point and not the contents.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

10 Apr 2009 - 8:36pm
usabilitymedic
2008

Dave,

I worked through a similar challenge a while back and I will try to
resurrect more details but for now...

In addition to looking at the data table from the point of view of
different roles and displaying info accordingly, try using the same
premise for tasks.

In the project I worked on, one role regularly performed two types of
tasks. And the information needed for each task was somewhat
different. So, we created a different view for each task with a
toggle mechanism so the user could easily switch from one to the
other.

mm

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

10 Apr 2009 - 8:45pm
usabilitymedic
2008

Dave,

We understand your data table is wide but I'm wondering how "long"
is it? And if it's long, does it paginate or render al in one page?

Also, do you users have the ability to sort the table by each column?

Just asking because these factors can sometimes make a difference in
the effectiveness of some of the solutions to narrowing the width.

mm

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

11 Apr 2009 - 8:18pm
dirtandrust
2008

Some great IxD Patterns sites which will help you with patterns and
terminology:

http://www.welie.com
http://ui-patterns.com/

There's many more out there. Just look up "Interaction Design
Patterns".

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41136

Syndicate content Get the feed