The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Busy forms - lots of data, etc.

I am working on a project and the interface is getting very busy.  Functionally, everything works.  The users and management want to see as much data as possible (sales & customer service related).  They really don't want to flip through screen - although some show/hide functionality is possible.

I am looking specifically for some tips and examples of things people have done to separate data elements logically, color, font, and emphasis used to provide notification of important data.

Matthew Moran Send private email
Wednesday, June 07, 2006
One of the things you should avoid is having too much data on a single form because what happens is that the user to trying to focus on too many things at once. If management does not want more forms you can use a pagecontrol on your form i.e. present the data in several pages of the pagecontrol. I think the synonym for this control is tabbed notebook.

In ths approach you can place similar data items on the same page and put an appropriate label on the tab e.g. if you have a student data you can have on one page personal details, on another page course details, on another page enrolment details etc. You have all his details on one form but not all of it are display at the same time for the user to digest. Hope this helps.
Phillip Flores Send private email
Wednesday, June 07, 2006
Thanks for the reply.

I understand this and in most cases, in fact, even in this case, do a variety of things to minimize the data per window/screen/view.  The problem is that there is data they want to see and be available.

I am looking at techniques to deal with a lot of controls on a form.

Certainly, working with alignment of labels, boxes around logically grouped controls, etc. but I would love to see and read about color scheme, font characteristics, etc. that make digesting and understanding data simpler.

Matthew Moran Send private email
Wednesday, June 07, 2006
- Make the data stand out & the labels, borders and organising clutter fade to the background.

Several places I've worked have had gobs of data to show in limited screen space.  One of the most effective techniques we've used is to make the data font bold.  One size larger than the descriptive info works too, but you mentioned real estate issues.  Frequent users will quickly learn & ignore the labels, so there's no reason for them to have to visually parse them out all the time.

- I've read usability studies that say sans-serif fonts are more easily read on video screens, but that was a while back and better technology may have resolved that one.  (I prefer Verdana or Helvetica to TNR, so I may be prejudiced)

- Use a tabbed presentation (suggested earlier) with key-controlled progress thru the data.  ie, tabbing off LastField on PageA should go to FirstField on PageB.  Mouse movement should not be necessary.

- Minimise color changes on single screens & use a single scheme for the entire app. Try not to violate the standards for the platform you're on.  My company's app is tied to Windows' colors, so the app looks like a standard windows app.  I've seen & used products that used something the developer liked, hardcoded internally, and it's jarring to go into those apps from a 'normal' app.

One I worked place used colors to indicate 'balance' in a financial app (health insurance premium accounting).  Fields that were summaries went light green when 100% OK, light yellow when within a 'fudge factor', and light red when ouside the fudging limit.  Useful info & didn't require them to resond to a dialog.  Straight red, yellow & green were too garish & made the numbers hard to read.  We went for midtones that were the color approximations of Windows' "buttonface" grey.

Whatever you choose, be consistent with fonts, colors, etc throughout the app.  Even if you choose 'non-standard' ways of doing things, as long as the same type of element presents & handles the same way everywhere in the app your users will probably be OK with it.
a former big-fiver Send private email
Wednesday, June 07, 2006
What ever you do, keep it as simple as possible, while showing as much data as necessary.

So, if you MUST use color or fonts for emphasis, use very few fonts or colors.  A Bold font for data sounds good.  The Red/Green/Yellow text approach should be used sparingly.

A 'divider' line can allow you to 'clump' data elements.

I'm not one of those people who insists on breaking data across multiple pages.  Sometimes, a nice linear listing with a scroll bar lets you navigate up and down your displayed data set very easily.
Wednesday, June 07, 2006
Sorry, should have mentioned that the colors were used as field backgrounds; the data was still shown in the standard color & font.

And AllanL5 has a very good point: how much of a set of elements _has_ to be visible without scrolling/changing screens?  If your real estate is maxed out with a few desired elements not visible, it seems silly to force a "page break" when a PageUp/Down can make them visible on demand. 
Related to this, can you prioritise fields to push the low-priority or low-use fields out of the presentation area?  Can you separate read-only info from entry fields?
a former big-fiver Send private email
Wednesday, June 07, 2006
Thanks.  I'm finding some articles - a few samples - and replies like this.  Between all if it I'll probably end up confused and have black background with grey and red lettering - a few flashing green icons, etc.

But we will figure it out.

