This seems like a great time to subscribe my RSS !

Some days ago I stumbled on an old post of Matthew Paul Thomas, Canonical employee: Why Free Software has poor usability.

Disagreeing on about everything written in there, I decided to pull out a long reply to each one of the points made. Of course, that’s not really a direct response to him, but more an occasion for a general reflection.

USABILITY: will there be light at the end of the tunnel ?

USABILITY: will there be light at the end of the tunnel ?

From time to time, people jump up and say that free software usability suck. That’s sometime true. I should also note that I’m writing this post using Mac OS X (often considered a champion of usability), and that sucks also, I assure you.

Since the original post is quoted almost interely, you don’t need to read it. But if you have time on your hands, it may a pretty good idea to read it first.

I also apologize in advance for picking up little projects as examples, I just preferred to talk about my experience and how I perceive the experience of people I know.

What follow in the quotations, are the point raised by Matthew, which I reply on a one per one basis. This is a very long post, feel free to tell me if you could read until the end of it, so I have my chance to not believe you. (WARNING: LOLcats randomly added to enhance usability)

Weak incentives for usability. Proprietary software vendors typically make money by producing software that people want to use. This is a strong incentive to make it more usable. (It doesn’t always work: for example, Microsoft, Apple, and Adobe software sometimes becomes worse but remains dominant through network effects. But it works most of the time.)

With volunteer projects, though, any incentive is much weaker. The number of users rarely makes any financial difference to developers, and with freely redistributable software, it’s near-impossible to count users anyway. There are other incentives — impressing future employers, or getting your software included in a popular OS — but they’re rather oblique.

Solutions: Establish more and stronger incentives. For example, annual Free Software design awards could publicize and reward developers for good design. Software distributors could publish statistics on how many of their users use which programs, and how that number is changing over time. A bounty system could let people pay money in escrow for whoever implements a particular usability improvement. And distributed version control could foster quicker competition: distributors could choose not just which application to ship, but also which variant branch of an application, with usability as a factor in their choice.

Tipically hard core programmers don’t pay much attention to design, they either expect people to kick in when the moment comes or simply are not interested. Bounties would solve nothing (there are already websites for bounties and they are so cheap to mean almost nothing, community rewards are not going to make it any better.

Google Summer of Code are a good implementation of the bounty idea. Guess what ? The initiative costs millions of dollars.

One thing is right: there’s not much money in the majority free software projects. You want a good incentive ? When someone does a usable software hire him (google cache). That will set an example and well help raising the standards.

Few good designers. Some musicians are also great composers, but most aren’t. Some programmers are also great designers, but most aren’t. Programming and human interface design are separate skills, and people good at both are rare. So it’s important for software to have dedicated designers, but few Free Software projects do. Some usability specialists are employed by Free Software vendors such as Mozilla, Sun, Red Hat, and Canonical. But there aren’t many, and skilled volunteer designers are even harder to find.

Solutions: Provide highly accessible training materials for programmers, and volunteer designers, to improve the overall level of design competence. Foster communities that let programmers collaborate with usability specialists. And encourage Free Software projects to have a lead programmer, a lead human interface designer, a help editor, and a QA engineer, these being separate people.

Good design is not precise science, no matter what some people say.  There may be guidelines, but they get repeteadly violated by successful programs. How many guidelines does Gnome-Do infringes ?Which non-yet-formalized principles does it adheres to ? Another use case is XMMS, which was totally inconsistent with practically any desktop environment known,  but had a huge following for years and years (and years).

Also one of the problems of design is the lack of people and of time. This point is not solvable yet. You need to expand the reach of your communities and grow the number of their contributors. The better is the job that Linux does at reaching non-technical people the more people with non-strictly-developmental skills it will attract. Rephrased: Ubuntu is more likely to attract skilled designers than Gentoo, for example. Mac still attracts better designers than Ubuntu.

Make it easy for non techs.

But why is there a shortage of volunteer designers in the first place? That brings us to the third problem.

Design suggestions often aren’t invited or welcomed. Free Software has a long and healthy tradition of “show me the code”. But when someone points out a usability issue, this tradition turns into “patches welcome”, which is unhelpful since most designers aren’t programmers. And it’s not obvious how else usability specialists should help out.

Solution: Establish a process for usability specialists to contribute to a project. For example, the lead designer could publish design specifications on the project’s Web site, and invite feedback on a Weblog, wiki, or mailing list. The designer could respond courteously to design suggestions (even the misguided ones). And the project maintainer could set up an editable issue tracker, instead of an append-only bug tracker — making it easy to refine, approve or decline, and prioritize implementation of design suggestions in the same way as bug reports.

Well, I’m not sure many developers would ask a patch to a non technical person, by the way: the patch welcome is the slang for sorry, I’m busy. It simply indicates developer has no time (or good will) to handle the coding part himself.

Gedit, for instance, is an awesome editor included by default in Gnome. It has a long history, is very stable and pretty good for most uses. But how many people really contribute to it ?They’re an handful of people, not more. If you enter their chatroom and ask for a feature (even a massively requested one), the most likely response is “Hey, that’s not hard, why don’t you give a shot to it yourself ?”

The first version of rapache used to let you create a virtual host with (exactly) 2 keystrokes (+ typing the name): ctrl+n, type a domain name (textbox already focused) and press Return. With refactoring that feature went away. That’s not a usability bug, that’s a regression. When the development will resume again that feature is likely to be the last to be fixed. Sometimes, there are more important things to do.

Solution: check what you really lack. You lack usability experts or just development work force ? Increase the number of technical people or at least appoint someone to responsible for implementing the UI stuff. Setting up wikis and stuff is unuseful until you don’t get the workflow.. flowing. Not always the lack of design is just because the lack of designers.

Also, a good solution for devs being dicks: the stick, the whip, or even better the fork.

So why do programmers respond differently to usability suggestions than to more technical bug reports?

Usability is hard to measure. Some qualities of software are easily and precisely measured: whether it runs at all, how fast it starts, how fast it runs, and whether it is technically correct.

But these are only partial substitutes for more important qualities that are harder to measure: whether the software is useful, how responsive it feels, whether it behaves as people expect, what proportion of people succeed in using it, how quickly they can use it, and how satisfied they are when they’re finished.

These human-related qualities can often be measured in user tests. But doing that takes hours or days that volunteers are unwilling to spend. User tests are usually low-resolution, picking up the big problems, but leaving designers without hard evidence to persuade programmers of the small problems. And even once a problem is identified, a solution needs to be designed, and that may need testing too.

Without frequent user testing, volunteer projects rely on subjective feedback from the sort of people devoted enough to be subscribed to a project mailing list. But what these people say may not be representative of even their own actual behavior, let alone the behavior of users in general.

Solutions: Promote small-scale user testing techniques that are practical for volunteers. Develop and promote screen capture, video recording, and other software that makes tests easier to run. Encourage developers to trust user test results more than user opinions. And write design guidelines that give advice on the common small problems that user tests won’t catch.

Good solution for  a big project.

Impratical for a little one, it just deviates energies from developing. If your little project (few developers) has a large user base, open a Wiki or a Forum and encourage software users to mess with it and propose mockups. Make it clear with them that they will discuss primarily with other users, and only get the devs into the discussion when large consent is reached on something. If you’re lucky enough a good leader may emerge.

The lack of dedicated designers, in turn, contributes to three cultural problems in Free Software projects.

Coding before design. Software tends to be much more usable if it is, at least roughly, designed before the code is written. The desired human interface for a program or feature may affect the data model, the choice of algorithms, the order in which operations are performed, the need for threading, the format for storing data on disk, and even the feature set of the program as a whole. But doing all that wireframing and prototyping seems boring, so a programmer often just starts coding — they’ll worry about the interface later.

But the more code has been written, the harder it is to fix a design problem — so programmers are more likely not to bother, or to convince themselves it isn’t really a problem. And if they finally fix the interface after version 1.0, existing users will have to relearn it, frustrating them and encouraging them to consider competing programs.

Solution: Pair up designers with those programmers wanting to develop a new project or a new feature. Establish a culture in Free Software of design first, code second.

Bad solution: first do something worth, then ask help.

When I created the Rapache project, I did a 0.1 version. It had only 1 feature but was fully functional: you could add and remove virtual host (not even edit). Then a guy showed up and offered to help. The first thing he told was that the editing window needed some love.

The same guy also created a little project, Ear Candy. Once it reached a decent functionality, a guy popped up in the bug tracker proposing to replace the ugly icon. And I also could convince another guy to make a second icon proposal. Ear Candy not only works, but will have a nice icon soon.

You really get the idea. Those are little examples from little projects, but pretty much every project starts small.

Those are little examples, but give you the idea.

Too many cooks. In the absence of dedicated designers, many contributors to a project try to contribute to human interface design, regardless of how much they know about the subject. And multiple designers leads to inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

Solution: Projects could have a lead human interface designer, who fields everyone else’s suggestions, and works with the programmers in deciding what is implementable. And more detailed design specifications and guidelines could help prevent programmer-specific foibles.

Agreed, a good leader helps. Provided you can find one.

Chasing tail-lights. In the absence of a definite design of their own, many developers assume that whatever Microsoft or Apple have done is good design. Sometimes it is, but sometimes it isn’t. In imitating their designs, Free Software developers repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.

Solution: Encourage innovative design through awards and other publicity. Update design guidelines, where appropriate, to reflect the results of successful design experiments.

Highly agree with not-copying.

Also agree with the awards, but not really for Usability. One heavily voted Brainstorm idea was to promote a DeviantArt contest to create a new Ubuntu theme. Some attempt to implement the idea has been done, but nothing really convincing enough.

If the community has not enough graphical designers, trying to reach users outside the community itself digging in the proper niches may do a lot of good.

One of my ideas for Memaker was to sacrifice a bunch of pixels on the main window to allow the link to the homepage of the Avatar theme author. Recognition is a strong incentive, which may lead to reputation or monetary benefit for the authors of great stuff. Why not ? Shipping the link of your homepage to 8 million of desktops may be appealing for talentuous people struggling to get their work noticed.

I don’t see how the concept may apply to usability, though. The world’s full of usability experts, just they’re usually working for money on non-FOSS software and ften(o) websites. And I really don’t see how they may be interested in such awards. That’s probably just my fault though, as I am not an usability expert of any kind, so yes, maybe is possible.

Other reasons for poor usability exist regardless of the presence of dedicated designers. These problems are more difficult to solve.

Scratching their own itch. Volunteer developers work on projects and features they are interested in, which usually means software that they are going to use themselves. Being software developers, they’re also power users. So software that’s supposed to be for general use ends up overly geeky and complicated. And features needed more by new or non-technical users — such as parental controls, a setup assistant, or the ability to import settings from competing software — may be neglected or not implemented at all.

Solutions: Establish a culture of simplicity, by praising restrained design and ridiculing complex design. And encourage volunteer programmers to watch their friends and families using the software, inspiring them to fix problems that other people have.

Ridiculing won’t take you anywhere. Simplicity is a value, but also a limit in many ways. Gnome has been ridiculed for being too simple, so.. not sure who ridicules who.

True simplicity is packing the necessary features (usually: a lot!) in a seamless and non-intrusive way, and it’s usually technically difficult (don’t worry, GTK makes it even harder).

Simplicity is not excuse for laziness or for enforcing limits. In some websites usability shines. Wonder what ? That’s because of the flexibility of html. Consistency itself comes at a price, sometimes higher than the value it brings.

Leaving little things broken. Many of the small details that improve a program’s interface are not exciting or satisfying to work on. Details like setting a window’s most appropriate size and position the first time it opens, focusing the appropriate control by default when a window opens, fine-tuning error messages and other text to be more helpful, or making a progress bar more accurately reflect overall progress. Because these things aren’t exciting or satisfying, often years go by before they get fixed. This gives users a general impression of poor design, and that may in turn discourage usability specialists from contributing.

Solution: When scheduling bug fixes, take into account how long they will take, possibly scheduling minor interface fixes earlier if they can be done quickly. Involve interface designers in this scheduling, to guard against usability flaws being downplayed because “it’s just a UI issue”.

I mostly agree on this (given the right time-workforce constraints)

Oversimplified UI

LACK OF OPTIONS. That's how you feel.

Placating people with options. In any software project with multiple contributors, sometimes they will disagree on a design issue. Where the contributors are employees, usually they’ll continue work even if they disagree with the design. But with volunteers, it’s much more likely that the project maintainer will agree to placate a contributor by adding a configuration setting for the behavior in question. The number, obscurity, and triviality of such preferences ends up confusing ordinary users, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.

Solution: Strong project maintainers and a culture of simplicity. Distributed version control may help relieve the pressure, too, by making it easier for someone to maintain their own variant of the software with the behavior they want.

I agree on strong leadership. As noted before, avoiding too much options may be good, but progressive disclosure may help more and should be implemented where possible. A rich preference dialog is not a problem if the software ships with *sane* defaults and the common user is not forced to ever open it.

Pidgin faced a fork for not implementing a, largely non-needed, option. They walked their own steps back and implemented it. And explained.

Carrier Instant Messenger is a GUI fork of the popular open source client Pidgin which allows instant messaging with over twenty different protocols.

What makes us different from the official client, is that we work for you. Unlike the Pidgin developers, we believe the user should have the final say in what goes into the program. (from:

Simplicity is a word that makes for (often just) a good rap, but what are really needed are smart solutions and sane defaults. Sometimes you just have to let the people mess with their preference windows.

  • Firefox come with about:config
  • Compiz ships a great configuration panel. It can be confusing at first, but let’s you do everything you want. They’ll probably re-organize it one day, but remove even one option from it and you’ll face revolt.

Distributed version control may be a solution, but maintaining different versions is pain nonetheless. In some cases a plugin architecture may do wonders. Creating a plugin architectures is a pain, and a generic plugin library may be help so much (look ma’! Mono has one).

I’ll reiterate, the lack of usability in most cases derives from the lack of development time. While it’s obvious that having usability guy around and good planning may help, it’s really about time and effort. That said, undertaking the pain of maintaining multiple versions around is going to likely decreasing the usability in reason of the highly increased effort.

Fifteen pixels of fame. When a volunteer adds a new feature to a popular application, it is understandable for them to want recognition for that change — to be able to point to something in the interface and say “I did that”. Sometimes this results in new options or menu items for things that should really have no extra interface. Conversely, removing confusing or unhelpful features may draw the ire of the programmers who first developed them.

Solutions: Provide alternative publicity, such as a Weblog, for crediting contributors. Establish design review of code changes that affect the human interface. Regularly review the entire interface, asking “Do we really need this bit”.

That doesn’t really work for usability, I fear. But could be a good try, anyway. Something to add to your resume – at least.

Design is high-bandwidth, the Net is low-bandwidth. Volunteer software projects are usually highly distributed, with contributors in different cities or even different continents. So project communications are mostly plain text, in e-mail, instant messaging, IRC, or a bug tracking system. But interaction design is multi-dimensional, involving the layout and behavior of elements over time, and the organization of those elements in an overall interface.

When developers are in the same room, they can discuss interaction design using whiteboards, paper prototypes, spoken words, and gestures. But on the Internet, these often aren’t available, making discussions much slower and prone to misunderstandings.

Solutions: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet. And whenever possible, hold physical meetings for developers to collaborate in person.

Good tools makes up for good software. Developing those tools first hand is something out of reach for most.

Launchpad did much good to the community. Still, it’s proprietary, and we’re still waiting. There are important things left off, that may help. Integrated Wikis, sketchboards and stuff. Free the Launchpad, and the tools will come.

VOIP is pretty nice, but I don’t thing it really scales if people are many. Or in different timezones (ask me how many 4am coding nights I did. My project mate was in New Zeland)

Releasing is the very start to make everything happen

RELEASING is the very start to make everything happen

Finally, a few problems are specific to Free Software development.

Release early, release often, get stuck. The common practice of “release early, release often” can cause poor design to accumulate. When a pre-release version behaves a particular way, and testers get used to it behaving that way, they will naturally complain when a later pre-release version behaves differently — even if the new behavior is better overall. This can discourage programmers from improving the interface, and can contribute to the increase in weird configuration settings.

Solution: Publish design specifications as early as possible in the development process, so testers know what to expect eventually.

How do I say it nicely ? .. Bullshit.

This is not really how things work. That’s corporate reality, not FOSS. Most applications have the strong need to proof useful before they can attract contributors. Without contributors you’re not going anywhere, unless you’re Canonical (which has paid developers).

Releasing often is the key for not getting stuck. How many complete redesigns failed ? Was it because the released too often before ? :-)

Also the Vista failure should teach us something (no wonder Windows 7 was a public RC and – mind – early versions used to had big business value for Microsoft).

Also the work-flow of paid developers is totally unsustainable by unpaid developers.  There are many factors, motivation, team coordination, people expectations that you simply can’t ignore. Simply put: if you have 30-60 minutes of free time at night, you should be able to get something done and make it worth to be seen by your team members and possibly your (bleeding edge) users.

While a more organized work may sometimes be better, it’s not something you can afford very often. Koan of the day: notify-osd has been early released or not ?

Release early and often is also a key principle of Google. I don’t see them being stuck in anyway.

Let me bring a pair of case studies for this, everybody loves them, right ?
(what follows is my own opinion, not opinion of the guys cited)

1 – Ubuntu Wanted: code talks

I’ll make a use case basing on my understanding of Qense‘s experience. I’m taking the liberty to write about it because I’m in good relationship with him, because he sort of acknowledged some mistake, and also because he’s in Paris right now, so he won’t notice. ;-)

