DataGrids are the safety blanket for bad design.

I’m constantly in and out of meetings with developers who are making some pretty intense Silverlight based solutions. It’s exciting and irritating at the same time to see them having all the fun in Silverlight and all I do is give advice etc on how to fix X or approach the product from Y lense.

One consistent theme I often see a lot is the over-use of DataGrids. DataGrids are being used pretty much majority of the time to present any if not all large amounts of data and it absolutely baffles me personally as to why developers keep gravitating towards them?

I say this, mainly as you’re given a solution like Silverlight where its actually your job to simplify the end user’s experience – yet the first chance some get, “Let’s grab the ye olde DataGrid with sortable columns and snap it into place”

DataGrids have a very small niche of usage rights in my opinion when it comes towards User Experience. What I mean is, should you have a need to make your own Excel Spreadsheet, sure, I can see the need (sortable columns and all).

Otherwise, stop. Use ListBox’s instead of DataGrids.

The difference between a ListBox and a DataGrid visually is obvious – DataGrid is multiple columns, ListBox is one. The major significant mindset adjustment for a ListBox is that it dares both the developer and end user to think about the problem being solved in that current piece of software.

An example that comes to mind and is quite common is Outlook 2007.

On the left you have a tree like situation, this is your first line of defence against dense data. It essentially forces you as an end user to think in terms of contextual categories regarding your email traffic.

The next column is typically a list of emails separated based on Date (Most commonly) but again, this is your second layer of defence regarding unnecessary dense data.

Last is the body of the email itself, basically this is your main end point “ahah, now i can get down to work”.

I like to use this as one of many examples of how a DataGrid vs ListBox could go off the deep end. In this example you’ve provided the ability for the end user to both narrow their filtering (self-selection in the wild) and secondly you’ve addressed the overall problem in a way that isn’t to restrictive or requires a lot of mental processing to parse for that email sent “last week”.

It’s concept also caters to both large and small data sets, as should you have an inbox like I did when I was at Microsoft, it was pretty much 1000’s of emails a day.

Today I have smaller inbox (yay) but the problem getting access to emails from the past hasn’t changed. In this approach to UI, i’m still able to sort/parse the said emails but should the data not yield an obvious “at first glance” hunt for that email of ages past, I can enter a search term – that or – sort the data on a more contextual level (narrowing down the data ).

Search is probably the area I use the most in Outlook as i’m often going “Oh crap, Sarah sent me an email last week, it had something to do with X customer…” I then type in “Sarah X Customer” and already my hunt is narrowed and the chase begins.

You can do the same with DataGrids, don’t get me wrong. DataGrids however get quite busy and cumbersome once you go beyond 1 line of text. In that, we humans typically aren’t happy to read horizontally – it has to do with the fact we prefer to parse things vertically than horizontally and especially on wide columns. It gives the impression that its “heavy or more work” vs vertical can give you more of a feeling of being “quick to parse” (Ever wonder why news papers do this?)

Bottom line is this. DataGrids should really be left to narrow specific areas of use, typically for fiscal data that has a lot of calculations to review – that or UI’s that make use of 1 line of text much like Apple’s email client does below.

Having said all of that, I still often see teams of folks praise the DataGrids that have heirachy’s of sub-grids as a “better way” to represent the data. It can be quite frustrating to see this, but I simply take it on the chin, take a deep breathe and try and sway them to focusing on the said problem from a different angle where the mandate/objective is to simplify the density of the data.

Less is more when it comes to UI, parsing large amounts of information gets tedious and is more prone to human error than user interfaces that handle a lot of the heavy lifting for you.


Related Posts:

  • No Related Posts
  • http://nickjosevski.wordpress.com/ Nick Josevski

    I completely agree with DataGrids being a crutch, the simplest option and as a result a poor design choice. “Lets not design/think-about the screen/interaction/flow, lets just slap in a DataGrid and keep going.”

    This has many downsides one of which is having that DataGrid getting worse over time and often very quickly. This happens through various additions and expansions on a UI element that shouldn’t be there in the first place.

    Comments from stake holders such as; “can we have these cells interact and change those other cells”, “can we embed a checked listbox in these cells”, and so on deeper into the hole you get.

  • http://www.mindscape.co.nz John-Daniel Trask

    +1 Scott.

    At Mindscape we’ve been part of the anti-data grid brigade for years and were stoked when WPF/SL came about to make rich presentation and visualization of data easier.

    There would be mutiny in the company if I suggested we build a data grid but unfortunately, being in the controls space, it’s appearing more and more like we should just build one as they still appear to be the #1 selling controls.

    It’s all a bit sad really. It’s like finally building a flying car but still driving on the road.