couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Website_Design" by MilesFidelman
Date Tue, 17 Apr 2012 20:17:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Website_Design" page has been changed by MilesFidelman:
http://wiki.apache.org/couchdb/Website_Design?action=diff&rev1=5&rev2=6

- <<Include(EditTheWiki)>>
- <<TableOfContents()>>
+ ----
+ /!\ '''Edit conflict - other version:'''
+ 
+ ----
+ <<Include(EditTheWiki)>> <<TableOfContents()>>
  
  = Intro =
- 
  Read the [[http://s.apache.org/NsT|mailing list thread]] that spawned this page.
  
  = Guidelines =
+ ----
+ /!\ '''Edit conflict - your version:'''
  
+ ----
+ <<Include(EditTheWiki)>> <<TableOfContents()>>
+ 
+ = Guidelines =
+ ----
+ /!\ '''End of edit conflict'''
+ 
+ ----
  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.
@@ -20, +32 @@

  Let us know!
  
  = Unreviewed Comments =
- 
  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.''
+   * ''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.''
+   * ''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.''
  
-    * ''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.''
  
-    * ''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''
  
   * 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.''
+   * ''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.''
+   * ''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.''
+   * ''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.
  
@@ -64, +75 @@

   * 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: ''
  
-    * ''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.''
+  . 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, ....) - 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.
+ 
+  .
+ 
+  . For experienced users, updates, detailed documentation, code libraries (when users are
developing stuff), support for odd problems, ...
+  .
+  . For contributors it becomes a matter of technical documentation, community, easy-to-access
CVS and bugtraq, lists and community....
  
   * The Documentation link should say Wiki
  
@@ -76, +97 @@

   * There should be a link to the Quick Links in the header
  
   * 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.''
  
-    * ''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.''
- 

Mime
View raw message