Archive for April, 2016

Archive for April, 2016

UX Stability

Posted on

When I help friends and family with technical issues, or listen to them complain generally about their tech issues, one big theme comes up often: the upgrade treadmill. I don’t just mean that they complain that they have to always buy a new computer (though this is certainly an issue), but when they get a new computer they don’t know how it works. Every time an update for any piece of software installs, they have to learn their system all over again. And they feel like they didn’t really have a great handle on it to begin with.

This, I believe, actually leads to users being less willing to learn in the first place, since they (often rightly) believe that any knowledge they gain will be obliterated by changes to their User eXperience in short order. Software systems are, in this way, very user-hostile.

One way to solve this problem might be to simply not install updates, but this leads to a whole host of issues. The first one technical people will talk about is that not installing updates means your computer is even more full of security holes than usual. Enterprise-focused solutions involve so-called “Long Term Support”, where security fixes are backported to older versions of software for some support window. This can help in the short-term, but faces its own dilemma: if the support term is too short, then users are still upgrading fairly often, and the longer you make the support term, the longer users have to wait for new features and (sometimes) bugfixes.

But wait! Don’t the users not want new features? Isn’t this a good thing? Wrong. Users want updates what they don’t want is change. When Firefox gains the ability to play a new kind of video, users want that, because they want the webpages they visit to work. When Libreoffice improves support for a popular file format, users want that, because they want to be able to open files they get sent. Even straight-up new functionality may be welcome in certain cases. So long as the new feature does not invalidate the user’s existing workflow. This is the key. A user that can trust their workflow will keep working (and you won’t replace all their menus with new menus, or worse, non-menus) is (I think) more willing to learn to begin with. Certainly more happy in the long run.

So keeping a system stable in the way that, say, Debian or RHEL or Ubuntu LTS do is a very useful start, but it’s not the whole story. We need a system that stays the same (or at least, whose core components change very little) while also receiving bug fixes and new functionality. Backporting, from time to time, bugfixes and new features in a way that preserves the user’s experience. For what support window? This is a big task, and starting with shorter timeframes may be needed, but ultimately? Forever. Or for the life of the users at least. A user should never be put into a position where they are forced to re-learn their system just to keep using it. Computers are tools that many people find essential to their daily lives, and there is a duty to provide them with systems that keep working, not just technically, but for the user.

Obviously, we cannot achieve this with proprietary software, so software freedom is an important part of this. And also, we cannot easily achieve it with any application that delivers the UI remotely (such as a “web app”), so native clients for popular web applications and similar technology may be needed in order to be able to provide this kind of stability. This is not a small task that we can accomplish overnight, but I believe it is part of the essential solution to the problems our society faces with their daily computing needs.