Site Archive (Complete)
Architecture Blog: UI Changes
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
July 12, 2006

UI Changes

Don't invest too much in UI without validating it against actual users. More often than not users don't understand what they really want before they get to play with a system. You don't need to validate each and every screen that the system will have. Far from it. What is important is to set the system's "UI Experience."

By "UI Experience" I mean the way users interact with the system as a whole (idioms used, keyboard shortcuts for yes/no items, is the UI built for experienced users or for occasional users?, and so on).

Craig Bailey left a comment on my blogpost on refactoring, offering "maxfactoring" for UI refactoring. While this is an interesting idea, my experience shows it is easier said than done and there's a lot of effort changing UI overall behavior (i.e., more than just simple cosmetics) after you have many forms/pages up and running.

The other option is to create a UI prototype up front. A UI prototype means you code the bare minimum that is needed to give the users the user experience intended. You can also use whiteboard/paper prototypes as an to help make the UI prototype focused on promising directions also it is worthwhile to look at tools like EasyPrototype which lets you take your paper prototypes to another level (take a look and see).

Another thing that can help with easing UI change pains is applying patterns like Model-View-Presenter (MVP) or (the older) Model-View-Controller (MVC). The idea behind these patterns is to remove all code (except the one that has to do with formatting the view itself ) away from the view (the form/web page). If you augment this with making the Presenter only depend on an interface of the view you can also greatly increase the testability of the UI (as you can mock the views) and make the UI changes easier (due to the decreased dependency).

Thus, the UI experience, just like the system's quality attributes mentioned in the previous post, is another area where it is important and worthwhile to spend some design up front to help build a higher quality system--and do it faster (overall).


Posted by Arnon Rotem-Gal-Oz at 08:24 AM  Permalink




 
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies