jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zack Shoylev <zack.shoy...@RACKSPACE.COM>
Subject Re: Improve jclouds site content
Date Thu, 02 Jan 2014 20:55:43 GMT
I think reducing clicks is a very good idea and a good place to start. I would leave the video
and bootstrap for last.
However: if doing content and design changes at the same time will save any work,  do that
:)



-------- Original message --------
From: Everett Toews <everett.toews@RACKSPACE.COM>
Date: 01/02/2014 1:53 PM (GMT-06:00)
To: "<dev@jclouds.apache.org>" <dev@jclouds.apache.org>
Cc: "<user@jclouds.apache.org>" <user@jclouds.apache.org>
Subject: Re: Improve jclouds site content


Hi Ignasi,

Great idea. I think we can make the site more welcoming for newcomers too. To do this right,
we need a new design.

I did a bit of research into other popular open project websites [*] to see what we can learn
from them. There seem to be some commonalities. I believe these things helped contribute to
their popularity. I'm not saying jclouds needs each and every thing but whatever makes sense
for us.

1. Most sites start with a simple "[Whatever] is a blah blah blah" type statement. This lets
users know exactly what it is without have to click through to anything.

2. An eye catching top banner.

3. A prominent link button to download or install.

4. A prominent link/button for getting started.

5. A simple code snippet.

6. A short list of prominent customers/consumers/providers.

7. Navigation as a top menu with the usual suspects. Essentially whatever is important to
that project. e.g. About, Documentation, Download/Install, News, Community, etc.

8. A video of the project in action.

9. Search.

They all seem to follow the design principles espoused by Bootstrap [1] so I think we could
make things much easier on ourselves by using it. I'm not sure how well it will play with
Jekyll but it's worth a try.

I volunteer to do a proof of concept for Bootstrap. I think I could have something to look
at by the end of next week.

Does anyone have any advice or would care to help?

Thanks,
Everett

[1] http://getbootstrap.com/

[*]
Front end projects:
http://jquery.com/
http://lesscss.org/
http://d3js.org/

Languages:
http://preview.python.org/
http://nodejs.org/
https://www.ruby-lang.org/
http://www.scala-lang.org/

Frameworks:
http://phonegap.com/
http://cordova.apache.org/
http://shiro.apache.org/
http://akka.io/
http://www.playframework.com/

Deployment:
http://puppetlabs.com/
http://www.getchef.com/
http://www.saltstack.com/


On Jan 1, 2014, at 5:00 PM, Ignasi Barrera wrote:

Hi jcloudies!

We've recently started a discussion about the contents in
http://jclouds.apache.org

It would be great if we could discuss the things to improve to make
the site better and make it easier for newcomers to approach jclouds.
Let's do some brainstorming and see what we can do!

My opinion is that the current content doesn't help people approaching
jclouds: documentation is hard to find, and there are many obsolete
pages.

IMO the site should have a simple landing page (as it has now), with
the following sections:

* Getting started: Should explain the concepts: contexts, providers,
apis, locations, but not many more. We should keep it simple. Also
should contain a few links to other topics such as compute/blobstore
description, logging, configuration and basic code examples. But
keeping everything simple, basic and short/concise. This is what 99%
of people approaching jclouds looks for, so let's put that in the
getting started page and keep it simple.
* Provider user guides: I like the current format. Just explain the
provider specific apis with examples
* Community: Links to the ML, Jira, etc.
* Blog.

I really think we should revisit and simplify the entire site. Remove
the obsolete documents and those too specific, and keep the site with
simple docs of common code that help understanding the core concepts
and how jclouds works. I'm sure that would help adoption?

WDYT? Any other vision of how the site should be? Can we coordinate
and start together a documentation effort?


Ignasi


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