Why free software has poor usability and how to fix it

I offer my Haboo community a translation of the article by Matthew Paul Thomas, which he recently published on his blog. Thomas is a programmer from New Zealand who works on the development team for the Launchpad project - the brainchild of Canonical , better known as the commercial sponsor of the most popular Linux distribution Ubuntu .
What is most interesting:
- the first version of this article came out 6 more (!) Years ago.
- most likely, the appearance of the second version was inspired by the recent loud statement by Canonical founder Mark Shuttleworth, in which he invited the free software community to create an operating system interface for the next 2 years that would be “nicer” Mac OS X.
- in the article there is a clear separation between volunteer designers and dedicated designers, while the former do not use the special caress of the author. This is interesting, because judging by the words of Thomas, he is.


Yes, I am not a certified translator, so do not judge me ...

When I wrote the first version of this article 6 years ago, I called it “Why free software has such crappy usability” (this is my translation, in the original Why Free Software usability tends to suck - translation). At the moment, the best open applications and operating systems are more usable than they were then. But this is largely due to the slow development and low level of competition between projects and distributions. The main problems of design in the majority remained unresolved.
')
Many of these issues are not specifically related to free software, but to all programs created on a voluntary basis. Proprietary programs created as a result of a hobby are often difficult to use for many of the same reasons. But the easiest way to get volunteers to contribute to programming is to declare the program open. And since at the moment thousands of people are involved in the development of free software, most of them are volunteers. Therefore, in the world of open source software, we see the usability problems of programs created by volunteers most often.
This gives us the key to the first two problems.

1. Weak incentive. Proprietary software vendors basically make money by producing programs that people like. This is a strong incentive to make them more usable (this does not always work: for example, Microsoft, Apple and Adobe programs sometimes get worse, but still remain dominant because of the bulk. But they work most of the time).
For volunteer projects, however, any incentives are much weaker.
Such an indicator as the number of users rarely influences developers in any financial way, and in free programs it is almost impossible to count the number of users in general. There are other incentives - to make an impression on future employers or to achieve the inclusion of your software product in a popular OS, but these are rather indirect motives.

Solution: create more strong incentives. For example, annual design awards for free software could be announced, which would pay tribute to developers for good design. Software providers could publish statistics on how many of their users use programs, and how this number changes over time. The bonus system could allow people to deposit money to anyone who makes special improvements in usability. And the release management system could contribute to faster competition. Distributors could choose not only which application to release, but also which option to choose from the application branch, considering ease of use as a factor of choice.

2. Few good designers. Some musicians are also good composers, but most of them are not. Some programmers are also good designers, but most of them are not. Programming and developing a user interface are different skills, and people who are equally good in both areas are rare. Therefore, it is so important that software have professional designers. But only a few projects from the world of free software can boast of this. Several usability professionals are hired by free software developers like Mozilla, Sun, Red Hat, and Canonical. But they are few, and it is very difficult to find qualified volunteer designers.

Solution: provide programmers and volunteer designers with easily accessible educational materials to improve the overall level of design knowledge. Educate communities about the need for programmers to collaborate with usability specialists. And encourage free software projects to have a lead programmer, lead user interface designer, reference editor, and quality control engineer on their staff. And it must be different people.
But why in the first place the lack of voluntary designers? The answer to this question leads us to the third problem.

3. Design improvements are often discouraged and disapproved. Free software has a long and useful tradition of “show me the code”. But when someone points out errors in usability, this tradition turns into “patches welcome”, which is useless because most designers are not programmers. And it is not clear how else usability specialists can help in this situation.

Solution: establish a way for usability specialists to participate in the project. For example, a lead designer may publish specifications on a project’s website and induce feedback on a blog, wiki, or mailing list. The designer can kindly respond to suggestions for improving the design (even if they are wrong). A project manager can install an edited bug tracker instead of a cumulative one - making it easier to improve, approve or reject proposals, while paying attention to the implementation of design proposals as well as error reports.
Then why programmers react to suggestions for improving the ease of use of the program is not the same as technical error reports?

4. Usability is difficult to measure. Some qualities of software can be easily and accurately measured: whether it works at all, how quickly it starts, how quickly it works, and whether everything is correct from a technical point of view. But this is only a private replacement for a more important quality that is difficult to measure: is the software useful, how responsive is it, does it behave as people expect, what percentage of people who achieved the goal with its use, how quickly can they use it, and how satisfied after use. These human-dependent qualities can often be measured using custom tests. But it takes hours or days that volunteers don’t want to spend. User tests are usually difficult to interpret, focus on major issues, and leave designers without solid evidence to convince programmers that small problems exist. And even if a problem is identified, a solution must be developed, and for this, tests may also be needed.
Without the frequent use of user tests, volunteer projects rely on the subjective impressions of people who are so passionate about subscribing to the project's mailing list. But what these people say may not be representative even in relation to their own experience of use, let alone ordinary users.

Solution: support low-level custom test technologies that are convenient for volunteers. Develop and maintain the use of screenshots, videos and other software that facilitates testing. Encouraging developers to trust the results of user tests more than just the opinions of users. And to write design manuals that give solutions to common minor problems that cannot be traced by user tests.
The shortage of professional designers, among other things, contributes to three cultural problems in free software projects.

5. First programming, then design. Software tends to become easier to use if, roughly speaking, the design was made before writing code. The desired user interface for a program can affect the data model, the choice of algorithms, the order of operations, the need to use conveyor, the choice of format for storing data on disk, and even the choice of program functionality in general. But it all looks boring, so programmers often just start coding - they will worry about the interface later.
But the more code is written, the more difficult it is to solve design problems — that is why programmers will most likely not worry about this, or convince themselves that this is actually not a problem. And if they finally fix the interface after version 1.0, existing users will be forced to relearn, frustrated and thinking about considering competing programs.