Matthew Moran
Matthew Moran Send private email
Wednesday, June 07, 2006
one of my customers is an accouting firm. the UI for the app i wrote for them could not be any busier. these guys were previously using excel to do this work and they wanted all the data visible at once. i spent a good week explaining to them why this was bad, especially when they only really cared about 10% of it, but, hey, the customer is always right. so, they are stuck with a busy, ugly, hard to read form, but they love it!
starving coder
Wednesday, June 07, 2006
Just don't forget that a significant number of people are color blind, in particular with respect to green and red.
Wednesday, June 07, 2006
If it's not too late...

Look at some of the stuff that's being explored in AJAX, Flash, Flex and similar technologies. I'm seeing a lot of interfaces that allow for "drilling down" into the data - for example, I remember one demonstration that broke the page into a graph at the top, and a table at the bottom.

If you clicked a bar within the bar graph (or a wedge within the pie chart), the table is populated with the gory details about that segment. Click another bar, and the table and only the table is refreshed with data relevant to that bar.

For example, if I was a studio boss and wanted to look at the performance of the 20 movies or so I released this year, I'd get a bar graph that shows how much each of the 20 made. If I click on the highest grossing movie, the table below then displays who directed it, what the rating was, what the critics' average score was, how much it made domestically, how much foreign, how much DVD sales, etc etc. If I shift-clicked the highest and lowest, then I can compare the two movies.

Anyhow, the point being is that I think there's some interest in moving away from displaying ALL of the data on a web page, but letting the user intuitively and quickly fetch more detailed data as desired.
Wednesday, June 07, 2006
Question whether they really truly have to see everything at once. They might think they do, but probably don't.

I was recently faced with a similar situation in an inventory related application. We eventually determined that various incidental attributes didn't need to be on display the whole time.

The solution we arrived at was to break the screen roughly in half - the top half shows the "common" stuff, and is always there, and the bottom half is switchable through a variety of views using tabs, and allows them to see orders, purchase history, sales history, supplier history, etc.
Andrew Lighten Send private email
Wednesday, June 07, 2006
Have you read Tufte?  Not much help specifically on screen design, but he's great on the theoretical underpinnings for why you want to do it a good way, and having the book around to point to will help convince a boss with "popular" ideas about design...
Ideophoric Send private email
Thursday, June 08, 2006
In your case, it sounds like you have a user base who are used to looking at all the data all the time based on what they're used to in a legacy app. Cluttered screens tend to be problematic, since they are difficult to maintain in a layout sense when there are new requirements. And, they're tough to train new folks on.

I would highly recommend that you provide two prototypes in PowerPoint or Visio to demonstrate (1) the cluttered mess they want after your best efforts to organize the thing, and (2) a "possibility" version done in a tabbed layout, good format, etc. (and show what the form in each tab will look like). Get feedback from some users as you're putting together the demo. One thing I've learned over the years is that users by and large don't care about the functionality of an app per se, but they will quibble over look-and-feel until the cows come home. Then, show it to the main stakeholder and some representative users. It might sway them toward a more reasonable, maintainable layout.

As for references, one of the best I've ever seen is "Don't Make Me Think" by Steve Krug (I've pulled it off my shelf just now). It's well worth the few bucks to buy it used from Not a technical reference, but good, basic principles of web design, layout and behavior; and good examples of Right and Wrong.
Thursday, June 08, 2006
I read Don't Make Me Think a few months ago.  It is excellent but probably worth re-reading.

I am currently prototyping a page that more clearly segments data logically, has some data abbreviated but makes it clickable to expose more, and is otherwise much, much, cleaner.

My goal is to demo this on Tuesday.

I had a long discussion about what is absolutely necessary to see right away and all the time and what they need to be able to toggle on and off while speaking to customers.

Thanks for all the input.

Matthew Moran Send private email
Thursday, June 08, 2006
It depends on how much of a budget you have.

1)  It could be cluttered because you are trying to show everything to everybody.  Does the phone dudes need the same data as the repair guys?

2)  It could also be that your flow and organization is following the database schema, and doesn't reflect the actual tasks people are doing.  For example, are your sales guys having to hop across ten screens to complete an order, because there are ten tables, thus ten screens?

So.  Sit down, shut up, and watch the people use your application.  Observe how they are using your app and more importantly *why* they are using your app.  What is their goal - "place an order to get my commission check?".  What is the tasks they need to reach that goal.

From that, the information they need, and the sequencing of events should just fall out.  Be ruthless about removing anything that gets in the way of them completing their goals....
Cory R. King Send private email
Thursday, June 08, 2006
the best book for what you are doing is:
 Information Dashboard Design : The Effective Visual Communication of Data (Paperback)
by Stephen Few
Thursday, June 08, 2006
you could give flixible workspaces where use could just drag the relevant items/grids/charts into focus and let the others be available in a scroll
Amit George Send private email
Tuesday, July 04, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz