Re: website & jira

2012-04-18 Thread Benoit Chesneau
On Tue, Apr 17, 2012 at 3:58 PM, Noah Slater  wrote:
> On Tue, Apr 17, 2012 at 1:05 AM, Benoit Chesneau wrote:
>
>> To be honest I don't care about the color, I don't care about the font
>> used. I don't care to have a pretty website or not. I'm not sure I
>> like that one. It's trendy for sure. Not my problem here either.
>>
>
> No offence intended, but that you don't care about these things is what
> worries me about you wanting to make changes. Our previous website looked
> very dated, and the focus of the redesign was to breath some life in to it.
> And that very much does include the colour, and the typeface, and all the
> other visual elements. So whomever takes over the site should care very
> much about these things.
>
> That doesn't mean that your concerns are not valid, but it suggests that
> you shouldn't be the one playing around with the design. If you look at the
> wiki page I created I said the following. "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."

You missed the point, or my english failed which is quite possible. I
used a present verb.

(Though it's true i'm not sure I like the website, too much trendy for
my eyes. But this is only personal taste and don't have to enter in
consideration.)

I'm only trying to solve the points I noticed. I will look at this
wiki page. Maybe we can also consider to open tickets about different
points now that there is a `website` component?

> If we try to evolve the website by having people just randomly change this,
> and randomly change that, because some small thing was bothering them, then
> we will have website that deteriorates over time. There will be no
> consistency to the changes. There will be no single vision that is
> informing the approach we take, or informing the decisions we make.
>
> That is why I have added each and every concern you have raised to this
> page. Because I hope that someone with an eye for design (someone who cares
> about the colours and the typefaces, to use your example) will pick this up
> and run with it, and work out what the best way forward is.

I'm fine with that. There is absolutely no rush. But on first post I
had the feeling  you were dismissing the points. I'm happy to be wrong
on that.

>
>
>> What I care on the other hand, is about the content, and the
>> information in. What could have been discussed, and may be fixed in
>> the future is which information is important. Who are we targeting.
>> There was some mails about that on the ml sometimes ago without real
>> decision on that.  Again I'm not talking about a vote or whatever. At
>> the end someone has to take a decision. The one that took the lead for
>> any reason. I'm pretty sure the website will need some edits (and
>> again i'm not speaking about design) in near future following recent
>> discussions. But it wasn't the topic of my mails.
>>
>
> Agreed. I have been at the nexus of these discussions for five years now. I
> took it upon myself to get involved in launching the redesign of the
> website because I felt I cared enough, and because I felt I had enough
> knowledge about it. Of course, there were discussions, but they were
> primarily between myself and Jan and Yohie, but also with people who are
> interested in contributing in the long term. It is my hope that I can reach
> out to these people again, now, and that they will jump on board. But this
> is a slow process, and a lot if changing at the moment with CouchDB.
> Shipping 1.2.0 almost broke me. And I have been taking a little break from
> it so that I don't burn out. But I hope you can trust me when I say that
> this is not the final edit to the site for another 5 years. I want to see
> the website grow. And I want to address all the comments that we receive
> about it. But I will stress that I do not think we should be making
> alterations for every comment that we received. Knee jerks never made a
> good design.
>

Again agree. Minus the "knee jerk" thing. While we shouldn't accept
all changes, it should always be for a good reason. Providing feedback
isn't natural these days, so we should take in consideration any
remarks coming since they made the effort to tell us  a thing about
that.

>
>> What I care now, is that i'm not inclined to use the site because I
>> don't find the information easily like I used too. And I've found the
>> same feedback from some persons around. I listed the points
>> previously. I'm now worried that we can't even suggest something is
>> wrong. It looks like it for sure.
>>
>
> Of course you can suggest something is wrong! As a long time contributor to
> CouchDB, your voice is stronger than most, and of course it is listened to.
> All I am asking is that we approach this methodically, and tha

Re: website & jira

2012-04-17 Thread David Pratt
Hi. I like the vibrant new couch site and appreciate the initiative
that has gone into it. I agree with Benoit that text size is too large
to be easy to be easily readable for volume of text in first two
sections. Generally text this large should be used a bit more
sparingly.

An alternative is simply breaking text of 'A Database for the Web' to
two or three columns of content, with each point encapsulated. The
simple twitter Bootstrap site does this well, isolating 9 points under
"Designed for everyone, everywhere".
http://twitter.github.com/bootstrap/

Similarly, for Want to Contribute? section, images would allow text to
be broken up and sized to make more appropriate. Smiling happy people
collaborating or having fun might be good. Perhaps 4 great images or
videos from conference, events whatever. We want to show that there
are real people behind this that are passionate and support couch.
There must be a raft of these from over the years.

I'd be great to pull max's couchtv into this with all the great video
content there.

Lastly it would be great for there to be a "Built with CouchDB"
section with cool site or app thumbs on a slider to add some motion on
the site and to cycle these out. One site could be randomly chosen
from submitted images as featured side. There is nothing more telling
for someone unfamiliar to see a site, or app they already know being
driven by couch.

In any case, happy to see change here and nice that a responsive
design has been implemented. Please consider comments constructive as
I realize all work takes time, thought and initiative. In general,
appreciate the clean appearance and simplicity.


Re: website & jira

2012-04-17 Thread Noah Slater
On Tue, Apr 17, 2012 at 10:29 PM, Miles Fidelman  wrote:
>
> Well yeah, but it's called "documentation" which is actually a link to a
> specific page on the wiki.


I changed it to "Wiki" over an hour ago. :)


Re: website & jira

2012-04-17 Thread Miles Fidelman

Noah Slater wrote:

On Tue, Apr 17, 2012 at 9:36 PM, Miles Fidelman
wrote:

Web sites are, by and large, NOT like print ads - they generally are not
the first point of contact that someone has with a "product." Rather they
are "collateral" - akin to brochures, spec. sheets, case studies, and the
like.  Someone is likely to go to the CouchDB web site AFTER
hearing/reading about CouchDB somewhere else, and goes to
couchdb.apache.org (or more likely couchdb.org) looking for details -
specs, white papers, slide shows, a list of who's using CouchDB, a live
demo, and signs that the project is alive, widely used, and supported by a
strong community of maintainers and developers, (and perhaps a commercial
ecosystem that can provide hosting, development, and other forms of
support).


Good point. Gonna add it to the wiki?

(I never said it was like a print ad, I think I side the exact opposite,
no?)


Done, and, oops (had to go back and re-read your post - read it too 
quickly the first time).



Ummm... it's pretty hard to find.  I had to go back through the email
thread to find it, and the archives are not even searchable.


What?

I presume you've been following this thread? Did you not open it the first
time I linked to it? You're complaining that you had to go back through
your emails to find a link?

What?

The archives are searchable if you use Markmail.


Was referring to the link to the wiki comments page.  Yes, the archives 
are searchable via Markmail, if I could find a link to the Markmail 
archive.  The point of a web site, and particularly a wiki, is to make 
it easy to find information.  Unlike, say, WikiPedia, ASF's wiki pages 
don't have a discussion page automatically tied to a page - so it is 
actually pretty hard to both remember that there is a comments page, and 
then how to find it.





The quickest way to turn off potential users is to make information hard
to find.  There's no link to the Wiki on the front page.



Yes there is. It's in the Quick Links section.

Well yeah, but it's called "documentation" which is actually a link to a 
specific page on the wiki.




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




Re: website & jira

2012-04-17 Thread Noah Slater
On Tue, Apr 17, 2012 at 9:36 PM, Miles Fidelman
wrote:
>
> Not to get into a contest here, but I've been building web sites since
> about 1995 (and gopher sites
> before that).  And doing sales and business development since 1974.
>

*rolls eyes*


> Web sites are, by and large, NOT like print ads - they generally are not
> the first point of contact that someone has with a "product." Rather they
> are "collateral" - akin to brochures, spec. sheets, case studies, and the
> like.  Someone is likely to go to the CouchDB web site AFTER
> hearing/reading about CouchDB somewhere else, and goes to
> couchdb.apache.org (or more likely couchdb.org) looking for details -
> specs, white papers, slide shows, a list of who's using CouchDB, a live
> demo, and signs that the project is alive, widely used, and supported by a
> strong community of maintainers and developers, (and perhaps a commercial
> ecosystem that can provide hosting, development, and other forms of
> support).
>

Good point. Gonna add it to the wiki?

(I never said it was like a print ad, I think I side the exact opposite,
no?)


> By and large, at least when I'm evaluating software for use on a project
> or internally, I'm looking for two things:
> - a quick understanding of the software (who, what, where, why, how, etc.)
> - PPTs, screen shots, demos, white papers
> - a strong community
>
> By and large a user and developer oriented site, with a highly visible
> "learn more" link is far more effective as a marketing vehicle than
> something that looks like a print ad.


Do you think we disagree on this?


> Ummm... it's pretty hard to find.  I had to go back through the email
> thread to find it, and the archives are not even searchable.


What?

I presume you've been following this thread? Did you not open it the first
time I linked to it? You're complaining that you had to go back through
your emails to find a link?

What?

The archives are searchable if you use Markmail.


> The quickest way to turn off potential users is to make information hard
> to find.  There's no link to the Wiki on the front page.


Yes there is. It's in the Quick Links section.


> Absolutely.  Pretty much everything anybody might look for is right there
> - including WTF is MongoDB and Download.


Please add SPECIFIC suggestions to the wiki.


> Well, if it were me, I'd have a single link to a mailing list page like
> http://www.erlang.org/static/**doc/mailinglist.html-
>  not clutter up the front page with all the details.


We chose to go with a single serving website.


Re: website & jira

2012-04-17 Thread Miles Fidelman

Noah Slater wrote:

On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman
wrote:

With all due respect and appreciation for your efforts marketing is
one thing, utility is another.  While there's value to marketing, (IMHO)
utility counts more.  We're not talking about a magazine ad, we're talking
about a web site that people have taken some effort to find and go to -
they're (we're) looking for information - if the information isn't there,
it doesn't matter how pretty the site is.


I've been building websites for clients for the best part of a decade, so I
assure you that I understand your points here. ;) When I said "a marketing
site" I meant that it's primary purpose is to market CouchDB to new users.
Not that we should think of it as a print ad. Trust me, I have worked with
people who do think about websites like this, and I know how crazy that
attitude is.
Not to get into a contest here, but I've been building web sites since 
about 1995 (and gopher sites

before that).  And doing sales and business development since 1974.

Web sites are, by and large, NOT like print ads - they generally are not 
the first point of contact that someone has with a "product." Rather 
they are "collateral" - akin to brochures, spec. sheets, case studies, 
and the like.  Someone is likely to go to the CouchDB web site AFTER 
hearing/reading about CouchDB somewhere else, and goes to 
couchdb.apache.org (or more likely couchdb.org) looking for details - 
specs, white papers, slide shows, a list of who's using CouchDB, a live 
demo, and signs that the project is alive, widely used, and supported by 
a strong community of maintainers and developers, (and perhaps a 
commercial ecosystem that can provide hosting, development, and other 
forms of support).


By and large, at least when I'm evaluating software for use on a project 
or internally, I'm looking for two things:
- a quick understanding of the software (who, what, where, why, how, 
etc.) - PPTs, screen shots, demos, white papers

- a strong community

