This post originated from an RSS feed registered with Agile Buzz
by Jimmy Nilsson.
Original Post: Don't cheat with the user interface
Feed Title: Jimmy Nilsson's weblog
Feed URL: http://www.jnsk.se/weblog/rss.xml
Feed Description: Patterns, OO, DB, .NET, ...
It's a paradox that many developers who have a large interest in design and maintainable applications often say something like:
"Anyone can take care of the UI, it's not possible to do that much damage there anyway."
Part of the paradox is that the largest amount of code, the ugliest and therefore also the largest maintenance problem, has a tendency to end up in the user interface (UI).
Another part of the paradox is that the success of an application largely depends on the user experience. Sure, the better the code/design is that the UI consumes, the larger the chance that the UI can also be good. But it doesn't
happen by itself that the UI code becomes good. In fact, it's often the opposite.
You might recognize some of these examples.
The rendering of UI and logic has been mixed into a soup. When the rendering is to be swapped, it's clearly obvious that the logic is affected too.
In the large application the logic has been split in different parts - in a good way. For example in accordance to how often they change. The exception is the user interface that is one single monolite where it's very hard to
change the different parts separately.
After a lot of pain and effort, the team is gaining a lot from automatic testing. Except for the user interface. Unfortunately it often needs refactoring and thereby needs the safety net that automatic tests provide.
Good design is used in the domain model, for instance, so that with little code and right abstractions it successfully describes the solution to the problem. But the user interface is done in a "brute force" way, almost totally
without abstractions.
Most developers are resilient sorts, but I don't think we should accept what we get from the tool vendors as-is. Tools should often rather be seen as platforms that can be used to develop specific frameworks on top.
If you do as the vendor proposes, you can often expect verbosity in the code and large, hard to maintain codebases. Most often, the vendor hasn't eaten its own dog food. It's not until the tool is used in real projects that the
experience and knowledge of what is good and bad emerges - and how the good is used in an effective way.
An indication of the problem is that to most developers design means quite different things, such as in the domain model and the user interface. Of course good software development design in the UI as well is extremely useful
(and not only "look-and-feel"-design)!
The user interface has always been important, but has often been treated as the poor relation. The largest maintenance bottleneck is often found in the user interface. Now and in the future, that area requires and deserves to
receive a lot of focus.
An interesting approach is framework oriented user interface development. It's anything but trivial to do well. Yet the potential is enormous!
(First published in Swedish as a developer chronicle here.)
Previous Topic