Qense had a great idea (also ironically sort of related with the topic of this post), but failed at understanding that asking for help before having something working usually leads to nothing. He did the decent enough blueprint, IRC planning, he planned the code structure and even rewrite it at least once etc. Still no or little contributions. The project is still alive, sort of, but not released, not used by end users, not nothing. Some great people decided to help, but how much gets done, in how much time ?

Free Software is not made of companies. Code talks, bullshit walks. There’s no way to attract contributors basing on great ideas (hey, let’s do PhotoLinuxhop !)

2 – GiftWrap: the right way to do it

Vadim decided to create a GUI to allow developers to easily package third party applications in .deb format. I’m not sure about the precise steps he took, but this is what I can guess:

  • there was a need for an application
  • he looked around for similar applications
  • found 2 dead an non-working projects. Decided the fastest and easiest thing would be to just fix one of them.
  • he also didn’t care about the language the program was written. He fixed, tweaked some minor things and released it.
  • the day after 2 people showed up in the IRC channel, asking about how to help.
  • in the meantime he released a .1 bugfix release.
  • a few days after 4-5 people were permanently idling in the channel
  • Vadim started evaluating which language to port the application to as the next release of the program would be an original rewrite
  • one of the people (nasam) did an UI mockup that after several adjustments was accepted for the new verson