By and large a user and developer oriented site, with a highly visible 
"learn more" link is far more effective as a marketing vehicle than 
something that looks like a print ad.




Agreed, I think we could add a new section. This is already on the wiki.

http://wiki.apache.org/couchdb/Website_Design

I am starting to wonder if anyone is even checking this page! ;)

No body has added anything to it since I created it, and yet this thread
rages on. ;)


Ummm... it's pretty hard to find.  I had to go back through the email 
thread to find it, and the archives are not even searchable.



For experienced users, updates, detailed documentation, code libraries
(when users are developing stuff), support for odd problems, ...


This belongs on the wiki for now.

The website is a single serving website.

That is intentional, and I'd like to keep it that way.

The wiki should be our primary focus for detailed information.


The quickest way to turn off potential users is to make information hard 
to find.  There's no link to the Wiki on the front page.



The MongoDB website is easier to navigate? Heh. Ours is one page. By
definition, there is no navigation, just scrolling. ;) Perhaps you mean
that the sign posts to other resources are clearer. Again, all we've done
is move our sign posts to the bottom of the page. We are, clearly,
optimising for a specific use case here. Joe Random clicking on a link, and
asking "WTF IS COUCHDB?" We answer that quite well, I think. Or at least,
better than we used to. And there is certainly room for improvement. We
could cram all of our project signposts in to the header, but we would be
sacrificing the simplicity of the site, and the key focus on "WTF IS
COUCHDB?" and "WHERE DO I DOWNLOAD?"


Absolutely.  Pretty much everything anybody might look for is right 
there - including WTF is MongoDB and Download.



One thing that disturbed me, was a comment that there's no link to the
markmail archive because it's not "official."  That seems like a rather
unproductive approach to building and supporting a user community - links
to other resources should be encouraged, not discouraged - both as a way to
make the main site useful, and as a sign that the community is "alive."


You have misinterpreted me. "Unofficial" resources are great! But with a
single serving site you have to make some trade-offs in the name of
simplicity. We have, in the design, a single link to the web interfaces for
the mailing lists. So we have, naturally, chosen to link to the official
ASF web interface. The Markmail links deserve a mention, but not here.
There are other places we can promote them.
Well, if it were me, I'd have a single link to a mailing list page like 
http://www.erlang.org/static/doc/mailinglist.html - not clutter up the 
front page with all the details.




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




Re: website & jira

2012-04-17 Thread Noah Slater
Cleaned up the wiki page, changed Documentation to Wiki, etc, etc.

On Tue, Apr 17, 2012 at 9:18 PM, Noah Slater  wrote:

> Thanks to Bob for adding Quick Links to the header menu. Getting to JIRA
> is now too quick clicks. (I had added this myself during development but it
> was buggy. I dunno why it is no longer buggy. Very strange!)
>
>
> On Tue, Apr 17, 2012 at 9:13 PM, Noah Slater  wrote:
>
>> I have added your Markmail point to the wiki.
>>
>>
>> On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater wrote:
>>
>>>
>>>
>>> On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman <
>>> mfidel...@meetinghouse.net> wrote:

 With all due respect and appreciation for your efforts marketing is
 one thing, utility is another.  While there's value to marketing, (IMHO)
 utility counts more.  We're not talking about a magazine ad, we're talking
 about a web site that people have taken some effort to find and go to -
 they're (we're) looking for information - if the information isn't there,
 it doesn't matter how pretty the site is.

>>>
>>> I've been building websites for clients for the best part of a decade,
>>> so I assure you that I understand your points here. ;) When I said "a
>>> marketing site" I meant that it's primary purpose is to market CouchDB to
>>> new users. Not that we should think of it as a print ad. Trust me, I have
>>> worked with people who do think about websites like this, and I know how
>>> crazy that attitude is.
>>>
>>>
>>>
 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)

>>>
>>> Agreed!
>>>
>>>
 For new users, what counts are documentation, tutorials, FAQs, an
 active and friendly support community.

>>>
>>> Agreed, I think we could add a new section. This is already on the wiki.
>>>
>>> http://wiki.apache.org/couchdb/Website_Design
>>>
>>> I am starting to wonder if anyone is even checking this page! ;)
>>>
>>> No body has added anything to it since I created it, and yet this thread
>>> rages on. ;)
>>>
>>>
 For experienced users, updates, detailed documentation, code libraries
 (when users are developing stuff), support for odd problems, ...

>>>
>>> This belongs on the wiki for now.
>>>
>>> The website is a single serving website.
>>>
>>> That is intentional, and I'd like to keep it that way.
>>>
>>> The wiki should be our primary focus for detailed information.
>>>
>>>
 For contributors it becomes a matter of technical documentation,
 community, easy-to-access CVS and bugtraq, lists and community

>>>
>>> Contributors should be focusing on the wiki too IMO. The "marketing
>>> site" or "homepage" or whatever you want to call our single serving website
>>> is not a one stop shop for everything to do with CouchDB. It's a primer, an
>>> intro, a landing page, a set of sign posts. Committers should know enough
>>> about the project to be able to use bookmarks, and use the wiki to provide
>>> more in-depth resources/links.
>>>
>>>
 Sure, all the better if the stuff looks pretty, but more important that
 things are there and EASY TO FIND (I emphasize this last point as it seems
 to be the primary criticism people are raising.  Most of the other things
 exist, somewhere - it's finding them that's difficult.)

>>>
>>> Just to clarify, it is ONE person who is saying that the JIRA link is
>>> hard to find. And that one person is a committer. It just so happens that
>>> our user focused single serving website has moved his usual "link to get me
>>> JIRA" out of the way, and he's annoyed about it. I can understand that, but
>>> I am also trying to keep his concerns in context.
>>>
>>>
 Mind you, I'm more of a function over form kind of guy, and a sample of
 one, but when I lay the mongodb web site next to the couchdb web site
 (since people seem to compare the two pieces of software quite a bit), the
 mongo home page is uglier, but a lot easier to navigate.

>>>
>>> The MongoDB website is easier to navigate? Heh. Ours is one page. By
>>> definition, there is no navigation, just scrolling. ;) Perhaps you mean
>>> that the sign posts to other resources are clearer. Again, all we've done
>>> is move our sign posts to the bottom of the page. We are, clearly,
>>> optimising for a specific use case here. Joe Random clicking on a link, and
>>> asking "WTF IS COUCHDB?" We an

Re: website & jira

2012-04-17 Thread Noah Slater
Thanks to Bob for adding Quick Links to the header menu. Getting to JIRA is
now too quick clicks. (I had added this myself during development but it
was buggy. I dunno why it is no longer buggy. Very strange!)

On Tue, Apr 17, 2012 at 9:13 PM, Noah Slater  wrote:

> I have added your Markmail point to the wiki.
>
>
> On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater  wrote:
>
>>
>>
>> On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman <
>> mfidel...@meetinghouse.net> wrote:
>>>
>>> With all due respect and appreciation for your efforts marketing is
>>> one thing, utility is another.  While there's value to marketing, (IMHO)
>>> utility counts more.  We're not talking about a magazine ad, we're talking
>>> about a web site that people have taken some effort to find and go to -
>>> they're (we're) looking for information - if the information isn't there,
>>> it doesn't matter how pretty the site is.
>>>
>>
>> I've been building websites for clients for the best part of a decade, so
>> I assure you that I understand your points here. ;) When I said "a
>> marketing site" I meant that it's primary purpose is to market CouchDB to
>> new users. Not that we should think of it as a print ad. Trust me, I have
>> worked with people who do think about websites like this, and I know how
>> crazy that attitude is.
>>
>>
>>
>>> 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)
>>>
>>
>> Agreed!
>>
>>
>>> For new users, what counts are documentation, tutorials, FAQs, an active
>>> and friendly support community.
>>>
>>
>> Agreed, I think we could add a new section. This is already on the wiki.
>>
>> http://wiki.apache.org/couchdb/Website_Design
>>
>> I am starting to wonder if anyone is even checking this page! ;)
>>
>> No body has added anything to it since I created it, and yet this thread
>> rages on. ;)
>>
>>
>>> For experienced users, updates, detailed documentation, code libraries
>>> (when users are developing stuff), support for odd problems, ...
>>>
>>
>> This belongs on the wiki for now.
>>
>> The website is a single serving website.
>>
>> That is intentional, and I'd like to keep it that way.
>>
>> The wiki should be our primary focus for detailed information.
>>
>>
>>> For contributors it becomes a matter of technical documentation,
>>> community, easy-to-access CVS and bugtraq, lists and community
>>>
>>
>> Contributors should be focusing on the wiki too IMO. The "marketing site"
>> or "homepage" or whatever you want to call our single serving website is
>> not a one stop shop for everything to do with CouchDB. It's a primer, an
>> intro, a landing page, a set of sign posts. Committers should know enough
>> about the project to be able to use bookmarks, and use the wiki to provide
>> more in-depth resources/links.
>>
>>
>>> Sure, all the better if the stuff looks pretty, but more important that
>>> things are there and EASY TO FIND (I emphasize this last point as it seems
>>> to be the primary criticism people are raising.  Most of the other things
>>> exist, somewhere - it's finding them that's difficult.)
>>>
>>
>> Just to clarify, it is ONE person who is saying that the JIRA link is
>> hard to find. And that one person is a committer. It just so happens that
>> our user focused single serving website has moved his usual "link to get me
>> JIRA" out of the way, and he's annoyed about it. I can understand that, but
>> I am also trying to keep his concerns in context.
>>
>>
>>> Mind you, I'm more of a function over form kind of guy, and a sample of
>>> one, but when I lay the mongodb web site next to the couchdb web site
>>> (since people seem to compare the two pieces of software quite a bit), the
>>> mongo home page is uglier, but a lot easier to navigate.
>>>
>>
>> The MongoDB website is easier to navigate? Heh. Ours is one page. By
>> definition, there is no navigation, just scrolling. ;) Perhaps you mean
>> that the sign posts to other resources are clearer. Again, all we've done
>> is move our sign posts to the bottom of the page. We are, clearly,
>> optimising for a specific use case here. Joe Random clicking on a link, and
>> asking "WTF IS COUCHDB?" We answer that quite well, I think. Or at least,
>> better than we used to. And there is certainly room for improvement. We
>> could cram all of our project signposts in to the header, but we would be
>> sacrificing the simplicity of the site, and

Re: website & jira

2012-04-17 Thread Noah Slater
I have added your Markmail point to the wiki.

On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater  wrote:

