¶Property grids

I don't write very fancy UIs; those of you who use my program probably already know this. The main reason for this is that I tend not to put a whole lot of time into making them fancy, because for me it has a low return for the amount of time I have to invest in it. Also, I'm not interested in spending a whole lot of CPU power on one either — why slow down a capture or a render with a UI that takes a lot of clock cycles to redraw? I do have one rule about UIs, though, and that's to use combo boxes very sparingly. Preferably not at all in new UI. Combo boxes take too many clicks, since you have to either waste a click for the drop-down or drag awkwardly X11-style, and I find that listboxes or lists of options look better and are easier to use. That's why in most of VirtualDub's more recent dialog, you see a lot of option sets instead.

And then, in the .NET Framework WinForms library, there is... the property grid.

A property grid is a generic UI widget that displays lists of properties, which can have values of type text, boolean (true/false), or even custom ones like colors. Properties can be separated into groups, and there are buttons to allow the user to sort the list of properties. There is also a pane at the bottom that holds help text for the property.

After using several .NET WinForms-based programs that use property grids, I've now come to a conclusion: I hate property grids. I hate them enough that I think they deserve a Joel Spolsky level rant and should be abolished from production UI.

Now, you might think... why does he hate property grids so much? Well, as an example, take the Visual Studio 2005 resource editor....

This is how options for a button are displayed. VS2005's resource editor, like the older VS2002/2003 resource editor, uses property grids for changing the appearance and behavior of controls in a Win32 dialog. Why does this UI suck so much?

• It's a homogeneous brick of text. At a glance, I can't find anything in it and have to read each line until I find what I'm looking for. Even worse, the property dialogs for the different types of controls all look the same. One time I couldn't find what I was looking for and kept searching, until I realized I had the dialog selected instead of the button.
• It uses scrolling. No, wait, it almost always requires scrolling. Even when I have it docked on the side of a maximized IDE window on a 1920x1200 display.
• The properties are alphabetized instead of ordered in frequency of usage. The two most common buttons in a dialog do not have bitmaps, unless you are using a Borland language. The control ID is at the bottom of the property list, under the "Misc" category.
• Boolean properties are displayed as True/False instead of Yes/No or even the obvious checkbox. If you click in it expecting it to toggle, what you get instead is a flashing caret, but you can't actually type anything. What you actually have to do is either click the arrow that suddenly appears and select True or False from a drop-down list, or double-click as a shortcut.
• The property grid is wasteful of screen space. Why is help always displayed? I know what a caption is and I could hit F1 for help if I didn't.
• Keyboard navigation is horrible. Pressing up-arrow and down-arrow scrolls through the properties, and F2 edits the property... but space doesn't change a boolean parameter. Up-arrow and down-arrow does. But now you can't use the arrow keys or page up/down to navigate to other properties. Shift+Tab works, but is not easy to hit.
• There are no accelerators for any of the properties. If the selected property in the dialog above were Bitmap, you might think that hitting S would start an incremental search starting at Simple... but no. It moves the focus to the boolean False text that I can't edit.
• It displays useless information. Apparently, Visual Studio uses an interface called IButtonEditor as part of its Win32 resource editing code. I care because...?

Now, here's the equivalent button editing dialog from Visual C++ 6.0's resource editor:

Smaller. Leaner. Visually heterogenerous — no chance of confusing the Visible checkbox with the Caption text edit, even at a glance. Stuff that always has to be tweaked on first tab, stuff that sometimes has to be tweaked on other tabs. And has support for keyboard navigation.

Now, you might think this is just the fault of the Visual Studio 2005 resource editor. But no, the C++ Project Properties panel was similarly changed from a dialog to an annoying property grid. And I see property grids pop up in lots of UI in other .NET WinForms-based programs, with all the same sorts of usability problems: hard to read, hard to use, wasteful of screen space, mixed-heap-o-mostly-useful-and-mostly-useless options. I cannot think of a case where a UI that uses a property grid couldn't be improved in usability by replacing it with a panel of regular UI widgets, tabbed if necessary. And my hatred of property grids has nothing to do with it effectively making every property into a combo box.

Having written a little bit of C# code, I also know why the property grid is used as much as it is: it's easy. You just create a set of properties in a class with suitable attributes, and then attach an instance of the class to the property grid, and you magically have an interface. Change the class, and the property grid changes along with it. Unfortunately, I think the amount of time saved coding is not nearly justified by the horrible user experience. (I also wonder how you localize it.)

Appendix: Not about property grids, but while I'm talking about the resource editor....

In VC6, double-clicking a control brings up its options dialog. In VS2005, it brings up the Add Class dialog, defaulted to the CLR category and adding a WinForm-based class. Because attaching a .NET WinForms-based class to a Win32 button in an .rc file in an native project is so much more useful than displaying button properties....

VS2003 had a serious bug with randomly corrupting symbolic IDs to hardcoded numbers in .rc files. Supposedly that's fixed in VS2005; it was going to be postponed until post-ship, but the suggested workaround was bogus and the fix seemed to go in pretty quickly after the votes on the bug on the MSDN Product Feedback Center shot up past 15 in a short time....

String tables and menus are places where the VS2003/VS2005 resource editor experience is actually better than in VC6, because you can type in the strings in-place rather than having to bring up a dialog for each one.

Between VS2003 and VS2005, the C# project settings were moved from a property grid in a dialog to a document page with tabs and regular style checkbox/edit/combo widgets. That it's a document is weird, and the spacing is goofy enough that it looks like a goofy web page instead of a dialog (maybe it is a web page?), but it's a step in the right direction. Unfortunately, the C++ project settings didn't make a similar move.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.