A convoluted Mambo: Why open source software needs usability Nazis

By David Rothman

I am hardly a Microsoft or Adobe flack, but I’m not going to resist a rant against the failings of open source, either. OS people need to bring usability Nazis into the software creation process as soon as possible, the way the big commercial vendors so often do. Exhibit A of the moment is Mambo, a content management system. Lickety-split, I installed Mambo for the forthcoming OpenReader site at a large Web hosting service. No hassles. Mambo makes everything clear at that stage, in line with its slogan “Power in simplicity.” But oh the horrors of creating a menu hierachy (Main Menu-> Section -> Category -> Item)!

If usability Nazis had been on the job for Mambo, the construction of a site navigation hierarchy would be easier–for example:

1. You just use the same screen to name and create the main menu. Press Return after specifying a name and you’re back in the original screen. No navigation worries!

2. When you create a Section within the Main Menu–such as “ORCA Reader Software”–you also name that. It’s just a matter of filling in a blank, after which you automatically return to the Main Menu creation screen. A list of already-named Sections, such as “About us,” keeps on growing. You can continue to make new Sections or click on links to edit existing ones, and during these edits you can add Categories. Yes, within the edit mode, you’re in a different screen. But a good, bread-crumb style menu (Main Menu -> Section for ORCA Reader Software -> Category for ORCA Technological Overview) helps you avoid getting lost. The nonbolded level is the one you’re in.

3. You go on (Main Menu -> Section for OCRA Reader -> Category for OCRA Technological Overview-> -> Item/Article), and the same logic applies. You can keep track of what’s happening. Effortlessly you can drill down to the lowest levels without losing yourself in the wilderness.

A KISS-the-user approach wouldn’t be such big deal (even if the above probably has mistakes and undoubtedly can be improved on), but Mambo instead used something horridly convoluted. Googling around, I see that Mambo’s creators perhaps wanted a bottoms-up approach–at least by the interpretation of one poster in a Mambo forum. If true, that is outright silly. Everyone learns in schools to do outlines. Why can’t Web sites get built the same way, tops down–with ample opportunity to add and link new minor items if need be? And with constant navigation aids like the bread crumbs? End users would appreciate that. Instead, however, the Uber Geeks apparently prevailed–perhaps rationalizing, “Hierarchies are evil! Let’s keep things as flat as possible and build from there.” No, maybe that’s not how it happened. But it might as well have.

Rx

Rx for future versions? Mambo should get documentation writers involved earlier in the process. If they can’t describe what is going on, then the relevant parts of the Mambo interface will require more sweat. Back to the drawing board!

In this vein, I also wonder if the Geek Snobbery Factor may have been at work. So often, leadership within open source efforts is based too much on programming ability and not enough on the ability to empathize with the end users. The uber geeks may care more about the number of minor features, and so on, than about general ease of installation or use. In awarding influence among collegues, open source teams should place more emphasis than now on software ergonomics.

Come to think of it, I’d like to see standardized bread crumb style menus for situations like this. Windows has standardization. The open source world could use more of it.

Significantly, compared to CMS rivals such as Drupal, Mambo is often said to be simpler. I wouldn’t be surprised. Whatever the case, Mambo, which has many redeeming traits, is firing me up with an eagerness to help keep the reference implementation of OpenReader as easy to install and use as possible. You can bet that as a nonprogrammer, I’m gonna speak up.

A chance for open source to get things right, too

No, I don’t think that open source programs created through mass collaborations are inherently doomed to have sucky interfaces. Firefox is a great illustration of the positives. Maybe the right procedures were in place or the programmers understood mere users better than most geeks do. In usability, OpenReader needs to be more like Firefox than Mambo.

And if big congomerates with usability labs and focus groups want to do their own OpenReaders? That would be wonderful. Let Microsoft, Adobe and the rest try to outdo the open source people and vice versa. That’s what happens when you have an open format–not subject to fickle decisions of one company–and an opportunity for competition.

Detail: In the parlance of open source people, Mambo is now forked. Two differcent factions are doing their own respective versions of the program, one of them to be called Joomla. I hope that both prongs will pay attention to my thoughts above.

Meanwhile, if any Mambo/Joomla gurus want to catch up with me, I won’t mind. Why not write a plain-English guide on hierarchy/navigation or collaborate with me on one? I’ll publish it here, where, of course, Google will pick it up so that other users don’t waste the same time I have. Someone else did that, more or less, but his work is now obsolete. I think that the Mambo CMS on the whole will be good for the reborn OpenReader site, and I hope that the above feedback is helpful.

Now, back to my Mambo-ing! I’ll never be the Fred Astaire of Mambo–rest assured that the OpenReader site will have true CMS masters when sufficient funding materializes!–but this dance is worth it. I’m grateful Mambo exists. Maybe the rant above will help encourage its creators to make it better.