Read the mailing list thread that spawned this page.
We do not vote for changes to the website design. This leads to a design by committee situation. And design by committee situations always produce bad designs. A good design is usually the result of a unified vision. That means it is usually driven by a single individual. As such, comments and suggestions should be given to that individual, and they can use it to inform their vision.
At the moment, we do not have a designer with that vision for our website.
We are actively looking for one.
Does this sound like you?
Let us know!
When adding a comment, please describe the problem. Do not describe the solution. The solution is something that the person with the overall vision is tasked with coming up with. If you provide a solution with your problem, you are confusing the matter, and limiting the scope of productive discussion.
- The main text is very large and takes up a lot of space.
Commentary: This is because the current design is set to a certain width, and the main body text expands to fill that width. The size of the type itself is to compensate for that large width. If the type was any smaller, the text would be hard to read. If we want to reduce the text size, we need to reduce the width.
- The links to the mailing list web interfaces are not clear enough.
- We do not link to the Markmail web interface.
Against: These are not official, and might be better suited for the wiki.
For: this is an open source project with a community - links to other sites is both common for FOSS projects and indicative of a strong user and support base - it's one of the things people look for when evaluating open source software
- For: searchable archives are very useful, and since the Apache mail archives don't have a search function.....
- The link to JIRA should be more prominent.
For: Reporting bugs is a primary task for visitors to this website.
Against: We link to it in the footer, and this should be enough.
For: the purpose of a front page is primarily navigation - make it easy to find things
JIRA is ambiguous as a name. Issues/Bug Tracker or whatever else has meaning.
- The Contribute section is too long, and users might miss the Development links under the Quick Links section.
- We should tweak the themes of JIRA and the Wiki so they better match the homepage.
Commentary: JIRA probably can't be skinned, but the wiki probably can be.
- We should link to the documentation more prominently.
- We should have a "Support" section.
Against: I am not sure many people would be looking for this keyword.
For: fairly common button on lots of software web sites
- The word "Contribute" is ambiguous, and "Development" might be better.
Against: "Contribute" is inclusive, "Development" is exclusive. That is the wrong framing for us.
For: "contribute" can be confused with monetary contributions
- We should have a "Community" section.
- We should have a "Events" section.
- We should have a "Demo" section.
- We should have links to Twitter and Facebook accounts.
- The website needs a clear demographic target.
Commentary: Are we targeting new users, new contributors, or existing contributors? Potential new users are our biggest slice, and carry the most potential, so we should focus on those. Getting contributors is important too, but maybe we over do it? Existing contributors probably don't need the website at all, and managed perfectly fine with the old one. Sorting out the answer to this question will help the solutions to other comments seem obvious.
We need to support the entire community - ranging from evaluators who have not yet decided to use CouchDB, to new users, experienced users, sys admins, to developers. The front page is primarily an entry point - it should provide navigation and links to pages tailored to more specific audiences. In particular:
For evaluators (and I do a lot of software evaluation), the questions are: - what is this thing - what are the details (functionality, architecture, implementation) - is the project "alive" (not in terms of a pretty site, but in terms of an active community of users and developers) - which implies things that change (blog, news, events, mailing lists with lots of activity, bug tracker that shows things getting fixed, etc) - who's using it - details of what's involved in using it (demo, install instructions, documentation, some slideshows) - a sense of the community (blog, archives, forums, links to related sites)
For new users, what counts are documentation, tutorials, FAQs, an active and friendly support community, etc.
For experienced users, updates, detailed documentation, code libraries (when users are developing stuff), support for odd problems, etc.
For contributors it becomes a matter of technical documentation, community, Git, JIRA, lists, and community, etc
For: we are an opensource project and should encourage contributions and shouldn't forget dev or futur contributors coming on the website to find thee information. (Can be links)
The notion of product may change if we follow the roadmap and we should be able to target users of Couchdb as a full product àla mysql, and other that want to use couchdb inside their project (embedded). (Note: can be done in a next step)
- There should be an additional section that gives new users a tutorial, or getting started guide.
- There should be an interactive tutorial, like the one MongoDB has
- We should link to the Markmail interface for the mailing lists.
Against: We already link to the official ASF interface, and that should be enough for this site. The Markmail links can be put on the wiki.
For: search is important, the ASF interface doesn't provide it.