Vadim’s project has some good chances to succeed. He did release early a very basic, fully working application. Someone stepped in to propose mockups. Since designers have usually no experience with packaging, having a working application to use, allowed the UI guy to understand pretty easily what the needs are and less explanations were needed.

How much explanations would have been needed if there were nothing to look at ? How much time wasted making pencil sketches, VOIP conferences (lol) and such ? Would he have provided mockups for something that probably would never get to the working stage ?

Even if the project dies tomorrow, at least people will have a basic working application for some time. And someone could one day resuscitate the project and take advantage from his work.

Mediocrity through modularity. Free software hackers prize code reuse. Often they talk of writing code to perform a function, so that other programmers can write a “front end” (or multiple alternative “front ends”) to let humans actually use it. They consider it important to be able to swap out any layer of the system in favor of alternative implementations.

This is good for the long-term health of a system, because it avoids relying on any single component. But it also leads to a lack of integration which lessens usability, especially if the interfaces between the layers weren’t designed with usability in mind.

For example, most terminal commands do not provide information on how complete a process is, or estimate how much time is remaining. This is traditional behavior in a terminal, but in graphical software, progress feedback is crucial. If a graphical utility is developed merely as a “front end” to the terminal command, it can’t easily provide that feedback.

Solution: Design an example graphical interface first, so that interface requirements for the lower levels are known before they are written.

