Data grids - lack of imagination or abdication of design responsibility?

Paul recently wrote a great blog entry that called out something I’ve felt for a long time, regarding the absence* of an editable datagrid in the “out of the box” WPF control set. While many hard-core winforms users bemoan the lack of a data grid in WPF, I think the absence of a data grid in WPF is a good thing. Why? To me the editable data grid is an over-used UI device, which shows either a terrible lack of imagination or understanding as to how data is going to be entered, or an abdication of UI design responsibility. To be clear - I’m not talking about displaying of tabular data ala the ListView (WPF’s list view is very powerful for this). I’m talking about banging in data, row by row, cell by cell. We don’t give users a copy of SQL Management Studio, show them how to open up underlying tables and let them go nuts, but (to me) giving them an editable grid is not that different.

The reason editable data grids fall short is that when a user enters some data that means something, and I believe data grids don’t do a great job of capturing that meaning because all data entry operations look the same. A bank employee changes a customer credit rating from “good” to “credit risk” using a drop-down list in an editable grid means the nature of that customer’s relationship with the bank is about to change fairly dramatically. Why was the change made? What validations need to be applied? What other processes need to be initiated as a result of this change? As Chris Stevenson pointed out a while ago, editable grids don’t do a great job of capturing these subtleties. Data grids are the “one size fits all“ data entry solution you don’t even have to think about. Sure, the data you get may not be as good as it could have been. The user might have had to jump through a few hoops to get what they wanted done, and they may have been exposed to some implementation details of the system but the data got in there.

Users and analysts will often request an Excel-like interface to data. Some people think that given Excel’s ubiquity this will reduce training. However Excel is a commercial product with hundreds of person-years poured into its code-base. Is the grid you’re using going to be as fast as Excel (given that unlike Excel your data probably has to come from a remote server)? How will your grid handle concurrency (Excel doesn’t have to care about concurrency)? Excel has hundreds of features and tweaks to make editing of tabular data faster - how many of those are you going to implement? Which ones? When Excel v.Next comes out will you rev your application to continue to “be like excel“? If end users want Excel why not just let them use Excel?

When the only tool you’ve got is a hammer, everything looks like a miniature in-line version of Excel. By keeping the data grid off the table for a while the WPF team may have forced people to get a little more creative in how they interract with their data. At the end of the day “it that makes me find creative ways to work around its deficienceis“ is not a great selling point for a framework (although it never seemed to hurt the adoption of HTML) and the WPF team have come to the party and said they will provide a grid. That still doesn’t change the fact that I think they are generally a bad idea.

* There are 3rd party WPF grids from Xceed and Infragistics (both of which are free IIRR).

Comments