I think your main goal here is to figure out what messages the website is intended to send, and to what audiences. As for the design: form follows function.
The homepage, for example, describes what couchdb is, but I don't think it does well to address what visitors would really like to know. Would MapReduce be of any consideration for someone who's choosing a DB for their next project? Would javascript and erlang solve major issues for someone who's considering migrating from another DB? Is there anything to show that couchdb can be used as a web-server? Whatever the 'selling points' are, they should be made obvious. The bullet-points method used in the main page of the wiki is a good way to do that, in my opinion. And, of course, diagrams. a. On 12 July 2010 13:37, Noah Slater <[email protected]> wrote: > It is starting to concern me that we're trying to design the site by > committee. And design by committee is a terrible way to achieve anything > with cohesion. I'm not sure what to do though. > > The ideal solution would be for us to appoint a designer/webmaster who's > sole responsibility was the design and maintenance of the site. This person > could then take guidance from the community on what should be included, and > what we'd like on the site - but would be free to call the shots, and > ultimately decide how things were going to look. > > Does anyone have any ideas how we can move towards this, and away from the > current situation? Having a bunch of geeks (and we're hardly known for our > design prowess in the first place, right?) argue about what should and > should not be included will lead us head first into the kind of open source > website we all know and hate.
