§ ¶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....
![[VS2005 resource editor property grid]](/blog/images/vs2005res.png "[VS2005 resource editor property grid]")
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:
![[VC6 resource editor button dialog]](/blog/images/vc6res.png "[VC6 resource editor button dialog]")
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
Comments posted:
Yes! Property grids are an abomination. I think another possible factor for their usage is that Visual Studio uses them, most Windows developers use Visual Studio, and they either start picking up Visual Studio's horrible UI practices, or they use Visual Studio as a model for justification. (On the other hand, for some it could have the opposite effect: I hated them completely within five minutes of using Visual Studio.)
stickboy - 20 03 06 - 05:15
Preaching to choir. Amen. Use of Property grids is just plain slack, thoughtless and rude.
ianb - 20 03 06 - 08:10
Property grids can be useful for looking at all the options but gets annoying when I have to use so much of them.
john - 20 03 06 - 12:10
...at least you can sort them alphabetically.
This feature is missing in the german version of vba. If you try to change properties in an access-report you have to search for the german name, but if you change them within vba-code you have to addresses them with their english name - that's weird.
Murmel - 20 03 06 - 12:53
I can understand why they do this. Using property grids is less resource hungry and is much easier to extend than a proper dialog (from a coding state of view).
I also have to disagree with you with regards to doing a proper UI. It doesn't take more CPU to do a proper UI, it really depends on how you implement the UI. In my own program, which has skinning elements and a flexible UI (scriptable), the UI takes nearly zero CPU (pretty much the same CPU as a normal windows app when not doing window resizes).
Blight - 22 03 06 - 16:06
I didn't say proper UI, I said a fancy UI -- creating a usable UI indeed doesn't mean an expensive one.
I would have to disagree with you in general on skinning (disregarding that I don't consider skinning to be essential to a proper UI). If skinning is done correctly and with a lightweight, well-designed skin, then it too need not have any significant impact. However, there are very few applications that do skinning well. Most are bloated and use a lot of image-based and owner-drawn controls. When competition for the CPU is very high or the UI is being rendered over a slow remote connection (remote desktop), the overhead for such an interface is considerable. Generally, the first thing I do when I find that an application is skinned is to look for a way to turn the skinning off or to switch to a "classic" option.
This is, by the way, a major reason I dislike .NET's System.Drawing: it uses GDI+ and thus forces a lot of expensive, non-accelerated rendering.
Phaeron - 23 03 06 - 04:17
haha! I thought I was the only one that hates the property page. One of the things I find very annoying is the Control ID, besides being at the end of the list, it's also affected by the scroll wheel. After I change the ID, I like to scroll up with the mouse wheel to change other properties. But every time I do that, the ID is changed to some other ID. AH!
meanie - 26 03 06 - 23:59
The goofy behavior of the control ID field acting as a list has been bugged already:
http://lab.msdn.microsoft.com/productfee..
I can't think of any good reason whatsoever for the existing behavior. VirtualDub isn't that big of a program, and it probably has thousands of symbolic resource IDs. Navigating that by a one-line field would be ridiculous.
A further problem I've run into is that the dialog editor is nearly unusable without opening and pinning the property pane, but the dialog editor doesn't have its own UI mode like in VC6, so then when I switch to code the property grid sticks around and wastes space. This is really annoying when I'm trying to implement a dialog and have to flip back and forth to copy the control IDs.
I really have to wonder if anyone on the Visual Studio team is actually using this editor. You would think all they would have to do is bring in an MFC developer and watch him working for an hour to see the usability problems.
Phaeron - 27 03 06 - 02:17
If you haven't applied for the VS2003 Service Pack 1 Beta, you might want to do so and add your feedback there (
https://connect.microsoft.com). For VS2005 I think you have to stick with the MSDN Lab for feedback since there is no SP Beta yet.
Derek - 05 04 06 - 05:44
I think what would make the property grid 1000x more usable (especially in VS) is the ability to filter the list on some text. Type "Right" and it will only show those options with the property (or description) containing "Right".
This would help incredibly when changing the same property on multiple controls.
rein - 29 01 09 - 13:34
In Expression Blend there is a filter feature since WPF has so many properties, this increases usability quite a lot. I'm currently building a Visual Studio add-in to just display the most common properties and to add a Blend like filter feature. It'll work only for WinForms however.
Many applications lack usability due to missing search and filter features, ever tried to change key shortcuts in MPC a lot, I have much respect for Gabest's filter development but his UIs are amateurish.
The PropertyGrid, the design time evironment and reflection are valuable tools when used appropriatly, it's just many people abuse it. In most cases when the property grid is used there aren't just real properties in a class, there are several classes, interfaces, attributes etc. to add and remove/filter properties dynamically. Take a look at TypeDescriptor, TypeConverter, TypeDescriptionProvider, ICustomTypeDescriptor, PropertyDescriptor for instance, this stuff can safe a hell of code and work and provide incredible power and flexibility.
stax - 13 03 09 - 15:25
Filtering is not a good way to resolve the usability issues of the property grid. It would make it slightly less painful, but you're still talking about a lot more work for the user to do than just selecting a control from a well-sorted category. It also requires combining the keyboard and the mouse, which I also consider a poor idea.
Phaeron - 13 03 09 - 23:29
You are right of course about the usability issues, there are custom property grid's that support option boxes btw. This one for instance:
http://www.visualhint.com/index.php/blog..
Here is a WPF Blend like with Search/Filter feature and the caption is right aligned which also might improve usability:
http://www.codeplex.com/wpfpropertygrid
Generic or dynamic solutions like the property grid or the options tree view in VirtualDubMod or StaxRip lack always usability wise but it can save a lot work and code and enable features only possible with a dynamic solution, the saved time can than be spent on things more important.
In StaxRip I tried my best to build a nice x264 dialog with sliders etc. since many users like x264, I've completely changed the x264 dialog 3 times just to ensure it don't suck. For H.264 DivX I didn't want to spent more than a hour work and a couple of lines code building a dialog so I decides to make a quick and dirty dialog using a option tree view which is a single line code for every option only. Saved time can be spent to enjoy the nice weather for instance :)
stax - 14 03 09 - 09:56
