Moving to an Open Source World

User-friendliness

Your browser needs to be JavaScript capable to view this video

Try reloading this page, or reviewing your browser settings

This video segment explains why open source software has a reputation for being hostile to new users, but also dispels much of that reputation by pointing out that user-friendliness among open source programs can be strong and is getting stronger all the time.

Keywords

  • Usability
  • design
  • user interfaces
  • code maturity
  • GNOME
  • KDE
  • localisation
  • installation

About this video

Author(s)
Karl Beecher
First online
25 December 2018
DOI
https://doi.org/10.1007/978-1-4842-4441-8_6
Online ISBN
978-1-4842-4441-8
Publisher
Apress
Copyright information
© Karl Beecher 2019

Video Transcript

[Audio Begins] [0:00:00]

Karl Beecher: As with quality, open source software has a shaky reputation when it comes to user-friendliness, but I might argue that the state of user-friendliness in open source is very similar to that of quality. In other words, I’d say yes, there are reasons why that reputation exists, but it’s an unfair reputation and the reality is more complicated. Once more, there are plenty of examples of user-friendly open source software that compares favorably to a lot of proprietary software. User-friendliness or usability, its more technical name, is a whole engineering field of its own.

So when the program is usable, it’s not just about subjective feelings, it’s also about learnability. That is how easy a user can pick up basic usage. Efficiency, how quickly can a proficient user perform tasks using the program. Memorability, how quickly can users re-establish proficiency after they return to the program. Errors, how many mistakes do users make and how easy is it to recover from them. And satisfaction, how pleasant is it to use the program. And these are all objective criteria of a program that can be measured by observing people using that program.

Similarly, there are all sorts of engineering techniques that programmers can use to make their programs more usable, like reducing interface clutter and grouping related features on the screen, and making navigation simple, and so on. Usability then requires a programmer to design the program with the inexperienced user in mind. However, recall what was said in the previous segment on quality. Open source software is typically available to the public right from its initial conception. The programmer focuses in the early stages of production on getting the program working. Hence, initially at least, open source software is being written by developers for other developers. Usability is not typically a big priority at that point.

The same can be said for installation. Programmers can take in their stride a complicated installation process that most users find frustrating. Again, in the early stages convenient installation of the sort offered by installers and package managers is not a priority early on. Improvements to usability and convenience of use tend to come later in development, once a software is in the working state. Only then might usability become a focus. Thus, early versions of open source software might be hard to use, but because open source software is developed incrementally, later versions can be more usably. Incidentally, the same is often true for proprietary software as well, it’s just that work on those early, less usable versions is done out of sight behind closed doors. With luck, the user only sees the program after usability has been improved.

Usability is something that must be designed carefully into a program as a job that requires skill. In the open source world where so many projects rely on voluntary effort, it’s not always possible to find someone with an expertise. And like documentation, it’s a job that enjoys lesser status among programmers than does writing code. And therefore, the job of making a program usable might land on a programmer who has little of the required expertise. What’s more, it’s easy to produce clean, consistent, well-designed interfaces when design decisions are controlled and concentrated in the hands of a few or maybe even one individual developer. This kind of tight control is a difficult fit in the collaborative open source world.

However, open source software has produced many very usable programs. Gnome and KDE offer excellent interfaces for the Linux operating system. Projects like Open Office and FireFox have their own usability teams. These are projects which are large, diverse, mature, and by the terms of open source at least, manage development relatively closely. That is they don’t match the popular stereotype of open source as being an anarchic free-for-all that ignores the needs of ordinary users. Studies comparing the usability of open source and proprietary software are revealing and tend to show only marginal improvement in proprietary when compared to open source software. For example, one study pitted Linux running a KDE Desktop against Microsoft Windows, whereby participants were observed using the software and then questioned about it afterwards. The findings showed Linux to be only slightly more difficult than Windows. Personally, I find studies like this more revealing about software development itself, when usability is a hard thing to engineer in general. In the best efforts, both commercial proprietary software and voluntary open source software show only marginal differences.

Another usability difference worth pointing out is localization. That is tailoring software to different languages and cultures. In the case of open source software, this is theoretically straightforward since the source code is available to anyone. For example, the words you see in a program’s interface are just text stored in the code. New versions of an open source program supporting additional languages can be produced by translating that text. This is also true for proprietary software, but it takes the vendor time and therefore money to do, which might lead them to target only a limited number of languages and locals. No one outside the vendor can do this work since the code is secret.

So we can draw a similar lesson here as we did with quality. Moving to open source software doesn’t mean the software necessarily becomes harder to use. It could mean having to do some research to find software of sufficient maturity and that pays attention to usability, and it could well mean some ramp up time while you become accustomed to new interfaces. Also, thanks to package managers, installation of open source software these days can be very simple, and the openness of the code makes open source software more easily localizable.

In the next segment, we’ll look at interoperability.

[0:06:15] [Audio Ends]