Over the past month or so, I’ve upgraded my wife’s iPad to iOS7 and FireFox to v29. In both cases, it was a major one-way change (to my knowledge, iOS never lets you roll back, and reinstalling an older FireFox is not really an option), with big changeovers:

• iOS7 uses the new flat design, which contrasts to close to a decade of 3D buttons and gizmos, but is more in keeping with Android and Win8’s User Interface (UI) elements.
• Firefox has used fade in/out tabs above the URL line for quite some time, but gave people a hidden setting to change it back to show just above the window. v29 removed that setting, forcing the tabs to the top.

It’s FireFox that mostly prompted this post – today the Missus had to deal with ‘upper-tab’ issues as her upgrade kicked in, where not only did the tabs appear reversed with the bookmark bar, but they fade away when the mouse is not over them.

The problem in a nutshell? Programmers get tired of their visual design long before users.

There is a psychological term for this (which I wish Google was more helpful in finding) but it relates to ‘familiarity breeds contempt’, where user interfaces (among other things) get tiresome for the people directly involved with it long before the average incidental user.

Of course, there are other factors:

• For iOS7, the radical change is understandable when you consider that all competitors were embracing a flat display design. Standing out in this case may involve yielding market share – bad for any company. On the other hand, imitating the others might also cause users to make a choice on other factors (like price) since the ‘look’ is similar.
• Code is cheap only in theory. I know what it is like to carry old dross in code because somewhere, somehow, a user may need that setting. Removing it entirely means less code, less testing, and fewer problems. Boon to programmers (and companies), but changes for users.

How than can we avoid this problem? Simply, we can’t, but there are steps as developers we can keep in mind:

• Build it right the first time. Use proper design principles. For example, one could argue that fading tabs when the mouse is not over them as FireFox does makes for a cleaner interface. However, it reduces information – now your brain has to go one more step to decipher the text as a tab header (and while we’re on the topic, why do tabs look like tabs? For those few people who have actually worked in an office with tab folders – indicating one more item people have to ‘learn’ to use the interface). Likewise, putting the tabs on top saves a few pixels (apparently) – but now the URL and bookmarks toolbar are in between the tab and the page, adding more details to separate two items that should be visually linked (OK, I can see the URL line below the tab, but not the bookmarks, since they are ‘global’ and not related to the current tab). Designing it right for minimizing cognitive effort, and having the strength to stay with the design while everyone else goes for cool-yet-awkward in their UIs, is important.
• Try to keep PR out of the equation. Marketing ideally would like a new product every week, along with twenty variations of it. However, changes add to the development time (code not only written, but tested, including regression testing to make sure nothing has ‘crept back in’), and so there can be significant cost even for a ‘minor’ change.
• Be aware change is necessary. Despite mentioning how you don’t want marketing to run the show, the fact is without sales there is no company. I imagine some diehard iOS programmers in Apple had serious discussions about changing such a fundamental look after fighting for years to enforce it. Still, to be competitive you need to change sometimes.

Change is inevitable – but a little advance thought and sticking to the principle of helping the user maximally is always a good idea, and can make changes much more managable, despite the urge to ‘freshen up’ a stale interface – because I can guarantee there are a lot of people that will prefer the old one, stale or not…