views:

34

answers:

3

I'm working on a pretty basic web app (not much more than CRUD stuff). However, the requirements call for a bunch of data to be displayed with each item in the search results - IDs, dates, email addresses, long descriptions... too much to fit neatly into a simple grid, and too dissimilar to make them flow together (like the natural language example from this article.)

Is there a design pattern for attractively displaying many descriptive fields with each search result?

(Please don't tell me to just remove some fields from the results; that's not an option for this project.)

+2  A: 

It probably depends on the content you're displaying. Look at the StackOverflow layout for this question. It has Votes, Title, Description, Tags, Author, etc. The content wouldn't work well in a grid for sure, nor does it flow nicely on it's own.

I think it's time to get creative ;)

rockinthesixstring
+1  A: 

No one ever thinks about what this is going to look like on their screen, do they?

One thing you can do is truncate the displayed text, and then display the expanded version in a tooltip on hover, or after the user clicks on it.

For example, display only the two-letter state abbreviation but show the full state name on hover.

Or, to save even more space, only display the state abbreviation, and put the entire address in the tooltip.

For long descriptions, you can display only the first few characters, followed by an ellipsis or the word "More". Then, show the full text either on hover or on click.

One disadvantage of the hover approach is that you can't sort the column on that text. There's nothing for the user to click to request the sort.

DOK
+2  A: 

Obviously there are many ways you can handle this, and to a degree it's a factor of your information design abilities and preferences.

Natural Data Groupings

What I would do is try to organize your data into a small number of "buckets." You state that the data are too dissimilar to be arranged into a sentence, but it's likely you can create a few logical groups. Since we can't see all your data, I'll guess that you have information about a person (email, name, ID?), about some sort of event (dates? type?), or maybe about some kind of object related to the person (orders? classes?). Whatever they are, some of the data will be more closely related to each other than others.

Designing in Chunks

Take each loose "bucket" and design a kind of "plate" -- a grouping just for the information in that bucket. The design problem within this constrained chunk is easier to tackle: maybe it's a little table-like layout, maybe it's something non-tabular, like the stackoverflow user "nameplate". Maybe long textual data have their own plates, or maybe they're grouped into a single plate, but with a preview/detail click-for-more arrangement.

Using a Grid

Now that you have a small number of "plates," go back to a grid-like approach for your overall search result row design. Arrange the plates as units within the row, and be sure to keep them aligned. Following an overall grid (HTML table or otherwise) for the plates will avoid an "information soup" problem. You'll have clean columns that scan well, and a readable, natural information hierarchy. The natural language example you cite would indeed be difficult to parse if it were one of many rows displayed in a search results grid.

Consistency

Be sure to use a common "design vocabulary" when you're working on the chunks -- consistent styling of labels, consistent spacing... so when everything's displayed, despite the bulk of information, it all feels like it's part of the same family.

It's an interesting design exercise. Many comps, lots of iteration, and some brainstorming should get you where you need to be.

Ken Redler