Iterative design. It’s a relatively simple process. You come up with an idea, then have a go at it. Analyze it, test it, figure out what’s wrong with it, and if you’re lucky, how you might make it better. Then you refine it, circle back, and carry on the cycle.
Iterative design is not throwing up 150 ideas and picking what you think is the best one. And it’s not simply about adding new things (actually, many iterative steps may involve removing things). Good iterative design should involve thoughtful, considered analysis and judgement – not a straw poll of features getting voted up and down a list.
Every suggested change should be backed up with a good reason. What am I trying to accomplish? What is this piece attempting to do? Is there a statement that it’s making? Does the thing I’m adding (or the thing I just added) contribute to that or take away from it? There are a dizzying array of questions you can ask during the design process. It can get daunting. Quickly.
In the Libre Software world we seem to be able to incorporate the iterative process into software development rather comfortably. When a new search routine is required for some functionality in a program, does the team canvas its members for multiple complete working prototypes and then choose one to use? I would think they’d take some sort of working prototype and then begin the iterative process refining and improving it. Why don’t we do that with things like visual design more often?
There seem to be a lot of people (in the circles I run in anyway) that are none too happy with what Ubuntu seems to be doing lately. And while I don’t agree with every design decision they’re making, I do respect the fact that they seem to have chosen a path and are proceeding to refine it.
Yes. It would be nice if the starting point of that path was happily decided by everyone and his uncle. But that’s simply not practical. Not everyone gets a say in that starting point. The tenets of Free Software do not guarantee you that – thankfully.
So what about the power of community? Where does it play in here?
We need to up our game when it comes to the thoughtful, considered analysis. We need to provide, discuss and discover the reasoning behind our analysis of things. We need to demand a statement of audience and then do our best to plunk ourselves into the shoes of that audience when formulating our analysis and criticism. Without an accepted target audience we’re just shouting about how “We” don’t like feature XYZ or “We” don’t like the look of dialog XYZ. Knowing audience you can step back and remove a great deal of personal emotion from the analysis. I think this sort of ethos, even in specific projects can lift all Libre boats design-wise.
Perhaps you would step back and discover that Ubuntu is NOT targeting you. Maybe Ubuntu is NOT designed for me. I don’t know their target audience (but I wish they’d tell me). However that doesn’t mean they don’t need all the valuable, thoughtful criticism they can get.
I think we need a better way of getting involved in the analysis part of the cycle. Not everyone can do the refining, not everyone can do the prototyping. But let’s not ignore the considered analysis part of this. There needs to be better tools or a better system for seeking out that sort of analysis, and making use of it.
The Real Question
The question is, are you interested enough in the success of Libre Software to find out you’re not the target of a given project and still provide that considered, reasoned analysis so crucial to the iterative design process? If so, speak up and let’s start raising the tide.
While you should feel free to comment here, I highly recommend you bring your comments over to Librescope. We’re trying to build a community of people interested in discussing Floss design over there.