Apart from the, seemingly obvious, requirement that a UI has pleasing aesthetics and meaningful mechanics along with features that let the user feel in control, there is also a requirement that the technical foundation is sound. The term “polishing a turd” is sometimes fitting when it comes to software.
A very common principle of software design is separation of presentation and data. This made a lot of sense in the good old days when you would need to write your own combobox (drop down list). It would be completely insane to put the code to store a value on a server inside the combobox code; if you did, your combobox would be good for one purpose only. Today, we create standard comboboxes without even considering the amount of code behind it. We re-use the combobox to show vehicle makes, user types, colors and so on.
But how far should this principle be pushed?
Say you have a popup dialog, is it OK to write the “store on server code” in the OnClick handler of the OK button? I think it is a bad idea; the dialog is a representation of some known object, I’d much prefer that the code to save the object to a server is part of the class, and so the OnClick simply calls “dataobject.Save()”
The principle can be pushed even further, but this is where I start to get uneasy. Say you have a object that represents an account. The account has various attributes such as name and password. The access to the data happens through what is sometimes called a Controller, a Presenter or a ViewModel. The idea is that the controller adds and additional layer of information that pertain to the presentation. Say you change the account-type attribute to “guest”, then we might want to disable the “create account” button. To make this happen, the controller tells the view that the “IsCreateAccountEnabled” attribute has changed when the account type changes.
This allows you to write automated tests that check to see if IsCreateAccountEnabled truly becomes false when the account type is “guest”.
The fantasy is that you can then give the controller to an awesome UI designer who will wire the different things together and it will all be cool. But here’s the catch. What if changing the user type to “admin” required a roundtrip to the server which could take seconds? Suddenly, when you click the dropdown box, you have to wait for the server to respond. You did not expect that a dropdown would cause a 1 second holdup, locking the UI. You click again, before the UI becomes responsive. Windows will queue that mouseclick, causing a second roundtrip to trigger, and waste another second of your life. Why on earth did the designer not take this into consideration?
How would the designer know that setting accounttype to “admin” would take 1 second? Nothing in the controller tells the designer that the accounttype attribute is “slow”. Perhaps the designer should assume that all attributes are slow. But really? Is that what we should do? There is a cost to making things asynchronous, and a lot of designers won’t know how to wire things that happen asynchronously.
The same applies to arrays. Unless the designer knows a) How long the array is expected to be, and b) how frequently the array changes, and c) how long it takes to modify the array, then the UX is dependent merely on luck.
A truly awesome UI requires that the designer and the developer talk to each other every single day. It requires that the designer understands what arrays will be “long”, what side effects there are to every attribute being set and so on. In essence, what I am saying is that there is a much strong dependency between the data, the controller and the view, and that software-shops need to take that into consideration.
Prescienta's Blog 