Open Source UI, patches not welcome

David Hyatt raises some interesting questions in his recent “It’s just the UI, stupid” blog. He says that Netscape is being hampered in user interface development for the Netscape browser of fights with random Mozilla contributors who block bugs and make comments that some features are “bad for Mozilla.” He notes that no company develops a product this way and says Netscape should have complete control over the UI of their product. Okay. The sticking point is what happens with Mozilla. Mozilla is not a company.

So far, Mozilla has been fairly open to anyone logging UI bugs and submitting patches. Unfortunately, these patches frequently cause usability problems. There are no UI review and polish requirements other than module owner approval. This needs to change. Matthew Thomas has already pointed out many of the problems with free software usability and its design process. A better process needs to be worked out.

If Netscape and Mozilla were to fork UI, what would happen with nightly builds? Would they continue to have the Mozilla UI? Would there be more than one UI? The current interfaces are similar enough that Netscape may feel it’s getting resonable testing. If they were to diverge more, how would Netscape react?

Mozilla/browser!

Blake Ross describes work he’s been doing on the mozilla/browser project and includes a screen shot. It was uncanny to compare the screen shot with a theme I’m hacking on and notice that they are virtually identical. (I have Address instead of Location as the label for the URL box and haven’t yet revised the sidebar.) Hooray! It looks like mozilla/browser is going to be quite cool. I’m particularly impressed with Blake’s comments about improved startup and new window speed. Now if only we could get some builds…

More variation is good for Mozilla

Matt Judy defends the development of Chimera for Mac OS X as good for the Mozilla project. I believe he’s right. The more browsers that are using the underlying Gecko engine on various platforms, the better the code will become. As long as the Mozilla derivatives just swap out the UI but keep the Gecko engine it still helps to build a better and more standardized web. My only concern is that these new browsers will be perceived as separate entities with small marketshare and therefore dismissed by web developers.

You’re a luser if you can’t use this

Matthew Thomas has posted an article identifying additional reasons that open source software has poor usability. Unlike the previous list, this one is more specific to the open source development model. (Failing to design the interface before coding is a problem that also affects commercial software.)

I believe both of these lists have missed the biggest reason for poor usability: difficulty of coding. Creating custom controls and behaviors are more time consuming than using whatever common controls are provided. Common controls are therefore frequently misused. When the interface is designed in advance, developers have a good idea for how things should work and can plan to create custom widgets as necessary. However, if developers are just hacking something up to be functional, as likely as not they’ll just use any easily coded control whether or not it is appropriate. This is especially evident with the standard Yes/No dialogs. Even with excellent interface design, developers will often take a shortcut and use a control that is easier to code than writing a special one as dictated.

In an ironic twist, the converse is also likely, especially with multiplatform products. Instead of using a system standard common control, developers go out of their way to create widgets that work on all platforms, but resemble the common ones. Inconsistencies between platforms and expected behaviors yield additional user confusion and frustration. The problem is still the same: lack of developer energy invested in completely duplicating expected platform behavior.

Kids can learn anything

In a fascinating experiment, slum kids in India teach themselves to surf the web and use paint software but ask “What’s a computer?” I’m not sure what I find more interesting, the kiosk and hardware setup (including video cameras and screen recording software) or the fact that kids taught themselves to do this. Use of a touch pad probably contributed to the ease of learning. (A touch screen might be even better.) I originally saw this story on slashdot and can’t stop thinking about it.

Why should we talk about being computer-literate but not bicycle-literate? If you can use something should you need to know all the names for its parts? If you do, I suspect a majority of the population isn’t car-literate. This reminds me of a friend who said he encouraged his mom to call the CPU of her computer a “box”.

Out of toilet paper?

Fear not! Designer Don Norman is developing a solution. Who would have thought that people are driven to tear paper from the larger roll when given a choice between two?

After reading any of Don Norman’s writings (I highly recommend The Design of Everyday Things), you look at the world in a different light. He makes you wonder why we put up with horrible—or worse, dangerous—design. Once you’ve used something with good design, it’s frustrating to go back to an inferior product. Thankfully, when you’re sensitized to good design you’re less likely to make that change.