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.