The data grid is the default way to present a collection of things in enterprise software. Often times it's wasteful and inappropriate. This post explains the perils of using data grids and offers some alternatives.
A little history
Those of you born after 1980 may not know that a spreadsheet program called VisiCalc was considered to be one of the first "killer apps" in the PC era. Killer app is 1980's marketing slang for "a reason for people who aren't nerds to buy a computer."
Not much has changed since then. Excel continues its reign as the killer app for business users (aside from email/web). Tabular data with sorting, filtering, grouping, formulas and so on is and forever will be reality for them.
There's nothing wrong with spreadsheets mind you. The issue is the unstoppable urge to bring the spreadsheet UI to all business software regardless of the cost or relevance.
Why data grids are everywhere
Let's say MegaCorp® wants to build a web app to replace a manual process involving a shared Excel file which contains data about Widgets. They employ Kathy, our intrepid software developer, to build it.
Kathy: Ok so what are the properties of a Widget?
MegaCorp®: Let's see... they have a name, a SKU, a price... I think about twenty attributes in all.
Kathy: Ok so I can easily build some forms to allow the user to create, edit and delete each individual Widget. How will we the users navigate to each Widget to be edited?
MegaCorp®: We'd like a data grid.
Kathy: Ok how many Widgets will there be in total? Tens, hundreds, thousands?
MegaCorp®: Oh probably tens of thousands.
Kathy: Ok so we'll need server-side paging and pagination UI controls. Which columns do you want to display?
MegaCorp®: Hmm, probably name and SKU. Sometimes Bill in Accounting wants to see price... and Susan in QC wants to see batch number. Not sure. How about we start by showing name and SKU and allowing the user to choose which columns they want to see. I've seen other apps do that, you can do that right?
Kathy: Sure. But unless I add functionality to store each user's preferences, they'll need to re-configure the grid every time they use it.
MegaCorp®: Sure. And we need to be able to sort on any column. Oh! And we need to group by any of the columns. That's very important. It would also be nice to order the columns by dragging and dropping... oh and we need the column labels to always be visible so we'll need the header to be "sticky" as the user scrolls down the page.
MegaCorp®: And while you're at it, we'd like to export the data grid to an Excel file too.
Kathy: Is CSV ok?
This conversation goes on until Kathy is basically agreeing to re-implement Excel. Kathy can't do that with the time and budget she has, so she needs to use an off-the-shelf component from a 3rd party. Now she has several more problems like shopping around, learning how to configure it, and taking a significant dependency. If she discovers a limitation in that component months from now, she'll be forced to have a very tough conversation with her employer.
This may seem like a very cynical, fallacious slippery-slope narrative but it happens all the time.
The original question Kathy asked was "how will we the users navigate to each Widget to be edited?" She probably should have asked "who is trying to find Widgets to edit and why?"
Aside from spreadsheet familiarity, data grids permeate business software when displaying collections of things for two other reasons:
Laziness/effeciency/politics. People use data grids because they don't have the time/money to deeply understand use cases. They are so flexible that nobody needs to stick their neck out and make a single design decision.
People are afraid of losing data. If they can just "always see everything" and have pagination like "Displaying page 1 of 500" at the bottom then their fears will be assuaged.
We can do better
The mobile/touchscreen revolution of the past few years has put a dent in data grid hegemony. You simply can't squeeze lots of data onto a small screen because the user won't be able to read it or touch it with accuracy.
Instead, developers/designers are using "list views" or "cards" to present collections of things. This is great because the constraints of the medium are forcing people to choose which information is truly important. Even if you're building an app which doesn't have mobile/touch users, you should try to implement collection views in a "mobile" way if only to have the design conversations.
There's very unlikely that users are spending all day cruising your data grid, basking in it's glory. They're more likely in a hurry and need to quickly find and edit something very specific. Instead of just dumping lots of rows on the screen and making the user muddle through it with column sorting, consider placing filtering as the primary way to find something. Make the filter prominent and remember the last filter they used.
Instead of fifteen pagination links, consider simply showing a summary number to reassure the user that everything is indeed available. Similarly, use small charts to communicate key stats instead of providing open-ended grouping and sub-totals.
If exporting/importing to Excel is very important to your users, consider just building your app as a plugin to Office/Office365. It's much easier to do that you might imagine.
Don't take my word for it. Telerik, a company who probably makes a majority of its revenue from selling data grid controls, suggests they may not not be necessary in all cases (in a clever content-marketing sort-of way).
Data grids certainly have their place in some applications but not all. Don't be afraid to ask questions and challenge assumptions. The better you understand your user's real needs, the happier they will be. It's that simple.