There is a lot of discussion happening on the Habari mailing list about the design of the Administration interface. And it's the kind of thing that we're going to have to watch carefully to prevent it from getting ugly. With all the progress we've made, this is one of the first major tests of the strenght of the Habari Community. My own experience in theater has shown me that design is complicated, and the more designers you have working on something, the harder that gets. At some point, when working with other designers, someone's concepts are going to have to be subordinate to another's. If you're putting on a production, and the scenic designer is designing a setting in modern New York City, while the costume designer is basing their designs on 1940's Europe, and the sound designer is using 1970's protest music as their base, you're going to get a mess on the stage. This is why, in theater, it's usually the director who provides the over-arching vision, and a production manager is responsible for coordinating the elements and keeping lines of communication open.
But even so, while it's easy to say "We're going to need X amount of lumber to build this platform." Chosing the shade of blue to paint that platform is something that everyone can have a different idea about without anyone being "wrong".
In Habari we face the same issue. We can agree that a particular bit of code works or doesn't work. And it's usually easy to quantify what's "better" in the code. Does it use less memory? Fewer lines? Is it more secure? Easier to use in multiple places? But things like the width of the text entry fields can have a different answer for every user. In the case of Habari, we've also eliminated one of the simplest ways to resolve these issues. We don't have a person who is "in charge" who can simply say "Do it this way." We don't have a "director" and we like it that way. But this is when removing that centralized authority creates difficulty for the project. We must come up with a model that will allow us to come to a community consensus as to what Habari will look like. Because there is no "best" when you're dealing with something that is primarily subjective, a "veto on technical merits" isn't an option. The common element between where we are in Habari, and what I've learned from theater, is that it's an issue of communication. Designers, coders and users speak different languages and there's always the risk of things being lost in translation. Building common vocabulary is where we need to start if we're going to succeed. We have to take a large number of ideas and somehow create something that is visually appealing, user friendly, innovative and comfortable all at the same time, and we must somehow do this without sacrificing our primary principal of community inclusion.
This is our first big test. I don't know how we'll work through this, but I think we will all benefit from the lessons we're going to learn about how to design by community without ending up with something that looks like it was designed by a comittee.
Leave a Comment
Before leaving a comment, please ensure you have read and understand my comments policy and my privacy policy. Any comment that does not abide by the comment policy will be deleted immediately.