Solution: put in pairs of designers with programmers who want to develop a new project or new functionality. Create a cult in the free software world — design first, then code.

6. Too many cooks. In the absence of professional designers, many project assistants try to participate in the design of the interface, no matter how much they know in this area. And a large number of designers leads to inconsistencies, both in the general vision and in the details. The quality of interface development is inversely proportional to the number of designers.

Solution: projects should have a lead user interface designer who will track suggestions from everyone and work with programmers on how to choose what can be implemented. And more detailed design specifications and guidelines can help prevent program-specific flaws.

7. The pursuit of a sunny bunny. In the absence of their own specific design, many developers believe that what Microsoft or Apple do is a good design. Sometimes it is, but sometimes not. Imitating the design, free software developers repeat their mistakes and forever make it impossible to get a design better than Proprietary alternatives can offer.

Solution: encourage innovative design through contests and other public events. Update existing design guides to display the results of successful design experiments.

There are reasons for poor usability that are not dependent on the availability of professional designers. These problems are more difficult to solve.

8. Its shirt closer to the body. Voluntary developers work on projects and features that interest them, which usually means that they are going to use this software themselves. As developers, they are also advanced users. Therefore, the software, which was intended for general use, is too “geeky” and complicated. And the functions needed by more new or non-advanced users, such as parental control, installation assistant, or the ability to import settings from competing programs, may be abandoned or not implemented at all.

Solution: introduce a cult of simplicity, praising moderate design. Encourage volunteer programmers to oversee the use of their programs by friends and relatives, which will inspire them to solve the problems of other users.

9. Ignoring minor bugs. Many small details that improve the interface of the program, do not cause inspiration or pleasure from working on them. These are details such as setting the most suitable size and position of the window when opening for the first time, focusing on the default settings of the open window, good wording of error messages and other textual information so that they are more useful, or giving progress bar more accurate display of the duration of the process. Since such things do not cause admiration and pleasure, it takes years before they are realized. This gives users a general impression of the wretchedness of the design, and this can discourage the desire to participate in the project from discouraged usability specialists.

Solution: in the process of working on errors, determine how long they exist. It is possible to solve interface errors in the first place, if this can be done quickly. Involve designers in the process of planning bug fixes to guard against gaps in usability that are too low in importance because "yes, it's just a UI bug."

10. Calming people with options. In any software project with a lot of helpers, sometimes there are disagreements regarding design. In the case of hired employees, work usually continues, even if there is inconsistency. But in the case of volunteers, the project leader is likely to agree to reassure the assistant by adding configuration settings. The number, turbidity and banality of such settings embarrass ordinary users, although anyone is punished for inflating the final result and weakening the thoroughness of testing.

Solution: strict project leaders and the cult of simplicity. Release management systems should also help relieve pressure by offering easy support for their own version of the program with the right functionality.

11. Fifteen pixels of fame. When volunteers add new features to popular apps, they expect to be recognized for their work, to be able to show someone on the interface and say "I did it." Sometimes this leads to the emergence of new options or menu items for which a separate interface is not really needed. On the other hand, the removal of erratic or useless functions can cause the anger of the authors-developers.

Solution: Provide alternative publicity, such as a blog, for thanking the participants. Conduct design reviews of those code changes that affect the user interface. Regularly inspect the entire interface, asking yourself: “Do we really need this code?”.

12. Broadband design, low-speed Internet. Volunteer program projects are usually widely distributed among participants from different cities and even continents. Therefore, project collaboration is usually carried out via text, e-mail, instant messaging clients, IRC channels, or an error tracking system. But the collective design is multidimensional, it includes planning and taking into account the behavior of elements in time, the organization of these elements in the entire interface. When developers are in the same room, they can discuss mutual design using presentations, paper prototypes, words and gestures. But on the Internet it is often impossible, making the discussion much slower and leading to misunderstanding.

Solution: develop and promote the use of VoIP, video chats, virtual presentations, sketches and animation software that will facilitate discussion of design ideas via the Internet. And whenever possible, hold real developer meetings for personal collaboration.

Finally, some problems are specific to the development of free software.

13. Release earlier, release more often, get stuck. The common practice of “release earlier, release more often” can cause an accumulation of design errors. When in one version of the program the user performs the operation in one way, which testers follow, then they naturally complain when the next version behaves differently, even if the new version is better. This discourages programmers from improving the interface, and may lead to an increase in the number of incomprehensible configuration settings.

Solution: publish the design specifications as early as possible during the development process so that testers know what to expect in the long run.

14. Mediocrity due to modularity. Free software hackers appreciate code reuse. Often they talk about writing code to perform only a functional, so that other programmers can write a “front end” (or multiple alternative “front ends”) allowing ordinary people to use such code. They consider this important in order to be able to change at any level of the system with the aim of alternative implementation. This is good for the long-term viability of the system, because it avoids dependence on any single component. But it also leads to a lack of integration, which in turn weakens usability, especially if the interface of interaction between the levels of the system was not designed for usability. For example, most terminal commands do not provide information on how complete the process is or do not provide an estimate of how long it will take. This is a traditional behavior in the terminal, but in the graphics software the process mapping is critical. If graphic utilities are designed only as “front end” terminal commands, they cannot easily provide this information.

Solution: first develop a rough graphical interface design, so that the requirements of a low-level interface are known before writing code.

15. Closed developer communities. When you do something on a computer, you depend on programs developed by different development teams. , -, -, -, , , , , , , , , . . , . , .

: - , , . .

, , . , , .