I was going to explain but Carl Kessler sums it up rather nicely here:

Usability is more than a pretty face (or a good user interface)

(Yay! Someone else who gets annoyed when people assume usability == user interface.)

As a long-time user of the Gallery software for our photo gallery, and having recently totally fallen out with Gallery 2 (the software, not the people who I’m sure are lovely), I am just a little bit excited to read about the all-new Gallery 3 version which is now in its alpha release cycle. In particular, this insightful paragraph which nicely sums up the fundamental problems with Gallery 2:

Gallery 2 does many things for many people and this diversity has made it unhealthy. The code base is too complex and over-engineered because it was designed to fix every single thing that was wrong with Gallery 1 (Second System Effect) leaving its scope hazy and broad. And while the Gallery 2 code supports DB2, MSSQL, and Oracle we don’t actually have anyone on the team that knows much about them, so there is nobody to fix bugs or add features in these areas. Gallery 2 was designed from the bottom up with architecture and design patterns first, so the User Interface and User Experience need a ton of work! This is shown by the huge number of strings and documentation that need to be provided in the product for people to understand it, and multiple attempts for tech writers to document Gallery 2 have all failed. Lastly, the product is immensely complex which forces developers to take months or years to get up to speed. This makes it very hard to attract new developers, and that makes us sad.

(Gallery 3 Begins)

This paragraph, in its analysis of where they went wrong in their approach to designing Gallery 2, could easily be applied to numerous other pieces of software; it epitomises the approach taken by so many software developers (both Open Source and proprietary):

• Not clearly identifying who the software is for and what they want to be able to do with it. And not sticking with that definition, with the result that the software tries to become all things to all people and fails everyone by being too complex.
• Reacting to, and implementing, every user request indiscriminately. Yes, listen to users but do not be led by their requests. Users are not designers. They just want to do what they want to do and don’t really care what other users want to do. Some requests will conflict with other requests. Which is why you must have a clear understanding of who your users are, what their skills are, and what their goals in using your software are. Only then can you make informed decisions about which requests should be absorbed and which should be ignored. You can’t please everyone but, as long as you know who they are and you’re careful to design for them, you can please the people who you want to use the software.
• Making the software difficult to maintain and support. Aside from lacking contributors to the project, it increases the risk that when updates are released, they break other parts of the software because no one in the development team really understands how everything hangs together.
• Expecting documentation to paper the cracks in the software’s design. Documentation (not just the manuals but the labels on the User Interface or the titles in a wizard) has an important place within the whole product but always check honestly for whether the documentation is really necessary or whether it’s just covering up for a dodgy bit of design.
• Assuming that User Interface is the same as User Experience. The User Interface (UI) is only a part of the User Experience. One example in both Gallery 1 and 2 (though it’s way worse in Gallery 2), is the expectation that users implicitly understand Unix-style permissions. The UI didn’t help but the underlying concept of Unix-style permissions makes the software (and the UI) so much more complicated than it needs to be. (Gallery 2 was way worse because I still can’t work out how to set permissions – and I do, to an extent, understand Unix-style permissions.)

I think it’s really cool that Gallery have openly recognised and acknowledged the problems with Gallery 2 and what they need to do to make Gallery 3 successful. The really hard part now, though, is to make sure that the development team don’t fall back into their Gallery 2 ways of thinking. That’s not to disparage the development team; it’s just hard to adopt new approaches. But it will get easier with practice. The clearly stated Gallery 3 list of priorities is encouraging and, while I’ve not looked at their progress in the alpha yet, I look forward to the first release.