>
>
> On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman <
> mfidel...@meetinghouse.net> wrote:
>>
>> With all due respect and appreciation for your efforts marketing is
>> one thing, utility is another.  While there's value to marketing, (IMHO)
>> utility counts more.  We're not talking about a magazine ad, we're talking
>> about a web site that people have taken some effort to find and go to -
>> they're (we're) looking for information - if the information isn't there,
>> it doesn't matter how pretty the site is.
>>
>
> I've been building websites for clients for the best part of a decade, so
> I assure you that I understand your points here. ;) When I said "a
> marketing site" I meant that it's primary purpose is to market CouchDB to
> new users. Not that we should think of it as a print ad. Trust me, I have
> worked with people who do think about websites like this, and I know how
> crazy that attitude is.
>
>
>
>> 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)
>>
>
> Agreed!
>
>
>> For new users, what counts are documentation, tutorials, FAQs, an active
>> and friendly support community.
>>
>
> Agreed, I think we could add a new section. This is already on the wiki.
>
> http://wiki.apache.org/couchdb/Website_Design
>
> I am starting to wonder if anyone is even checking this page! ;)
>
> No body has added anything to it since I created it, and yet this thread
> rages on. ;)
>
>
>> For experienced users, updates, detailed documentation, code libraries
>> (when users are developing stuff), support for odd problems, ...
>>
>
> This belongs on the wiki for now.
>
> The website is a single serving website.
>
> That is intentional, and I'd like to keep it that way.
>
> The wiki should be our primary focus for detailed information.
>
>
>> For contributors it becomes a matter of technical documentation,
>> community, easy-to-access CVS and bugtraq, lists and community
>>
>
> Contributors should be focusing on the wiki too IMO. The "marketing site"
> or "homepage" or whatever you want to call our single serving website is
> not a one stop shop for everything to do with CouchDB. It's a primer, an
> intro, a landing page, a set of sign posts. Committers should know enough
> about the project to be able to use bookmarks, and use the wiki to provide
> more in-depth resources/links.
>
>
>> Sure, all the better if the stuff looks pretty, but more important that
>> things are there and EASY TO FIND (I emphasize this last point as it seems
>> to be the primary criticism people are raising.  Most of the other things
>> exist, somewhere - it's finding them that's difficult.)
>>
>
> Just to clarify, it is ONE person who is saying that the JIRA link is hard
> to find. And that one person is a committer. It just so happens that our
> user focused single serving website has moved his usual "link to get me
> JIRA" out of the way, and he's annoyed about it. I can understand that, but
> I am also trying to keep his concerns in context.
>
>
>> Mind you, I'm more of a function over form kind of guy, and a sample of
>> one, but when I lay the mongodb web site next to the couchdb web site
>> (since people seem to compare the two pieces of software quite a bit), the
>> mongo home page is uglier, but a lot easier to navigate.
>>
>
> The MongoDB website is easier to navigate? Heh. Ours is one page. By
> definition, there is no navigation, just scrolling. ;) Perhaps you mean
> that the sign posts to other resources are clearer. Again, all we've done
> is move our sign posts to the bottom of the page. We are, clearly,
> optimising for a specific use case here. Joe Random clicking on a link, and
> asking "WTF IS COUCHDB?" We answer that quite well, I think. Or at least,
> better than we used to. And there is certainly room for improvement. We
> could cram all of our project signposts in to the header, but we would be
> sacrificing the simplicity of the site, and the key focus on "WTF IS
> COUCHDB?" and "WHERE DO I DOWNLOAD?"
>
>
>> One thing that disturbed me, was a comment that there's no link to the
>> markmail archive because it's not "official."  That seems like a rather
>> unproductive approach to building and supporting a user community - links
>> to other resources should be encouraged, not discouraged - both as a way to
>> make t

Re: website & jira

2012-04-17 Thread Noah Slater
On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman
wrote:
>
> With all due respect and appreciation for your efforts marketing is
> one thing, utility is another.  While there's value to marketing, (IMHO)
> utility counts more.  We're not talking about a magazine ad, we're talking
> about a web site that people have taken some effort to find and go to -
> they're (we're) looking for information - if the information isn't there,
> it doesn't matter how pretty the site is.
>

I've been building websites for clients for the best part of a decade, so I
assure you that I understand your points here. ;) When I said "a marketing
site" I meant that it's primary purpose is to market CouchDB to new users.
Not that we should think of it as a print ad. Trust me, I have worked with
people who do think about websites like this, and I know how crazy that
attitude is.



> 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)
>

Agreed!


> For new users, what counts are documentation, tutorials, FAQs, an active
> and friendly support community.
>

Agreed, I think we could add a new section. This is already on the wiki.

http://wiki.apache.org/couchdb/Website_Design

I am starting to wonder if anyone is even checking this page! ;)

No body has added anything to it since I created it, and yet this thread
rages on. ;)


> For experienced users, updates, detailed documentation, code libraries
> (when users are developing stuff), support for odd problems, ...
>

This belongs on the wiki for now.

The website is a single serving website.

That is intentional, and I'd like to keep it that way.

The wiki should be our primary focus for detailed information.


> For contributors it becomes a matter of technical documentation,
> community, easy-to-access CVS and bugtraq, lists and community
>

Contributors should be focusing on the wiki too IMO. The "marketing site"
or "homepage" or whatever you want to call our single serving website is
not a one stop shop for everything to do with CouchDB. It's a primer, an
intro, a landing page, a set of sign posts. Committers should know enough
about the project to be able to use bookmarks, and use the wiki to provide
more in-depth resources/links.


> Sure, all the better if the stuff looks pretty, but more important that
> things are there and EASY TO FIND (I emphasize this last point as it seems
> to be the primary criticism people are raising.  Most of the other things
> exist, somewhere - it's finding them that's difficult.)
>

Just to clarify, it is ONE person who is saying that the JIRA link is hard
to find. And that one person is a committer. It just so happens that our
user focused single serving website has moved his usual "link to get me
JIRA" out of the way, and he's annoyed about it. I can understand that, but
I am also trying to keep his concerns in context.


> Mind you, I'm more of a function over form kind of guy, and a sample of
> one, but when I lay the mongodb web site next to the couchdb web site
> (since people seem to compare the two pieces of software quite a bit), the
> mongo home page is uglier, but a lot easier to navigate.
>

The MongoDB website is easier to navigate? Heh. Ours is one page. By
definition, there is no navigation, just scrolling. ;) Perhaps you mean
that the sign posts to other resources are clearer. Again, all we've done
is move our sign posts to the bottom of the page. We are, clearly,
optimising for a specific use case here. Joe Random clicking on a link, and
asking "WTF IS COUCHDB?" We answer that quite well, I think. Or at least,
better than we used to. And there is certainly room for improvement. We
could cram all of our project signposts in to the header, but we would be
sacrificing the simplicity of the site, and the key focus on "WTF IS
COUCHDB?" and "WHERE DO I DOWNLOAD?"


> One thing that disturbed me, was a comment that there's no link to the
> markmail archive because it's not "official."  That seems like a rather
> unproductive approach to building and supporting a user community - links
> to other resources should be encouraged, not discouraged - both as a way to
> make the main site useful, and as a sign that the community is "alive."


You have misinterpreted me. "Unofficial" resources are great! But with a
single serving site you have to make some trade-offs in the name of
simplicity. We have, in the design, a single link to the web interfaces for
the

Re: website & jira

2012-04-17 Thread Robert Newson
what's your username?

On 17 April 2012 18:13, Miles Fidelman  wrote:
> Dirkjan Ochtman wrote:
>>
>> On Tue, Apr 17, 2012 at 16:27, Miles Fidelman
>>   wrote:
>>>
>>> With all due respect and appreciation for your efforts marketing is
>>> one
>>> thing, utility is another.  While there's value to marketing, (IMHO)
>>> utility
>>> counts more.  We're not talking about a magazine ad, we're talking about
>>> a
>>> web site that people have taken some effort to find and go to - they're
>>> (we're) looking for information - if the information isn't there, it
>>> doesn't
>>> matter how pretty the site is.
>>
>> I'm sure Noah agrees with you, and the information/utility value will
>> get added soon. However, there's also plenty of value to be found in
>> having a site that's easy on the eyes. Perhaps the balance swung a
>> little too far in the marketing direction this time, but that will get
>> corrected. Arguing over it on this mailing list doesn't really help at
>> this point -- pointing out stuff that you would like to be able to
>> easily access and isn't, currently, (like your MarkMail point, on
>> which I probably agree) does. Even better if you add notes like that
>> to the aforementioned wiki page.
>>
> Well, ok, somebody want to add me to the contributors list so I can edit the
> wiki?
>
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.    Yogi Berra
>
>


Re: website & jira

2012-04-17 Thread Miles Fidelman

Dirkjan Ochtman wrote:

On Tue, Apr 17, 2012 at 16:27, Miles Fidelman
  wrote:

With all due respect and appreciation for your efforts marketing is one
thing, utility is another.  While there's value to marketing, (IMHO) utility
counts more.  We're not talking about a magazine ad, we're talking about a
web site that people have taken some effort to find and go to - they're
(we're) looking for information - if the information isn't there, it doesn't
matter how pretty the site is.

I'm sure Noah agrees with you, and the information/utility value will
get added soon. However, there's also plenty of value to be found in
having a site that's easy on the eyes. Perhaps the balance swung a
little too far in the marketing direction this time, but that will get
corrected. Arguing over it on this mailing list doesn't really help at
this point -- pointing out stuff that you would like to be able to
easily access and isn't, currently, (like your MarkMail point, on
which I probably agree) does. Even better if you add notes like that
to the aforementioned wiki page.

Well, ok, somebody want to add me to the contributors list so I can edit 
the wiki?



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




Re: website & jira

2012-04-17 Thread Dirkjan Ochtman
On Tue, Apr 17, 2012 at 16:27, Miles Fidelman
 wrote:
> With all due respect and appreciation for your efforts marketing is one
> thing, utility is another.  While there's value to marketing, (IMHO) utility
> counts more.  We're not talking about a magazine ad, we're talking about a
> web site that people have taken some effort to find and go to - they're
> (we're) looking for information - if the information isn't there, it doesn't
> matter how pretty the site is.

I'm sure Noah agrees with you, and the information/utility value will
get added soon. However, there's also plenty of value to be found in
having a site that's easy on the eyes. Perhaps the balance swung a
little too far in the marketing direction this time, but that will get
corrected. Arguing over it on this mailing list doesn't really help at
this point -- pointing out stuff that you would like to be able to
easily access and isn't, currently, (like your MarkMail point, on
which I probably agree) does. Even better if you add notes like that
to the aforementioned wiki page.

Cheers,

Dirkjan


Re: website & jira

2012-04-17 Thread Miles Fidelman

Noah Slater wrote:

On Tue, Apr 17, 2012 at 1:05 AM, Benoit Chesneauwrote:


To be honest I don't care about the color, I don't care about the font
used. I don't care to have a pretty website or not. I'm not sure I
like that one. It's trendy for sure. Not my problem here either.


No offence intended, but that you don't care about these things is what
worries me about you wanting to make changes. Our previous website looked
very dated, and the focus of the redesign was to breath some life in to it.
And that very much does include the colour, and the typeface, and all the
other visual elements. So whomever takes over the site should care very
much about these things.
With all due respect and appreciation for your efforts marketing is 
one thing, utility is another.  While there's value to marketing, (IMHO) 
utility counts more.  We're not talking about a magazine ad, we're 
talking about a web site that people have taken some effort to find and 
go to - they're (we're) looking for information - if the information 
isn't there, it doesn't matter how pretty the site is.


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


Sure, all the better if the stuff looks pretty, but more important that 
things are there and EASY TO FIND (I emphasize this last point as it 
seems to be the primary criticism people are raising.  Most of the other 
things exist, somewhere - it's finding them that's difficult.)


Mind you, I'm more of a function over form kind of guy, and a sample of 
one, but when I lay the mongodb web site next to the couchdb web site 
(since people seem to compare the two pieces of software quite a bit), 
the mongo home page is uglier, but a lot easier to navigate.


One thing that disturbed me, was a comment that there's no link to the 
markmail archive because it's not "official."  That seems like a rather 
unproductive approach to building and supporting a user community - 
links to other resources should be encouraged, not discouraged - both as 
a way to make the main site useful, and as a sign that the community is 
"alive."


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




Re: website & jira

2012-04-17 Thread Noah Slater
On Tue, Apr 17, 2012 at 1:05 AM, Benoit Chesneau wrote:

> To be honest I don't care about the color, I don't care about the font
> used. I don't care to have a pretty website or not. I'm not sure I
> like that one. It's trendy for sure. Not my problem here either.
>

No offence intended, but that you don't care about these things is what
worries me about you wanting to make changes. Our previous website looked
very dated, and the focus of the redesign was to breath some life in to it.
And that very much does include the colour, and the typeface, and all the
other visual elements. So whomever takes over the site should care very
much about these things.

That doesn't mean that your concerns are not valid, but it suggests that
you shouldn't be the one playing around with the design. If you look at the
wiki page I created I said the following. "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."

If we try to evolve the website by having people just randomly change this,
and randomly change that, because some small thing was bothering them, then
we will have website that deteriorates over time. There will be no
consistency to the changes. There will be no single vision that is
informing the approach we take, or informing the decisions we make.

That is why I have added each and every concern you have raised to this
page. Because I hope that someone with an eye for design (someone who cares
about the colours and the typefaces, to use your example) will pick this up
and run with it, and work out what the best way forward is.


> What I care on the other hand, is about the content, and the
> information in. What could have been discussed, and may be fixed in
> the future is which information is important. Who are we targeting.
> There was some mails about that on the ml sometimes ago without real
> decision on that.  Again I'm not talking about a vote or whatever. At
> the end someone has to take a decision. The one that took the lead for
> any reason. I'm pretty sure the website will need some edits (and
> again i'm not speaking about design) in near future following recent
> discussions. But it wasn't the topic of my mails.
>

Agreed. I have been at the nexus of these discussions for five years now. I
took it upon myself to get involved in launching the redesign of the
website because I felt I cared enough, and because I felt I had enough
knowledge about it. Of course, there were discussions, but they were
primarily between myself and Jan and Yohie, but also with people who are
interested in contributing in the long term. It is my hope that I can reach
out to these people again, now, and that they will jump on board. But this
is a slow process, and a lot if changing at the moment with CouchDB.
Shipping 1.2.0 almost broke me. And I have been taking a little break from
it so that I don't burn out. But I hope you can trust me when I say that
this is not the final edit to the site for another 5 years. I want to see
the website grow. And I want to address all the comments that we receive
about it. But I will stress that I do not think we should be making
alterations for every comment that we received. Knee jerks never made a
good design.


> What I care now, is that i'm not inclined to use the site because I
> don't find the information easily like I used too. And I've found the
> same feedback from some persons around. I listed the points
> previously. I'm now worried that we can't even suggest something is
> wrong. It looks like it for sure.
>

Of course you can suggest something is wrong! As a long time contributor to
CouchDB, your voice is stronger than most, and of course it is listened to.
All I am asking is that we approach this methodically, and that we do not
think of the website like we think of the code. We're getting by just fine
without a grand architect of CouchDB, though no doubt we could use one. But
a good design is the product of a single vision, and we have yet to find
that person. Again, to stress this point, I am going to be actively trying
to find that person, and I hope you can trust me when I say that. If you
have comments, that is brilliant. Can we please collect these on the wiki
page I made? And can we please try to state, clearly, the problems, and
leave the strategy up to someone else?

http://wiki.apache.org/couchdb/Website_Design


> Trust? `Trust` works in both way. And if you don't trust someone
> enough to think you can't discuss about that thing, there is a
> problem. I personally trust you even if we never met and others in the
> team. ANd pretty sure that we all know where to stop between
> bikesheeding and the rest. Am I right, dunno. That's it.
>

I trust you Benoît. If you ever get elected to the CouchDB PMC you will see
that I

Re: website & jira

2012-04-17 Thread Bob Dionne

On Apr 16, 2012, at 8:05 PM, Benoit Chesneau wrote:

> On Tue, Apr 17, 2012 at 1:07 AM, Noah Slater  wrote:
>> Some comments.
>> 
>> "I wish it could have been discussed before too."
>> 
>> Sorry to jump on you here Benoît, but this is not the way CouchDB works.
>> 
>> And every time I see this unhealthy attitude raise its ugly head, I am
>> going to stamp on it.
>> 
>> CouchDB operates a culture of trust. We trust that community members are
>> going to act in the interests of the project. Whatever you want to do, just
>> have at it. It is easier to ask for forgiveness than it is to get
>> permission.
>> 
>> The only rule to that is: don't be a berk!
>> 
>> This permission culture that we seem to have fostered in recent years is a
>> blight on the project, and it is my hope that we can use recent events to
>> shake it off. But we need to start by stamping it out where ever we see it.
>> Setting an example.
>> 
>> The website was not discussed prior to the launch, because I can tell you
>> right now, with my hand on my heart, it would never have seen the light of
>> day. We'd still be sat here, with a 5 year old site, moaning about it.
>> Because everyone thinks they know how to design, and everyone has an
>> opinion, and the thing would've been debated until it was killed.
>> 
>> You can imagine how much I flinched when I read this: "Does anyone think it
>> would be a good idea to list the proposed changes/issues to/with the site
>> and then have the community vote on them?"
>> 
>> Not picking on you here Jonathan, but it's a good example of what I am
>> talking about.
>> 
>> Voting on the design of the site is probably THE worst idea possible.
>> 
> So. I never suggested that.
> 
> To be honest I don't care about the color, I don't care about the font
> used. I don't care to have a pretty website or not. I'm not sure I
> like that one. It's trendy for sure. Not my problem here either.
> 
> What I care on the other hand, is about the content, and the
> information in. What could have been discussed, and may be fixed in
> the future is which information is important. Who are we targeting.
> There was some mails about that on the ml sometimes ago without real
> decision on that.  Again I'm not talking about a vote or whatever. At
> the end someone has to take a decision. The one that took the lead for
> any reason. I'm pretty sure the website will need some edits (and
> again i'm not speaking about design) in near future following recent
> discussions. But it wasn't the topic of my mails.
> 
> What I care now, is that i'm not inclined to use the site because I
> don't find the information easily like I used too. And I've found the
> same feedback from some persons around. I listed the points
> previously. I'm now worried that we can't even suggest something is
> wrong. It looks like it for sure.
> 
> Trust? `Trust` works in both way. And if you don't trust someone
> enough to think you can't discuss about that thing, there is a
> problem. I personally trust you even if we never met and others in the
> team. ANd pretty sure that we all know where to stop between
> bikesheeding and the rest. Am I right, dunno. That's it.
> 
> Now to list my issues with the website:
> 
> - easy access to the support (tickets)
> - reading the text is difficult
> - making some links more obvious: mailing list web browsing

+1 on these changes.

> 
> If I'm the only one to find issues about that fine. I will try to
> bookmark the links I need even if I dislike to work that way.
> 
> - benoît



Re: website & jira

2012-04-16 Thread Benoit Chesneau
On Tue, Apr 17, 2012 at 2:05 AM, Benoit Chesneau  wrote:

>
> Now to list my issues with the website:
>
> - easy access to the support (tickets)
> - reading the text is difficult
> - making some links more obvious: mailing list web browsing
>
> If I'm the only one to find issues about that fine. I will try to
> bookmark the links I need even if I dislike to work that way.
>
And the reason i think such things need discussion is just because of
the way we work btw. It would be easy to made the changes thinking
it's ok for anyone and go back, possibly ask for forgiveness. We all
know that's not so easy on such topics. This is not a code.

- benoôt


Re: website & jira

2012-04-16 Thread Benoit Chesneau
On Tue, Apr 17, 2012 at 1:07 AM, Noah Slater  wrote:
> Some comments.
>
> "I wish it could have been discussed before too."
>
> Sorry to jump on you here Benoît, but this is not the way CouchDB works.
>
> And every time I see this unhealthy attitude raise its ugly head, I am
> going to stamp on it.
>
> CouchDB operates a culture of trust. We trust that community members are
> going to act in the interests of the project. Whatever you want to do, just
> have at it. It is easier to ask for forgiveness than it is to get
> permission.
>
> The only rule to that is: don't be a berk!
>
> This permission culture that we seem to have fostered in recent years is a
> blight on the project, and it is my hope that we can use recent events to
> shake it off. But we need to start by stamping it out where ever we see it.
> Setting an example.
>
> The website was not discussed prior to the launch, because I can tell you
> right now, with my hand on my heart, it would never have seen the light of
> day. We'd still be sat here, with a 5 year old site, moaning about it.
> Because everyone thinks they know how to design, and everyone has an
> opinion, and the thing would've been debated until it was killed.
>
> You can imagine how much I flinched when I read this: "Does anyone think it
> would be a good idea to list the proposed changes/issues to/with the site
> and then have the community vote on them?"
>
> Not picking on you here Jonathan, but it's a good example of what I am
> talking about.
>
> Voting on the design of the site is probably THE worst idea possible.
>
So. I never suggested that.

To be honest I don't care about the color, I don't care about the font
used. I don't care to have a pretty website or not. I'm not sure I
like that one. It's trendy for sure. Not my problem here either.

What I care on the other hand, is about the content, and the
information in. What could have been discussed, and may be fixed in
the future is which information is important. Who are we targeting.
There was some mails about that on the ml sometimes ago without real
decision on that.  Again I'm not talking about a vote or whatever. At
the end someone has to take a decision. The one that took the lead for
any reason. I'm pretty sure the website will need some edits (and
again i'm not speaking about design) in near future following recent
discussions. But it wasn't the topic of my mails.

What I care now, is that i'm not inclined to use the site because I
don't find the information easily like I used too. And I've found the
same feedback from some persons around. I listed the points
previously. I'm now worried that we can't even suggest something is
wrong. It looks like it for sure.

Trust? `Trust` works in both way. And if you don't trust someone
enough to think you can't discuss about that thing, there is a
problem. I personally trust you even if we never met and others in the
team. ANd pretty sure that we all know where to stop between
bikesheeding and the rest. Am I right, dunno. That's it.

Now to list my issues with the website:

- easy access to the support (tickets)
- reading the text is difficult
- making some links more obvious: mailing list web browsing

If I'm the only one to find issues about that fine. I will try to
bookmark the links I need even if I dislike to work that way.

- benoît


Re: website & jira

2012-04-16 Thread Noah Slater
No worries. This is a good debate to be having. Thanks for prompting me to
lay things out how I see them! Glad to have you on board, Jonathan! Welcome
to the CouchDB party! :P

On Tue, Apr 17, 2012 at 12:33 AM, Jonathan Porta  wrote:

> Having worked on projects that were decided by a committee, I agree.  I
> think I suggested that due to the fact that I am not a contributor and that
> I have only been using CouchDB for a few months and am not fully sure yet
> how things are decided within the community.  Please excuse my ignorance on
> this one.
>
> Jonathan Porta
>
>
> On Mon, Apr 16, 2012 at 5:07 PM, Noah Slater  wrote:
>
> > Some comments.
> >
> > "I wish it could have been discussed before too."
> >
> > Sorry to jump on you here Benoît, but this is not the way CouchDB works.
> >
> > And every time I see this unhealthy attitude raise its ugly head, I am
> > going to stamp on it.
> >
> > CouchDB operates a culture of trust. We trust that community members are
> > going to act in the interests of the project. Whatever you want to do,
> just
> > have at it. It is easier to ask for forgiveness than it is to get
> > permission.
> >
> > The only rule to that is: don't be a berk!
> >
> > This permission culture that we seem to have fostered in recent years is
> a
> > blight on the project, and it is my hope that we can use recent events to
> > shake it off. But we need to start by stamping it out where ever we see
> it.
> > Setting an example.
> >
> > The website was not discussed prior to the launch, because I can tell you
> > right now, with my hand on my heart, it would never have seen the light
> of
> > day. We'd still be sat here, with a 5 year old site, moaning about it.
> > Because everyone thinks they know how to design, and everyone has an
> > opinion, and the thing would've been debated until it was killed.
> >
> > You can imagine how much I flinched when I read this: "Does anyone think
> it
> > would be a good idea to list the proposed changes/issues to/with the site
> > and then have the community vote on them?"
> >
> > Not picking on you here Jonathan, but it's a good example of what I am
> > talking about.
> >
> > Voting on the design of the site is probably THE worst idea possible.
> >
> > If we want a site that looks good, then we need to entrust a single
> > individual (preferably with a good eye for design, and modern design
> > skills) to own the site, and to take responsibility for any changes. That
> > is the only way we will avoid the dreaded design by committee, and it is
> > the only way we will be able to sensibly evolve our brand.
> >
> > So, I am asking people now. Please do not touch the design of the site
> > unless you are prepared to take ownership of the design of the site. And
> I
> > mean complete ownership. If you want to mess with the design, please be
> > prepared to take further requests. This is not to discourage you. In
> fact,
> > quite the opposite. If someone wants to do this, I would be overjoyed!
> But
> > we need someone who is committed, and who can use their single, unified
> > vision to guide us in the right direction.
> >
> > Are you a designer?
> >
> > Do you think you could help to maintain our one page static HTML website?
> >
> > Please get in touch. We need your help!
> >
> > In the mean time chaps, I have created a wiki page to collect our ideas.
> >
> > http://wiki.apache.org/couchdb/Website_Design
> >
>


Re: website & jira

2012-04-16 Thread Jonathan Porta
Having worked on projects that were decided by a committee, I agree.  I
think I suggested that due to the fact that I am not a contributor and that
I have only been using CouchDB for a few months and am not fully sure yet
how things are decided within the community.  Please excuse my ignorance on
this one.

Jonathan Porta


On Mon, Apr 16, 2012 at 5:07 PM, Noah Slater  wrote:

> Some comments.
>
> "I wish it could have been discussed before too."
>
> Sorry to jump on you here Benoît, but this is not the way CouchDB works.
>
> And every time I see this unhealthy attitude raise its ugly head, I am
> going to stamp on it.
>
> CouchDB operates a culture of trust. We trust that community members are
> going to act in the interests of the project. Whatever you want to do, just
> have at it. It is easier to ask for forgiveness than it is to get
> permission.
>
> The only rule to that is: don't be a berk!
>
> This permission culture that we seem to have fostered in recent years is a
> blight on the project, and it is my hope that we can use recent events to
> shake it off. But we need to start by stamping it out where ever we see it.
> Setting an example.
>
> The website was not discussed prior to the launch, because I can tell you
> right now, with my hand on my heart, it would never have seen the light of
> day. We'd still be sat here, with a 5 year old site, moaning about it.
> Because everyone thinks they know how to design, and everyone has an
> opinion, and the thing would've been debated until it was killed.
>
> You can imagine how much I flinched when I read this: "Does anyone think it
> would be a good idea to list the proposed changes/issues to/with the site
> and then have the community vote on them?"
>
> Not picking on you here Jonathan, but it's a good example of what I am
> talking about.
>
> Voting on the design of the site is probably THE worst idea possible.
>
> If we want a site that looks good, then we need to entrust a single
> individual (preferably with a good eye for design, and modern design
> skills) to own the site, and to take responsibility for any changes. That
> is the only way we will avoid the dreaded design by committee, and it is
> the only way we will be able to sensibly evolve our brand.
>
> So, I am asking people now. Please do not touch the design of the site
> unless you are prepared to take ownership of the design of the site. And I
> mean complete ownership. If you want to mess with the design, please be
> prepared to take further requests. This is not to discourage you. In fact,
> quite the opposite. If someone wants to do this, I would be overjoyed! But
> we need someone who is committed, and who can use their single, unified
> vision to guide us in the right direction.
>
> Are you a designer?
>
> Do you think you could help to maintain our one page static HTML website?
>
> Please get in touch. We need your help!
>
> In the mean time chaps, I have created a wiki page to collect our ideas.
>
> http://wiki.apache.org/couchdb/Website_Design
>


Re: website & jira

2012-04-16 Thread Noah Slater
Some comments.

"I wish it could have been discussed before too."

Sorry to jump on you here Benoît, but this is not the way CouchDB works.

And every time I see this unhealthy attitude raise its ugly head, I am
going to stamp on it.

CouchDB operates a culture of trust. We trust that community members are
going to act in the interests of the project. Whatever you want to do, just
have at it. It is easier to ask for forgiveness than it is to get
permission.

The only rule to that is: don't be a berk!

This permission culture that we seem to have fostered in recent years is a
blight on the project, and it is my hope that we can use recent events to
shake it off. But we need to start by stamping it out where ever we see it.
Setting an example.

The website was not discussed prior to the launch, because I can tell you
right now, with my hand on my heart, it would never have seen the light of
day. We'd still be sat here, with a 5 year old site, moaning about it.
Because everyone thinks they know how to design, and everyone has an
opinion, and the thing would've been debated until it was killed.

You can imagine how much I flinched when I read this: "Does anyone think it
would be a good idea to list the proposed changes/issues to/with the site
and then have the community vote on them?"

Not picking on you here Jonathan, but it's a good example of what I am
talking about.

Voting on the design of the site is probably THE worst idea possible.

If we want a site that looks good, then we need to entrust a single
individual (preferably with a good eye for design, and modern design
skills) to own the site, and to take responsibility for any changes. That
is the only way we will avoid the dreaded design by committee, and it is
the only way we will be able to sensibly evolve our brand.

So, I am asking people now. Please do not touch the design of the site
unless you are prepared to take ownership of the design of the site. And I
mean complete ownership. If you want to mess with the design, please be
prepared to take further requests. This is not to discourage you. In fact,
quite the opposite. If someone wants to do this, I would be overjoyed! But
we need someone who is committed, and who can use their single, unified
vision to guide us in the right direction.

Are you a designer?

Do you think you could help to maintain our one page static HTML website?

Please get in touch. We need your help!

In the mean time chaps, I have created a wiki page to collect our ideas.

http://wiki.apache.org/couchdb/Website_Design


Re: website & jira

2012-04-16 Thread Jonathan Porta
I agree regarding the differing use cases.  That is the problem exactly.  I
am not sure you could make a site that follows today's trends of "less is
more" and "creative simplicity" that also fully caters to the users, fully
caters to the developers and fully caters to the potential/new users.  That
a lot of content, not to mention several different web applications, to try
to cram into one webpage.

One thing worth pointing out is that contributing takes a higher level of
commitment on the user's part than does researching/trying CouchDB.

Someone willing to contribute would probably put up with having to spend a
few extra minutes the first time they decide to contribute.  Subsequent
visits are probably going to be via bookmarks/direct entry vs looking for
the link on the project homepage.

Basically, someone willing to contribute to the project will probably put
up with more hassle the first time than someone only interested in trying
it out.  Unfortunately, this seems a bit backwards in the whole customer
service mentality where you focus on taking care of your "valuable
customers".  But I think it makes sense to gear the site toward
newer/potential users in order to grow the user-base which will eventually
grow the number of contributors anyway.

Jonathan Porta


On Mon, Apr 16, 2012 at 4:30 PM, Eli Stevens (Gmail)
wrote:

> I think that much of the disagreement stems from different audience /
> use cases in mind when proposing changes to the web site.  I see a few
> main user profiles that visitors to the website could be lumped into:
>
> - Neophyte users who are looking for information about CouchDB to see
> if it interests them; install it for the first time; upload first
> data; write first view; etc.
> - Slightly more experienced users who are looking for support; either
> they have a question not answered by the docs, they've found a bug
> they would like to report, etc.
> - Contributors to the project, looking to do whatever it is they're
> wanting to do today.
>
> Looking at it from the outside, I would say that the website simply
> can't meet the needs of both the first and the last group well at the
> same time.  The use cases are just too different.
>
> Also, since I think that there are at least an order of magnitude more
> potential users than there are actual users, and there's another order
> of magnitude more users than there are contributors, if you want the
> most impact, the website needs to target potential users first and
> foremost, while throwing a bone or two to current users, and totally
> ignoring contributors (because honestly, you guys did fine with the
> old website, and I'd bet a dollar none of you needs to have a link to
> click on to get to JIRA; it's in your history, bookmarks, or is your
> homepage ;).
>
> I understand the motivation to try and get more contributors to help
> the project progress, but I think that getting more users and letting
> the contributors come organically will be much more sustainable than
> going after contributors directly.  I could be wrong.
>
> Either way, figuring out the target audience will probably make a lot
> of these "do we need a link to JIRA; should it be called JIRA or
> Issues" questions have obvious answers.
>
> Cheers,
> Eli
>
> On Mon, Apr 16, 2012 at 1:15 PM, Miles Fidelman
>  wrote:
> > Jonathan Porta wrote:
> >>
> >> Does anyone think it would be a good idea to list the proposed
> >> changes/issues to/with the site and then have the community vote on
> them?
> >
> >
> > Yes!
> >
> >> Opinion:
> >>
> >>
> >>- I think the new site feels very much up to current design trends.
> >>- The current site far surpasses the previous's site delivery of the
> >>message: "CouchDB is alive and ready for you to start using it!"
> >>- I think the focus on the text keeps it simple and easy to
> understand.
> >>- The "Quick Links" listed under "Development" could be a good thing
> to
> >>have at the very top of the "Want to Contribute?" section.  That way
> a
> >>person could jump right in instead of TL;DR'ing that section.
> >
> >
> > Seems to me that there are some fairly standard things that people look
> for
> > along the top of a software-related web page, that are conspicuously
> missing
> > from the CouchDB page, unless you go digging at the bottom of the page
> or by
> > clicking through links.  A fairly common list is:
> > - About (or Learn More) - missing
> > - Downloads
> > - Documentation - missing
> > - Support - missing
> > - News (or Blog) - missing
> > - Development - missing ("Contribute" is ambiguous)
> > - Community - missing (admittedly "Mailing Lists" is there, but what
> about
> > links to unofficial archives, other Couch related sites, .)
> > - Events
> > - Demo
> > - Facebook and/or Twitter
> >
> > I'd take a look at other sites, like erlang.org, drupal.org, mongodb.org
> ,
> > and so forth.
> >
> > --
> > In theory, there is no difference between theory and practice.
> > In practice, th

Re: website & jira

2012-04-16 Thread Eli Stevens (Gmail)
I think that much of the disagreement stems from different audience /
use cases in mind when proposing changes to the web site.  I see a few
main user profiles that visitors to the website could be lumped into:

- Neophyte users who are looking for information about CouchDB to see
if it interests them; install it for the first time; upload first
data; write first view; etc.
- Slightly more experienced users who are looking for support; either
they have a question not answered by the docs, they've found a bug
they would like to report, etc.
- Contributors to the project, looking to do whatever it is they're
wanting to do today.

Looking at it from the outside, I would say that the website simply
can't meet the needs of both the first and the last group well at the
same time.  The use cases are just too different.

Also, since I think that there are at least an order of magnitude more
potential users than there are actual users, and there's another order
of magnitude more users than there are contributors, if you want the
most impact, the website needs to target potential users first and
foremost, while throwing a bone or two to current users, and totally
ignoring contributors (because honestly, you guys did fine with the
old website, and I'd bet a dollar none of you needs to have a link to
click on to get to JIRA; it's in your history, bookmarks, or is your
homepage ;).

I understand the motivation to try and get more contributors to help
the project progress, but I think that getting more users and letting
the contributors come organically will be much more sustainable than
going after contributors directly.  I could be wrong.

Either way, figuring out the target audience will probably make a lot
of these "do we need a link to JIRA; should it be called JIRA or
Issues" questions have obvious answers.

Cheers,
Eli

On Mon, Apr 16, 2012 at 1:15 PM, Miles Fidelman
 wrote:
> Jonathan Porta wrote:
>>
>> Does anyone think it would be a good idea to list the proposed
>> changes/issues to/with the site and then have the community vote on them?
>
>
> Yes!
>
>> Opinion:
>>
>>
>>    - I think the new site feels very much up to current design trends.
>>    - The current site far surpasses the previous's site delivery of the
>>    message: "CouchDB is alive and ready for you to start using it!"
>>    - I think the focus on the text keeps it simple and easy to understand.
>>    - The "Quick Links" listed under "Development" could be a good thing to
>>    have at the very top of the "Want to Contribute?" section.  That way a
>>    person could jump right in instead of TL;DR'ing that section.
>
>
> Seems to me that there are some fairly standard things that people look for
> along the top of a software-related web page, that are conspicuously missing
> from the CouchDB page, unless you go digging at the bottom of the page or by
> clicking through links.  A fairly common list is:
> - About (or Learn More) - missing
> - Downloads
> - Documentation - missing
> - Support - missing
> - News (or Blog) - missing
> - Development - missing ("Contribute" is ambiguous)
> - Community - missing (admittedly "Mailing Lists" is there, but what about
> links to unofficial archives, other Couch related sites, .)
> - Events
> - Demo
> - Facebook and/or Twitter
>
> I'd take a look at other sites, like erlang.org, drupal.org, mongodb.org,
> and so forth.
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.    Yogi Berra
>
>


Re: website & jira

2012-04-16 Thread Miles Fidelman

Jonathan Porta wrote:

Does anyone think it would be a good idea to list the proposed
changes/issues to/with the site and then have the community vote on them?


Yes!

Opinion:


- I think the new site feels very much up to current design trends.
- The current site far surpasses the previous's site delivery of the
message: "CouchDB is alive and ready for you to start using it!"
- I think the focus on the text keeps it simple and easy to understand.
- The "Quick Links" listed under "Development" could be a good thing to
have at the very top of the "Want to Contribute?" section.  That way a
person could jump right in instead of TL;DR'ing that section.


Seems to me that there are some fairly standard things that people look 
for along the top of a software-related web page, that are conspicuously 
missing from the CouchDB page, unless you go digging at the bottom of 
the page or by clicking through links.  A fairly common list is:

- About (or Learn More) - missing
- Downloads
- Documentation - missing
- Support - missing
- News (or Blog) - missing
- Development - missing ("Contribute" is ambiguous)
- Community - missing (admittedly "Mailing Lists" is there, but what 
about links to unofficial archives, other Couch related sites, .)

- Events
- Demo
- Facebook and/or Twitter

I'd take a look at other sites, like erlang.org, drupal.org, 
mongodb.org, and so forth.


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




Re: website & jira

2012-04-16 Thread Jonathan Porta
Does anyone think it would be a good idea to list the proposed
changes/issues to/with the site and then have the community vote on them?

Opinion:


   - I think the new site feels very much up to current design trends.
   - The current site far surpasses the previous's site delivery of the
   message: "CouchDB is alive and ready for you to start using it!"
   - I think the focus on the text keeps it simple and easy to understand.
   - The "Quick Links" listed under "Development" could be a good thing to
   have at the very top of the "Want to Contribute?" section.  That way a
   person could jump right in instead of TL;DR'ing that section.


Do we have the ability to tweak the themes of JIRA or the Wiki to have it
better match the homepage?

Jonathan Porta



On Mon, Apr 16, 2012 at 1:30 PM, Benoit Chesneau 
wrote:
> On Mon, Apr 16, 2012 at 9:14 PM, Wendall Cada  wrote:
>> I don't know if you guys care about my feedback, but I also do this stuff
>> for a living. I've added my comments below.
>>
>>
>> On 04/16/2012 10:35 AM, Noah Slater wrote:
>>>
>>> On Mon, Apr 16, 2012 at 6:26 PM, Benoit
>>> Chesneauwrote:
>>>
 On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater
  wrote:
>
> On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau wrote:
>
>> On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater
>> wrote:
>>>
>>> Benoît:
>>>
>>> Please don't add anything to the top navigation. The only thing I

 think
>>
>> we
>>>
>>> should add there is a link to the "Quick Links" section - but I

 already
>>>
>>> tried that and the auto-scrolling breaks. If you can figure out a
way

 to
>>>
>>> make it not break, please add that.
>>
>> Well why not about a context menu?
>
>
> What?
>
 http://en.wikipedia.org/wiki/Context_menu

 here a menu that culd appear when you click on a top navigation link.
>>>
>>>
>>> Okay. No, I don't think we should have one of those.
>>
>> Agreed, these are problematic for touch devices. It's doable, but a royal
>> pain in the ass.
>>
>>>
>>>
>>> Bob:
>>>
>>> We link to the documentation in the Quick Links footer. The

 documentation
>>>
>>> itself includes the API reference. I don't think there's any

 particular
>>>
>>> need to link to the API reference on the page as a special call out.
>>>
>>> Benoît:
>>>
>>> I agree that I think the text is very big, but it's the only way we

 could
>>>
>>> get it looking good with the text stretched across the whole screen.
>>> Perhaps the thing to do is to shorten the width of the text some
how.

 We
>>>
>>> need a designer to look at it.
>>>
>> Why the text has to be stretched across the whole screen? It looks
>> good but it's actually really painful to read it.
>
>
> Yes, I'm not sure what to do about it.
>
> We need a designer to look at it.

 i would first reduce the width to 40em (common width on desktop) and
 the font size to something human readable then look at a designer to
 make eventually things looking better (wich is far less important than
 readability). I can do that quickly if anyone is OK.
>>>
>>>
>>> I want a designer to look at this. It is readable enough that we don't
>>> have
>>> to take any emergency action. I am happy to wait for this to be picked
up
>>> as CouchDB re-organises itself.
>>
>> The font size is perfect. Smaller, and I'll override locally to actually
be
>> able to read it. I have 20/20 vision, this size works for everything for
me
>> from my primary 24" monitor to my android phone. This is a bit wide for
>> readability. For reference http://www.readability.com/articles/0hbffwvq#In
>> regard to the font size on the readability link, I set text size to 120%
by
>> default, as it is far too small. This makes it exactly the same size as
the
>> default for couchdb landing page.
>
>
> Are you kidding ? Did you see my screenshot? beeing able to place only
> 10 lines of text in 1024x768 is far from perfect. larger text are know
> to be unreadable. This is absolutely not common to have a text that
> extend on all width and far from confortable.  Hence the size of a
> book or a page. even ebooks.
>
>>
>>>
>> The links to the web interface for the mailing list are there. Click
on
>> the
>>>
>>> mailing list names themselves.
>>
>> Hard time to figure I had to click on the link. That's not intuitive.
>>
> Intuition is relative.

 Do you mean we should encourage people to try all the link before
 finding the right content behind? None of these links clearly tell to
 the user that it links to a web interface.
>>>
>>>
>>> I disagree. I think the links are very clear.
>
> Where do you read this is a link to the web browsing interface? Having
> to click to know it show how well the text describe it. That not like
> i'm not usi

Re: website & jira

2012-04-16 Thread Benoit Chesneau
On Mon, Apr 16, 2012 at 9:14 PM, Wendall Cada  wrote:
> I don't know if you guys care about my feedback, but I also do this stuff
> for a living. I've added my comments below.
>
>
> On 04/16/2012 10:35 AM, Noah Slater wrote:
>>
>> On Mon, Apr 16, 2012 at 6:26 PM, Benoit
>> Chesneauwrote:
>>
>>> On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater
>>>  wrote:

 On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau>>> wrote:

> On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater
> wrote:
>>
>> Benoît:
>>
>> Please don't add anything to the top navigation. The only thing I
>>>
>>> think
>
> we
>>
>> should add there is a link to the "Quick Links" section - but I
>>>
>>> already
>>
>> tried that and the auto-scrolling breaks. If you can figure out a way
>>>
>>> to
>>
>> make it not break, please add that.
>
> Well why not about a context menu?


 What?

>>> http://en.wikipedia.org/wiki/Context_menu
>>>
>>> here a menu that culd appear when you click on a top navigation link.
>>
>>
>> Okay. No, I don't think we should have one of those.
>
> Agreed, these are problematic for touch devices. It's doable, but a royal
> pain in the ass.
>
>>
>>
>> Bob:
>>
>> We link to the documentation in the Quick Links footer. The
>>>
>>> documentation
>>
>> itself includes the API reference. I don't think there's any
>>>
>>> particular
>>
>> need to link to the API reference on the page as a special call out.
>>
>> Benoît:
>>
>> I agree that I think the text is very big, but it's the only way we
>>>
>>> could
>>
>> get it looking good with the text stretched across the whole screen.
>> Perhaps the thing to do is to shorten the width of the text some how.
>>>
>>> We
>>
>> need a designer to look at it.
>>
> Why the text has to be stretched across the whole screen? It looks
> good but it's actually really painful to read it.


 Yes, I'm not sure what to do about it.

 We need a designer to look at it.
>>>
>>> i would first reduce the width to 40em (common width on desktop) and
>>> the font size to something human readable then look at a designer to
>>> make eventually things looking better (wich is far less important than
>>> readability). I can do that quickly if anyone is OK.
>>
>>
>> I want a designer to look at this. It is readable enough that we don't
>> have
>> to take any emergency action. I am happy to wait for this to be picked up
>> as CouchDB re-organises itself.
>
> The font size is perfect. Smaller, and I'll override locally to actually be
> able to read it. I have 20/20 vision, this size works for everything for me
> from my primary 24" monitor to my android phone. This is a bit wide for
> readability. For reference http://www.readability.com/articles/0hbffwvq# In
> regard to the font size on the readability link, I set text size to 120% by
> default, as it is far too small. This makes it exactly the same size as the
> default for couchdb landing page.


Are you kidding ? Did you see my screenshot? beeing able to place only
10 lines of text in 1024x768 is far from perfect. larger text are know
to be unreadable. This is absolutely not common to have a text that
extend on all width and far from confortable.  Hence the size of a
book or a page. even ebooks.

>
>>
> The links to the web interface for the mailing list are there. Click on
> the
>>
>> mailing list names themselves.
>
> Hard time to figure I had to click on the link. That's not intuitive.
>
 Intuition is relative.
>>>
>>> Do you mean we should encourage people to try all the link before
>>> finding the right content behind? None of these links clearly tell to
>>> the user that it links to a web interface.
>>
>>
>> I disagree. I think the links are very clear.

Where do you read this is a link to the web browsing interface? Having
to click to know it show how well the text describe it. That not like
i'm not using the web since a long time.

>>
>>

> Also I don't find the markmail link.


 Markmail is not official.
>>>
>>> But it was there and useful.
>>
>>
>> So put it on the wiki.

This is not what I'm asking.
>>
>> This site is about the bare essential facts about CouchDB.
>>
>> Let's keep it simple.

I don't really see how it's related. Or rather how it's not related.
>>
>>
 Not convinced this is a big deal. How many people use the web interface
>>>
>>> to

 our mailing lists by clicking on a link, and then browsing by date? I am
 willing to bet it is only me, when totting up vote.

>>> Or any people that want to link to a discussion on others media.
>>
>>
>> Again, I think it's clear.
>>
>> We can add clarification to the wiki if it turns out not to be clear.
>>
>> (Which we will hear about.)
>>
what is it supposed to mean?
>>
>> I don't think we need JIRA in the top level nav. We have it in the
>>>
>>> Quick
>

Re: website & jira

2012-04-16 Thread Wendall Cada
I don't know if you guys care about my feedback, but I also do this 
stuff for a living. I've added my comments below.


On 04/16/2012 10:35 AM, Noah Slater wrote:

On Mon, Apr 16, 2012 at 6:26 PM, Benoit Chesneauwrote:


On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater  wrote:

On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau
On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater
wrote:

Benoît:

Please don't add anything to the top navigation. The only thing I

think

we

should add there is a link to the "Quick Links" section - but I

already

tried that and the auto-scrolling breaks. If you can figure out a way

to

make it not break, please add that.

Well why not about a context menu?


What?


http://en.wikipedia.org/wiki/Context_menu

here a menu that culd appear when you click on a top navigation link.


Okay. No, I don't think we should have one of those.
Agreed, these are problematic for touch devices. It's doable, but a 
royal pain in the ass.




Bob:

We link to the documentation in the Quick Links footer. The

documentation

itself includes the API reference. I don't think there's any

particular

need to link to the API reference on the page as a special call out.

Benoît:

I agree that I think the text is very big, but it's the only way we

could

get it looking good with the text stretched across the whole screen.
Perhaps the thing to do is to shorten the width of the text some how.

We

need a designer to look at it.


Why the text has to be stretched across the whole screen? It looks
good but it's actually really painful to read it.


Yes, I'm not sure what to do about it.

We need a designer to look at it.

i would first reduce the width to 40em (common width on desktop) and
the font size to something human readable then look at a designer to
make eventually things looking better (wich is far less important than
readability). I can do that quickly if anyone is OK.


I want a designer to look at this. It is readable enough that we don't have
to take any emergency action. I am happy to wait for this to be picked up
as CouchDB re-organises itself.
The font size is perfect. Smaller, and I'll override locally to actually 
be able to read it. I have 20/20 vision, this size works for everything 
for me from my primary 24" monitor to my android phone. This is a bit 
wide for readability. For reference 
http://www.readability.com/articles/0hbffwvq# In regard to the font size 
on the readability link, I set text size to 120% by default, as it is 
far too small. This makes it exactly the same size as the default for 
couchdb landing page.



The links to the web interface for the mailing list are there. Click on
the

mailing list names themselves.

Hard time to figure I had to click on the link. That's not intuitive.


Intuition is relative.

Do you mean we should encourage people to try all the link before
finding the right content behind? None of these links clearly tell to
the user that it links to a web interface.


I disagree. I think the links are very clear.





Also I don't find the markmail link.


Markmail is not official.

But it was there and useful.


So put it on the wiki.

This site is about the bare essential facts about CouchDB.

Let's keep it simple.



Not convinced this is a big deal. How many people use the web interface

to

our mailing lists by clicking on a link, and then browsing by date? I am
willing to bet it is only me, when totting up vote.


Or any people that want to link to a discussion on others media.


Again, I think it's clear.

We can add clarification to the wiki if it turns out not to be clear.

(Which we will hear about.)



I don't think we need JIRA in the top level nav. We have it in the

Quick

Links section.

Quick link section is on the bottom. When I just want to put a ticket
I want to make it fast. That should be on top imo and really visible
for all. Its as important as "Download" is and probably more important
than the mailing lists.


I think that the next step forward is to add a Quick Links header
navigation element that would allow you to scroll to the bottom of the
page. If anyone can get this working properly, please contribute it.



Why do i have to scroll to the bottom to find a really important link.


Because that is the way the page is designed.



Opening tickets is a way to encourage people to contribute. It is also
the way we provide support. It really *must* be part of the top
navigation.


I agree. We want people to contribute. But I don't think we should have a
link to JIRA in the top of the navigation. At the moment, that area of the
page serves as in-page navigation only. I would like to keep it like that.
I appreciate that you do not want to keep it like that. But the plural of
anecdote is not data. That is, we have two opinions. It is yet to be seen
if people have a problem finding JIRA. If it is so important to YOU, you
should have a book mark for JIRA. I am not convinced that regular users of
CouchDB are going to come to this page and 

Re: website & jira

2012-04-16 Thread Noah Slater
On Mon, Apr 16, 2012 at 6:26 PM, Benoit Chesneau wrote:

> On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater  wrote:
> > On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau  >wrote:
> >
> >> On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater 
> >> wrote:
> >> > Benoît:
> >> >
> >> > Please don't add anything to the top navigation. The only thing I
> think
> >> we
> >> > should add there is a link to the "Quick Links" section - but I
> already
> >> > tried that and the auto-scrolling breaks. If you can figure out a way
> to
> >> > make it not break, please add that.
> >>
> >> Well why not about a context menu?
> >
> >
> > What?
> >
>
> http://en.wikipedia.org/wiki/Context_menu
>
> here a menu that culd appear when you click on a top navigation link.


Okay. No, I don't think we should have one of those.


> >
> >> >
> >> > Bob:
> >> >
> >> > We link to the documentation in the Quick Links footer. The
> documentation
> >> > itself includes the API reference. I don't think there's any
> particular
> >> > need to link to the API reference on the page as a special call out.
> >> >
> >> > Benoît:
> >> >
> >> > I agree that I think the text is very big, but it's the only way we
> could
> >> > get it looking good with the text stretched across the whole screen.
> >> > Perhaps the thing to do is to shorten the width of the text some how.
> We
> >> > need a designer to look at it.
> >> >
> >>
> >> Why the text has to be stretched across the whole screen? It looks
> >> good but it's actually really painful to read it.
> >
> >
> > Yes, I'm not sure what to do about it.
> >
> > We need a designer to look at it.
>
> i would first reduce the width to 40em (common width on desktop) and
> the font size to something human readable then look at a designer to
> make eventually things looking better (wich is far less important than
> readability). I can do that quickly if anyone is OK.


I want a designer to look at this. It is readable enough that we don't have
to take any emergency action. I am happy to wait for this to be picked up
as CouchDB re-organises itself.


> >
> >> The links to the web interface for the mailing list are there. Click on
> >> the
> >> > mailing list names themselves.
> >>
> >> Hard time to figure I had to click on the link. That's not intuitive.
> >>
> >
> > Intuition is relative.
>
> Do you mean we should encourage people to try all the link before
> finding the right content behind? None of these links clearly tell to
> the user that it links to a web interface.


I disagree. I think the links are very clear.


> >
> >
> >> Also I don't find the markmail link.
> >
> >
> > Markmail is not official.
>
> But it was there and useful.


So put it on the wiki.

This site is about the bare essential facts about CouchDB.

Let's keep it simple.


> >
> > Not convinced this is a big deal. How many people use the web interface
> to
> > our mailing lists by clicking on a link, and then browsing by date? I am
> > willing to bet it is only me, when totting up vote.
> >
>
> Or any people that want to link to a discussion on others media.


Again, I think it's clear.

We can add clarification to the wiki if it turns out not to be clear.

(Which we will hear about.)


> >
> >> >
> >> > I don't think we need JIRA in the top level nav. We have it in the
> Quick
> >> > Links section.
> >>
> >> Quick link section is on the bottom. When I just want to put a ticket
> >> I want to make it fast. That should be on top imo and really visible
> >> for all. Its as important as "Download" is and probably more important
> >> than the mailing lists.
> >
> >
> > I think that the next step forward is to add a Quick Links header
> > navigation element that would allow you to scroll to the bottom of the
> > page. If anyone can get this working properly, please contribute it.
> >
>
>
> Why do i have to scroll to the bottom to find a really important link.
>

Because that is the way the page is designed.


> Opening tickets is a way to encourage people to contribute. It is also
> the way we provide support. It really *must* be part of the top
> navigation.
>

I agree. We want people to contribute. But I don't think we should have a
link to JIRA in the top of the navigation. At the moment, that area of the
page serves as in-page navigation only. I would like to keep it like that.
I appreciate that you do not want to keep it like that. But the plural of
anecdote is not data. That is, we have two opinions. It is yet to be seen
if people have a problem finding JIRA. If it is so important to YOU, you
should have a book mark for JIRA. I am not convinced that regular users of
CouchDB are going to come to this page and think "OMG WHERE CAN I REPORT
BUGS?" Maybe I am wrong, and maybe this will happen. But I want to wait and
see, and get a better feel for how this design is received before we make
any rash changes.


>
> - benoît
>


Re: website & jira

2012-04-16 Thread Benoit Chesneau
On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater  wrote:
> On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau wrote:
>
>> On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater 
>> wrote:
>> > Benoît:
>> >
>> > Please don't add anything to the top navigation. The only thing I think
>> we
>> > should add there is a link to the "Quick Links" section - but I already
>> > tried that and the auto-scrolling breaks. If you can figure out a way to
>> > make it not break, please add that.
>>
>> Well why not about a context menu?
>
>
> What?
>

http://en.wikipedia.org/wiki/Context_menu

here a menu that culd appear when you click on a top navigation link.

>
>> >
>> > Bob:
>> >
>> > We link to the documentation in the Quick Links footer. The documentation
>> > itself includes the API reference. I don't think there's any particular
>> > need to link to the API reference on the page as a special call out.
>> >
>> > Benoît:
>> >
>> > I agree that I think the text is very big, but it's the only way we could
>> > get it looking good with the text stretched across the whole screen.
>> > Perhaps the thing to do is to shorten the width of the text some how. We
>> > need a designer to look at it.
>> >
>>
>> Why the text has to be stretched across the whole screen? It looks
>> good but it's actually really painful to read it.
>
>
> Yes, I'm not sure what to do about it.
>
> We need a designer to look at it.

i would first reduce the width to 40em (common width on desktop) and
the font size to something human readable then look at a designer to
make eventually things looking better (wich is far less important than
readability). I can do that quickly if anyone is OK.

