couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: website & jira
Date Tue, 17 Apr 2012 20:18:09 GMT
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 <nslater@tumbolia.org> wrote:

> I have added your Markmail point to the wiki.
>
>
> On Tue, Apr 17, 2012 at 9:10 PM, Noah Slater <nslater@tumbolia.org> wrote:
>
>>
>>
>> On Tue, Apr 17, 2012 at 3:27 PM, Miles Fidelman <
>> mfidelman@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 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.
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message