Apple for Oranges here. Terminal commands behaves like they do, because they’re designed to be used just on terminal or simply because they’re old. In some cases you just have to hook the library they use (if any), then you can have wonderful progress bars :-) . Layering a terminal command is done just for lazyness or because rewriting is considered a burden or leading to dangerous results (untested software).

Gated development communities. When you do anything on a computer system you are relying on software from several different development teams. For example, if you print this Web page to show someone else, that task will involve not just the Web browser, but also a layout engine, a window manager, an interface toolkit, a variety of other libraries, a graphical subsystem, a printing subsystem, a printer driver, a filesystem, and a kernel, almost all of these implemented by separate teams.Often these teams don’t communicate with each other frequently. And unlike their proprietary competitors, they nearly all have different release cycles. This makes usability improvements difficult and slow to implement, if those improvements involve coordinating changes across multiple parts of the system.

Solutions: Free Software system vendors can coordinate cross-component features like this, if they have employees working on all relevant levels of the software stack. And volunteer contributors to different software layers can meet at conferences arranged for that purpose.

Amen. And integrating bug trackers (like launchpad does) also helps a bit.

Summing up

Matthew is also the author of Empathy Vs Pidgin Usability a detailed study which (I’m told) has been well received by both projects.

What surprised me, in the writing I commented above, is how the Open Source work is perceived. Free Software is being looked as it was made by a company or payed developers, in most of the points.