>
>> The links to the web interface for the mailing list are there. Click on
>> the
>> > mailing list names themselves.
>>
>> Hard time to figure I had to click on the link. That's not intuitive.
>>
>
> Intuition is relative.

Do you mean we should encourage people to try all the link before
finding the right content behind? None of these links clearly tell to
the user that it links to a web interface.

>
>
>> Also I don't find the markmail link.
>
>
> Markmail is not official.

But it was there and useful.

>
> Not convinced this is a big deal. How many people use the web interface to
> our mailing lists by clicking on a link, and then browsing by date? I am
> willing to bet it is only me, when totting up vote.
>

Or any people that want to link to a discussion on others media.

>
>> >
>> > I don't think we need JIRA in the top level nav. We have it in the Quick
>> > Links section.
>>
>> Quick link section is on the bottom. When I just want to put a ticket
>> I want to make it fast. That should be on top imo and really visible
>> for all. Its as important as "Download" is and probably more important
>> than the mailing lists.
>
>
> I think that the next step forward is to add a Quick Links header
> navigation element that would allow you to scroll to the bottom of the
> page. If anyone can get this working properly, please contribute it.
>


Why do i have to scroll to the bottom to find a really important link.
Opening tickets is a way to encourage people to contribute. It is also
the way we provide support. It really *must* be part of the top
navigation.


- benoît


Re: website & jira

2012-04-16 Thread Noah Slater
On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau wrote:

> On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater 
> wrote:
> > Benoît:
> >
> > Please don't add anything to the top navigation. The only thing I think
> we
> > should add there is a link to the "Quick Links" section - but I already
> > tried that and the auto-scrolling breaks. If you can figure out a way to
> > make it not break, please add that.
>
> Well why not about a context menu?


What?


> >
> > Bob:
> >
> > We link to the documentation in the Quick Links footer. The documentation
> > itself includes the API reference. I don't think there's any particular
> > need to link to the API reference on the page as a special call out.
> >
> > Benoît:
> >
> > I agree that I think the text is very big, but it's the only way we could
> > get it looking good with the text stretched across the whole screen.
> > Perhaps the thing to do is to shorten the width of the text some how. We
> > need a designer to look at it.
> >
>
> Why the text has to be stretched across the whole screen? It looks
> good but it's actually really painful to read it.


Yes, I'm not sure what to do about it.

We need a designer to look at it.

> The links to the web interface for the mailing list are there. Click on
> the
> > mailing list names themselves.
>
> Hard time to figure I had to click on the link. That's not intuitive.
>

Intuition is relative.


> Also I don't find the markmail link.


Markmail is not official.

Not convinced this is a big deal. How many people use the web interface to
our mailing lists by clicking on a link, and then browsing by date? I am
willing to bet it is only me, when totting up vote.


> >
> > I don't think we need JIRA in the top level nav. We have it in the Quick
> > Links section.
>
> Quick link section is on the bottom. When I just want to put a ticket
> I want to make it fast. That should be on top imo and really visible
> for all. Its as important as "Download" is and probably more important
> than the mailing lists.


I think that the next step forward is to add a Quick Links header
navigation element that would allow you to scroll to the bottom of the
page. If anyone can get this working properly, please contribute it.


>
> - benoit
>


Re: website & jira

2012-04-16 Thread Benoit Chesneau
On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater  wrote:
> Benoît:
>
> Please don't add anything to the top navigation. The only thing I think we
> should add there is a link to the "Quick Links" section - but I already
> tried that and the auto-scrolling breaks. If you can figure out a way to
> make it not break, please add that.

Well why not about a context menu?

>
> Bob:
>
> We link to the documentation in the Quick Links footer. The documentation
> itself includes the API reference. I don't think there's any particular
> need to link to the API reference on the page as a special call out.
>
> Benoît:
>
> I agree that I think the text is very big, but it's the only way we could
> get it looking good with the text stretched across the whole screen.
> Perhaps the thing to do is to shorten the width of the text some how. We
> need a designer to look at it.
>

Why the text has to be stretched across the whole screen? It looks
good but it's actually really painful to read it.

> The links to the web interface for the mailing list are there. Click on the
> mailing list names themselves.

Hard time to figure I had to click on the link. That's not intuitive.
Also I don't find the markmail link.

>
> I don't think we need JIRA in the top level nav. We have it in the Quick
> Links section.

Quick link section is on the bottom. When I just want to put a ticket
I want to make it fast. That should be on top imo and really visible
for all. Its as important as "Download" is and probably more important
than the mailing lists.

- benoit


Re: website & jira

2012-04-15 Thread Noah Slater
Benoît:

Please don't add anything to the top navigation. The only thing I think we
should add there is a link to the "Quick Links" section - but I already
tried that and the auto-scrolling breaks. If you can figure out a way to
make it not break, please add that.

Bob:

We link to the documentation in the Quick Links footer. The documentation
itself includes the API reference. I don't think there's any particular
need to link to the API reference on the page as a special call out.

Benoît:

I agree that I think the text is very big, but it's the only way we could
get it looking good with the text stretched across the whole screen.
Perhaps the thing to do is to shorten the width of the text some how. We
need a designer to look at it.

The links to the web interface for the mailing list are there. Click on the
mailing list names themselves.

I don't think we need JIRA in the top level nav. We have it in the Quick
Links section.

On Sun, Apr 15, 2012 at 11:04 AM, Benoit Chesneau wrote:

> bump. The more I use the new website, the more I find it difficult to
> find the right info. Ex. was looking for jira, which i found somewhere
> in the text and then remembered about the "issue tracker" link at the
> end, but having this issue tracker link on top would be good. This
> isn't like it's not an important link.
>
> I don't see any "website" section to jira, not sure if "Documentation"
> is about that. Maybe we could open one?
>
> - benoît
>
> On Sat, Apr 14, 2012 at 5:33 PM, Benoit Chesneau 
> wrote:
> > On Sat, Apr 14, 2012 at 7:39 AM, Benoit Chesneau 
> wrote:
> >> On Tue, Apr 10, 2012 at 3:43 PM, Bob Dionne
> >>  wrote:
> >>> agreed. Another thing we seemed to have lost on the new site is an
> easy way to link to the API references on the WIKI. Perhaps "Documentation"
> could be another top level category -- Bob
> >>>
> >>>
> >>> On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote:
> >>>
>  The website should have a direct link to jira on top so anyone can
>  click on it to easily report an issue.
> 
>  - benoît
> >>>
> >>
> >> Are others OK for those changes.
> >>
> >> I would add that while I like the current layout i find the website
> >> difficult to read.  On latest firefox at least. Police is too big and
> >> text extend too much on the width for a pleasant read. It also lack
> >> some bold around for fast text focus:
> >>
> >>
> http://benoitc.im/vrac/f3fd34da21f150fc5e72748507001e12/Screen%20Shot%202012-04-14%20at%207.37.39%20AM.png
> >>
> >> What's the best way to solve that?
> >>
> >> - benoît
> >
> > we also lost the links to the web access to the ml, or I cat least
> > can't find it (markmail & the other one I can't rememeber). Is this
> > something wanted?
> >
> > - benoit
>


Re: website & jira

2012-04-15 Thread Benoit Chesneau
bump. The more I use the new website, the more I find it difficult to
find the right info. Ex. was looking for jira, which i found somewhere
in the text and then remembered about the "issue tracker" link at the
end, but having this issue tracker link on top would be good. This
isn't like it's not an important link.

I don't see any "website" section to jira, not sure if "Documentation"
is about that. Maybe we could open one?

- benoît

On Sat, Apr 14, 2012 at 5:33 PM, Benoit Chesneau  wrote:
> On Sat, Apr 14, 2012 at 7:39 AM, Benoit Chesneau  wrote:
>> On Tue, Apr 10, 2012 at 3:43 PM, Bob Dionne
>>  wrote:
>>> agreed. Another thing we seemed to have lost on the new site is an easy way 
>>> to link to the API references on the WIKI. Perhaps "Documentation" could be 
>>> another top level category -- Bob
>>>
>>>
>>> On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote:
>>>
 The website should have a direct link to jira on top so anyone can
 click on it to easily report an issue.

 - benoît
>>>
>>
>> Are others OK for those changes.
>>
>> I would add that while I like the current layout i find the website
>> difficult to read.  On latest firefox at least. Police is too big and
>> text extend too much on the width for a pleasant read. It also lack
>> some bold around for fast text focus:
>>
>> http://benoitc.im/vrac/f3fd34da21f150fc5e72748507001e12/Screen%20Shot%202012-04-14%20at%207.37.39%20AM.png
>>
>> What's the best way to solve that?
>>
>> - benoît
>
> we also lost the links to the web access to the ml, or I cat least
> can't find it (markmail & the other one I can't rememeber). Is this
> something wanted?
>
> - benoit


Re: website & jira

2012-04-14 Thread Benoit Chesneau
On Sat, Apr 14, 2012 at 7:39 AM, Benoit Chesneau  wrote:
> On Tue, Apr 10, 2012 at 3:43 PM, Bob Dionne
>  wrote:
>> agreed. Another thing we seemed to have lost on the new site is an easy way 
>> to link to the API references on the WIKI. Perhaps "Documentation" could be 
>> another top level category -- Bob
>>
>>
>> On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote:
>>
>>> The website should have a direct link to jira on top so anyone can
>>> click on it to easily report an issue.
>>>
>>> - benoît
>>
>
> Are others OK for those changes.
>
> I would add that while I like the current layout i find the website
> difficult to read.  On latest firefox at least. Police is too big and
> text extend too much on the width for a pleasant read. It also lack
> some bold around for fast text focus:
>
> http://benoitc.im/vrac/f3fd34da21f150fc5e72748507001e12/Screen%20Shot%202012-04-14%20at%207.37.39%20AM.png
>
> What's the best way to solve that?
>
> - benoît

we also lost the links to the web access to the ml, or I cat least
can't find it (markmail & the other one I can't rememeber). Is this
something wanted?

- benoit


Re: website & jira

2012-04-13 Thread Benoit Chesneau
On Tue, Apr 10, 2012 at 3:43 PM, Bob Dionne
 wrote:
> agreed. Another thing we seemed to have lost on the new site is an easy way 
> to link to the API references on the WIKI. Perhaps "Documentation" could be 
> another top level category -- Bob
>
>
> On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote:
>
>> The website should have a direct link to jira on top so anyone can
>> click on it to easily report an issue.
>>
>> - benoît
>

Are others OK for those changes.

I would add that while I like the current layout i find the website
difficult to read.  On latest firefox at least. Police is too big and
text extend too much on the width for a pleasant read. It also lack
some bold around for fast text focus:

http://benoitc.im/vrac/f3fd34da21f150fc5e72748507001e12/Screen%20Shot%202012-04-14%20at%207.37.39%20AM.png

What's the best way to solve that?

- benoît


Re: website & jira

2012-04-10 Thread Bob Dionne
agreed. Another thing we seemed to have lost on the new site is an easy way to 
link to the API references on the WIKI. Perhaps "Documentation" could be 
another top level category -- Bob


On Apr 10, 2012, at 9:37 AM, Benoit Chesneau wrote:

> The website should have a direct link to jira on top so anyone can
> click on it to easily report an issue.
> 
> - benoît