subject:"website jira"

On Tue, Apr 17, 2012 at 1:05 AM, Benoit Chesneau bchesn...@gmail.comwrote:

 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 was the

Re: website jira


Noah Slater wrote:

On Tue, Apr 17, 2012 at 1:05 AM, Benoit Chesneaubchesn...@gmail.comwrote:


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 Dirkjan Ochtman

On Tue, Apr 17, 2012 at 16:27, 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'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


Dirkjan Ochtman wrote:

On Tue, Apr 17, 2012 at 16:27, 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'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 Robert Newson

what's your username?

On 17 April 2012 18:13, Miles Fidelman mfidel...@meetinghouse.net wrote:
 Dirkjan Ochtman wrote:

 On Tue, Apr 17, 2012 at 16:27, 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'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

On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:

 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 mailing lists. So we have, naturally,

Re: website jira

I have added your Markmail point to the wiki.

On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater nsla...@tumbolia.org 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 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

Re: website jira

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 nsla...@tumbolia.org wrote:

 I have added your Markmail point to the wiki.


 On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater nsla...@tumbolia.org 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

Re: website jira

Cleaned up the wiki page, changed Documentation to Wiki, etc, etc.

On Tue, Apr 17, 2012 at 9:18 PM, Noah Slater nsla...@tumbolia.org 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 nsla...@tumbolia.org wrote:

 I have added your Markmail point to the wiki.


 On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater nsla...@tumbolia.orgwrote:



 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

Re: website jira


Noah Slater wrote:

On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:

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

On Tue, Apr 17, 2012 at 9:36 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:

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.htmlhttp://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


Noah Slater wrote:

On Tue, Apr 17, 2012 at 9:36 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:

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

On Tue, Apr 17, 2012 at 10:29 PM, Miles Fidelman mfidel...@meetinghouse.net
 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 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

On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater nsla...@tumbolia.org 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

On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater nsla...@tumbolia.org wrote:
 On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau bchesn...@gmail.comwrote:

 On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater nsla...@tumbolia.org
 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 6:26 PM, Benoit Chesneau bchesn...@gmail.comwrote:

 On Mon, Apr 16, 2012 at 7:13 PM, Noah Slater nsla...@tumbolia.org wrote:
  On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneau bchesn...@gmail.com
 wrote:
 
  On Sun, Apr 15, 2012 at 10:45 PM, Noah Slater nsla...@tumbolia.org
  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 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 Chesneaubchesn...@gmail.comwrote:


On Mon, Apr 16, 2012 at 7:13 PM, Noah Slaternsla...@tumbolia.org  wrote:

On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneaubchesn...@gmail.com
wrote:


On Sun, Apr 15, 2012 at 10:45 PM, Noah Slaternsla...@tumbolia.org
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

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 bchesn...@gmail.com
wrote:
 On Mon, Apr 16, 2012 at 9:14 PM, Wendall Cada wenda...@83864.com 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
 Chesneaubchesn...@gmail.comwrote:

 On Mon, Apr 16, 2012 at 7:13 PM, Noah Slaternsla...@tumbolia.org
  wrote:

 On Mon, Apr 16, 2012 at 5:04 PM, Benoit Chesneaubchesn...@gmail.com
 wrote:

 On Sun, Apr 15, 2012 at 10:45 PM, Noah Slaternsla...@tumbolia.org
 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

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

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)
wickedg...@gmail.comwrote:

 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
 mfidel...@meetinghouse.net 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 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

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 nsla...@tumbolia.org 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

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 rurd...@gmail.com 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 nsla...@tumbolia.org 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

On Tue, Apr 17, 2012 at 1:07 AM, Noah Slater nsla...@tumbolia.org 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