Many projects, instead, are fruits of amateur and passionate work, which rely heavily on principles like scratching your own itch, release early and often, modularity, code reuse and so on. Usability should not be an excuse to drop good development or motivational practices.

Should also be said that when a project gets many users, it’s usability usually dramatically increases, as a simple consequence of the growing number of requests and of the augmented number of contributors.

In some parts, Matthew seems even to advocate not letting people seeing the early results of the project work. That contrasts with the way I perceive the FOSS world, and how the work gets done.

On a side note a project he is currently involved in is the new AppCenter. I know that an discussion session took place at the the Karmic UDS, still I couldn’t find any note in Gobby (probably my fault) nor the Wiki page has changed that much since then.
Sure I hope the AppCenter discussion and development won’t be kept private ! :-P
Update: the wiki page has – ironically – been edited just before the publication of this post.

Update 2: While this post was more meant as a general reflection (but yes, I made too much mess), Matthew has been kind enough to answer to this post. Check out his reply in the comments. Also, he says ridiculing works :-)

10 Responses

  1. “Weak incentives for usability” & “Few good designers” hold. Just yesterday I found this:

    which is, without personal offense to the author, is a crap interface. It might as well be terminal-based or configuration-file based. Interface != make a whole bunch of options be line inputs and comboboxes.

    “Design suggestions often aren’t invited or welcomed.” That’s true. There are few projects, mostly under the GNOME umbrella, that actually welcome better design suggestions. Rest are programmers thinking they’re better interface designers than a real designer.

    “Coding before design.” That’s true. Most projects are like that. Then stuff keeps getting added onto in various places until a deadlock forces a complete rewrite. In fact, I even had one person want to start on coding right away! The intention is surely appreciated, but a plan needs to be set down first, and we agreed on that.

  2. An important point about mpt’s essay: it’s all about Mozilla in the pre-1.0 days.

  3. Stefano Forenza

    @David Gerard: important point, thank you. I forgot to say the (year old) post is the rewrite of a 7 year old document. Should also be noted that, being rewritten (or adjusted/corrected) his opinion is likely have been pretty much the same at that time. I’m pretty ok with everything, I just disagree on many points. :)

  4. Yeah, my main point was that deep involvement in Mozilla would have warped anyone’s brain. Mine was shallow and it still warped mine ;-)

  5. I stopped reading when there was a lolcat reference/image.

    then I felt bad about that and started reading again, until I got to the warning:
    > (WARNING: LOLcats randomly added to enhance usability)

    i knew i was done then.

  6. ok, then i read it after all. good post.

    > code talks, bullshit walks
    As more users use FLOSS, less of the overall percentage will be able to code. I’ve used a FLOSS desktop (KDE) for over 5 years now and I cannot code, nor can the people to whom I’ve spread the Linux desktop. Are our concerns any less valid?

  7. Stefano Forenza

    lefty.crupps: thanks for withstanding the LOLcats :-D

    No, your concerns are not any less valid.

    You’re right, the more users use FLOSS the more the coders percentage will lower. That just means there will be more people with etherogeneous skills in the community to help with other factors, such as Documentation, Design, Usability etc.

  8. mpt

    Stefano, it’s interesting that five of the solutions I proposed, that you argue against on theoretical grounds, are already beginning to work in reality.

    Projects are already benefitting from the Season of Usability (which Canonical sponsors), which is much more focused on usability than the Google Summer of Code.

    The Gnome Human Interface Guidelines, however imperfect, have already substantially raised the floor of design quality in Gnome. (You are worrying about the ceiling, which is a separate issue.)

    Canonical’s Design team has already, at the last Ubuntu Developer Summit, run a daily Design Clinic that “let programmers collaborate with usability specialists” and helped numerous upstream projects. (And Canonical sponsors several of those upstream developers to attend UDS in the first place.)

    Ridiculing complex design has already contributed to the simplification that led to the successes of Firefox 1.0 and Gnome 2.0.

    And publishing mockups and design specifications early, to let volunteer testers understand what is supposed to happen eventually, has already helped with Notify OSD.

    Meanwhile, Canonical is working on some of the other solutions I proposed (though not necessarily following my roadmap deliberately). We are introducing distributed version control for all Ubuntu packages, making it easier to produce variant branches of projects. We are beginning to set an example of projects having a lead human interface designer (such as myself for Notify OSD and AppCenter) alongside a lead programmer (Mirco Müller for Notify OSD, Michael Vogt for AppCenter). We are beginning to foster a community of Free Software designers in Ayatana. And we are working on establishing and publishing simple usability testing procedures that can be used even by small projects, to save development time in the long term.

    Finally, you have badly misunderstood me in several areas. I did not say that anyone should “undertak[e] the pain of maintaining multiple versions”; I said that DVCS can help “someone to maintain their own variant of the software with the behavior they want”. It is not true at all that “Free Software is being looked as it was made by a company or payed developers”; on the contrary, I pointed out at the beginning of the article that “Many of these problems are with volunteer software”, and I concentrated on volunteer projects throughout. And it is not even slightly true that “Matthew seems even to advocate not letting people seeing the early results of the project work”; I didn’t write anything remotely like that.

    I updated most of the AppCenter wiki page three days ago. If you want to keep up to date with changes to the page, you could subscribe to it.

  9. Ooh. Subscribed the AppCenter page. I’m keenly interested in it coming together well.

  10. Stefano Forenza

    @mpt: Thanks for your clarifications. I’m not replying to your points, since that would end up in a long thread and I’m not that sure you would be interested.
    Glad to have misunderstood many things, as for the changes being undertaken I’m looking forward for the developments to come.

    As for the Wiki, yes I could have subscribed the page. I should note, though, that writing this (long) post took me to revise it the day later, when it was ready I scheduled to be published two days later ( ). That’s just to say there was no malice and the wiki page was mostly unchanged at the time of writing.

Leave a comment