What does a WinForm application need to be designed for usability, and be robust, clean, and profess
- by msorens
One of the principal problems impeding productivity in software implementation is the classic conundrum of “reinventing the wheel”. Of late I am a .NET developer and even the wonderful wizardry of .NET and Visual Studio covers only a portion of this challenging issue. Below I present my initial thoughts both on what is available and what should be available from .NET on a WinForm, focusing on good usability. That is, aspects of an application exposed to the user and making the user experience easier and/or better. (I do include a couple items not visible to the user because I feel strongly about them, such as diagnostics.)
I invite you to contribute to these lists.
LIST A: Components provided by .NET
These are substantially complete components provided by .NET, i.e. those requiring at most trivial coding to use.
“About” dialog -- add it with a couple clicks then customize.
Persist settings across invocations -- .NET has the support; just use a few lines of code to glue them together.
Migrate settings with a new version -- a powerful one, available with one line of code.
Tooltips (and infotips) -- .NET includes just plain text tooltips; third-party libraries provide richer ones.
Diagnostic support -- TraceSources, TraceListeners, and more are built-in.
Internationalization -- support for tailoring your app to languages other than your own.
LIST B: Components not provided by .NET
These are not supplied at all by .NET or supplied only as rudimentary elements requiring substantial work to be realized.
Splash screen -- a small window present during program startup with your logo, loading messages, etc.
Tip of the day -- a mini-tutorial presented one bit at a time each time the user starts your app.
Check for available updates -- facility to query a server to see if the user is running the latest version of your app, then provide a simple way to upgrade if a new version is found.
Maximize to multiple monitors -- the canonical window allows you to maximize to a single monitor only; in my apps I allow maximizing across multiple monitors with a click.
Taskbar notifier -- flash the taskbar when your backgrounded app has new info for the user.
Options dialogs -- multi-page dialogs letting the user customize the app settings to his/her own preferences.
Progress indicator -- for long running operations give the user feedback on how far there is left to go.
Memory gauge -- an indicator (either absolute or percentage) of how much memory is used by your app.
LIST C: Stylistic and/or tiny bits of functionality
This list includes bits of functionality that are too tiny to merit being called a component, along with stylistic concerns (that admittedly do overlap with the Windows User Experience Interaction Guidelines).
Design a form for resizing -- unless you are restricting your form to be a fixed size, use anchors and docking so that it does what is reasonable when enlarged or shrunk by the user.
Set tab order on a form -- repeated tab presses by the user should advance from field to field in a logical order rather than the default order in which you added fields.
Adjust controls to be aware of operating modes -- When starting a background operation with, for example, a “Go” button, disable that “Go” button until the operation completes.
Provide access keys for all menu items (per UXGuide).
Provide shortcut keys for commonly used menu items (per UXGuide).
Set up some (global or important or common) shortcut keys without associating to menu items.
Allow some menu items to be invoked with or without modifier keys (shift, control, alt) where the modifier key is useful to vary the operation slightly.
Hook up Escape and Enter on child forms to do what is reasonable.
Decorate any library classes with documentation-comments and attributes -- this allows Visual Studio to leverage them for Intellisense and property descriptions.
Spell check your code!
What else would you include?
