Usablity Tradeoff

Software graphical user interfaces are funny things.

For anything you’d like to do there is a whole spectrum of possible interfaces. On each screen, you can have various different types of modes. You can overlay all sorts of navigational paradigms on top. There are plenty of different widgets and lots of different styling tools. When you add up all of the permutations the possibilities feel endless.

But they are not.

For one thing, user interfaces are highly subject to current trends. A new interface either fits in nicely with the ones around it or it clashes. Its alignment may be at the higher levels, often referred to as ‘look’ and ‘feel’, or it can do it at the lower levels with how it uses the underlying widgets.

So, one rather counter-intuitive property of interfaces is that if they are easy to program, then they are hard to use. It’s not a strict tradeoff, but it is pretty close to it.

If you hire a graphic designer, they will make your interface look great.

If you don’t, it is incredibly difficult to make it look great and most people aren’t naturally gifted at doing that, it takes experience. Ugly interfaces increase the cognitive load of the user, they basically have to expend energy to ignore how annoying the thing is. It doesn’t ‘look’ great.

The ‘feel’ part is similar, usually the domain of a UX expert. Really it is how the navigation maps back to the user’s workflow. Obviously, poor or awkward mappings make it harder for the user to get around and do what they need to do. Instead of it being intuitive, they have to constantly remember that for ‘this interface’ they do some weird steps. So again it is an extra cognitive load for the users.

Interfaces with poor ‘feel’ also usually end up needing a lot of training as well. The users can’t just sit down and do what they need to do, instead, it is always a puzzle of some sort. That makes the project longer too.

For any large interface, a lot of work goes into initially setting up the UX, but as more and more functionality gets added, there is also a lot of work in keeping it relevant.

Then we get down to widgets.

Pretty much every platform provides the same basic ones. Some platforms provide even more. They all have an appropriate use. For example, if there is a password widget, then using it instead of a text widget is preferable.

And there are collected paradigms like dynamic trees. Lots of frameworks have some tree support, but they usually only work for small static trees, huge dynamic trees are a lot of work to get correctly implemented. Retrofitting paging back into trees and lists can be painful.

Layouts with widgets are often tricky as well. You can use simple ones. but they don’t look appealing. A good layout that matches a strong graphic design is often a complicated nest of different containers and layout managers, sometimes 3 or even 4 levels deep.

Now it is far easier for a programmer to ignore the graphic design and UX requirements, and toss the widgets around instead of using them properly. As well, it is extraordinarily difficult to sort out the UX mapping issues, as it always requires some foresight into how the application will grow.

So if you were going to produce a really slick interface, it is actually a huge amount of work. If you skimp on that work, it’s not that hard to wire up some widgets that do some stuff, but it will never make the users happy. So, it is a pretty direct tradeoff, just a little different because, for graphic design and UX, you would hire outside help, so it’s not harder in those cases for the programmers, it is just more expensive for the project.