incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: website - should we target the devs a little more
Date Sat, 03 Nov 2012 18:34:23 GMT
The homepage (or marketing site as I call it) is targeted at new users.
That's why the link to the source code is tucked away at the bottom.

Benoit, you trying to find the Git URL was not one of our user stories, and
nor should it be. You're perfectly able to figure that one out for
yourself. ;)

I definitely think we need to keep the website up to date, and iterate on
it. And I would like to see some concrete proposals that we can talk about.

On 3 November 2012 01:22, Randall Leeds <randall.leeds@gmail.com> wrote:

> On Wed, Oct 31, 2012 at 12:24 AM, Benoit Chesneau <bchesneau@gmail.com
> >wrote:
>
> > Hi all,
> >
> > Early in the morning I installed a new machine without anything around
> and
> > I couldn't remember the right link to the repository... So obviously I
> went
> > on our website to look at the link; But couldn't find it either. I
> couldn't
> > find it until I end to the Quick Links section. Which was after all
> logical
> > but ot so much intuitive (a dev is also a contributor ...).
> >
> > Anyway I'm worried that this 1 page site isn't the appropriate way to
> > present the project.
> >
> > 1. This big font (at least on chrome) doesn't help to read at all. And
> > links can't be easily  read due  to the thickness of it too
> >
>
> This one is going to be subjective. I do think we should change the default
> link text color so it's not the same as the rest of the text. That would
> make it stand out more clearly. Especially because many useful links are in
> the body text and not in the menus.
>
>
> >
> > 2. We should have a real dev sections to target devs, presenting couchdb
> > internals & such like here :
> > http://ipython.org/ipython-doc/stable/development/index.html or
> > http://www.chromium.org/developers/  an not a simple wiki page . It's
> > important for other to present couchdb internals so other developer know
> > where to hack. And it's important to attract more devs to couchdb I
> think.
> >
>
> IMO it's not a problem to have this on a wiki. Our wiki front page reads
> somewhat like chromium.org. I re-arranged it to try to be more narrative
> last time I sprinted on the docs for a day. I would like to do it again and
> I'll keep this in mind. Of course.... nobody wait for me :)
>
> Maybe it would be good to get the Wiki out of Quick LInks and into the top
> toolbar?
>
>
> >
> > 3. For other and I think the new doc site will help we should have
> > something like http://developer.android.com/index.html
> >
>
> Yeah, a lot will maybe change when the docs land. For now, I'm concerned
> about your original problem: not finding the source quickly. I think we
> should at least add the source repo under the Downloads section. Maybe add
> a line which reads "Source (repository)".
>
> Although, now I think about it more. It really is important that people can
> get to the source really fast. Maybe we should just have a "fork" link at
> the top? A section for it? Something to get here really, really fast:
> https://wiki.apache.org/couchdb/SourceCode
>
>
> > On a side note I don't find the slogan "Apache CouchDB is a database that
> > uses JSON for documents, Javascript for MapReduce queries and regular
> HTTP
> > for an API" isn't quite good. If I came here for the first time I would
> say
> > "and?" .  Replications, Views, Rendering (couchapps) and Reliable &
> > Elastiic (when bigcouch will come) are imo some selling points that speak
> > more to the end user.
> >
>
> Agreed. Let's propose some rewrites. Some text from
> https://wiki.apache.org/couchdb/FrontPage applies. It needs to communicate
> the awesome without getting stuck in the details. Different things are
> awesome to different people, though. Example: Erlang was one reason I got
> involved. Someone else might not care what language it's written in at all.
>



-- 
NS

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