RFC: Bazaar Web site Home Page Redesign

[Emma Jane]

Hello,

Before I jump into the guts of this RFC, I feel it's appropriate to give a bit 
of an introduction. I'm Emma. Aka EmmaJane on teh internets. During the last 
year I've been running around North America giving conference presentations 
about Bazaar because y'all make version control suck less and I wanted 
to share that with other people too [1,2]. In Real Life I'm a freelance Web 
developer, documentation author and IT trainer specializing in the deployment 
of open source content management systems for small businesses and 
communities. I'm best known for my work with Drupal [3,4].

Martin Pool has asked me to help out with the redesign of the Bazaar Web site. 
I'm very excited. Version control is important, but not exactly popular or 
"fun." Fortunately there are lots of people that know how awesome it is to be 
able to roll back changes and see a log of what you were thinking 18 months 
ago. While scanning existing version control systems Web sites to prepare this 
RFC, I realised that root canals look elegant. All of which is to say that I 
really am excited to help make version control more appealing.

I've started out with a wireframe for the home page. If all goes according to 
plan we should be able to get a new static home page by the end of next week 
and in time for the 2.0 release. I'm hoping that you will have a bit of time 
and a few ideas.

Thanks for your time.

regards,
emma

[1] http://www.slideshare.net/emmajane/version-control-for-mere-mortals
[2] http://opensourcebridge.org/sessions/37
[3] http://www.drupal.org
[4] http://www.emmajane.net/craft/drupal



Goal
----------------------------------
The goal for this first step is to make the home page suck less for the 2.0 
release. This is an iterative process. There will be many more opportunities 
for you to comment on the colour of the new bike shed, but for now we're 
"just" trying to make a home page that's worthy of Bazaar 2.0. :)


Proposed wireframe
----------------------------------
http://www.flickr.com/photos/emmajane/3791477132/



Desired Feedback
----------------------------------
1. Does this wireframe have spaces to accommodate all front-page-worthy 
material?
2. Can anything be omitted from this wireframe because it is not front-page-
worthy?
3. If you were to shuffle the components, what would your wireframe look like? 

Please feel free to sketch and scan. I want your ideas, and will not judge you 
based on handwriting or GIMP skillz. My handwriting looks like this: 
http://www.flickr.com/photos/emmajane/3790676649/. There's no way yours is 
worse.

Undesirable feedback:
Please don't worry about the technology part of implementation right now. At 
this time we just need the general "shape" of the front page. It is very 
likely that a flat HTML page will replace the current wiki home page for the 
first iteration of the redesign. 

Timeline:
Sunday August 9, incorporate feedback from this RFC
Monday August 10, I give final wireframe to the graphic designers
Wednesday August 12, I receive graphical treatment back from the designers
Friday August 14, "we" upload new home page for the Bazaar Web site
If you're able to spare a few minutes in the next day or two, it would be most 
appreciated. This is only the first iteration though, you will have lots of 
opportunity to give additional feedback later. :)


Rationale
----------------------------------
Going through the "competitor" Web sites taught me that people clearly do not 
pick a VCS based on the project's Web site. In my experience of doing 
conference presentations about Bazaar for newbies this is definitely true. Most 
people choose their VCS based on (1) what has already been implemented by 
work/project or (2) what trusted friends are using. To be a compelling Web 
site, Bazaar needs to be the VCS of choice for projects, and needs to appear 
like a trusted friend to people who are looking to start using version control 
(or are looking to switch).

I went through the following Web sites:
http://subversion.tigris.org/
http://www.nongnu.org/cvs/
http://www.selenic.com/mercurial/
http://www.bitkeeper.com/
http://git-scm.com/
http://darcs.net/
http://www.mozilla.com/en-US/firefox/upgrade.html (it's not version control, 
but it is a product)

You can see these sites broken into their components at:
http://www.flickr.com/photos/emmajane/sets/72157621825478417/

== Solve the customer's problem
To win a sale, a product must solve a problem. It doesn't matter what the 
product can do it matters how it makes a person's life easier. The front page 
focus must be on what the consumer wants, not what the project wants. This 
means the front page needs to:
• focus on getting the consumer using the product
• provide easy access to common questions/adoption hurdles
• avoid calls for project volunteers (this is what the project needs, not the 
consumer)

The following front page elements were found looking through each of the sites 
listed above (and the Bazaar site):
• types of users identified (see BitKeeper)
• short description of the product
• download now
• features, release-specific features, links to feature descriptions
• tour
• download, install, clients
• quick start command list
• projects using this system
• conversation about the product: IRC, mailing list
• get help (commercial, IRC, mailing list)
• link to documentation
• hosting
• project sponsor
• switcher guides
• contributor information

Each project combines and emphasizes these components in unique ways. Although 
Git has the prettiest site of the bunch, BitKeeper did the best job of 
identifying target audience; and Subversion did the best job of categorizing 
links into four main components (download, help, problems, development).

Working on a four column grid I've divided the front page as follows:
• Human information
	∘ Features/Solutions
	∘ Getting Help
	∘ About (including projects using bzr)
• Technical information
	∘ Install (Bazaar and clients)
	∘ Extend (plugins)
	∘ Release notes
Although I had originally divided the page in a left-to-right progression 
(Features, Download, Extend, Participate), but decided this LTR progression 
was not relevant for RTL languages and potentially made the software look 
difficult to use because it assumes that the final step in the procedure is to 
participate in the development of the software.

To accommodate the "extra" stuff that's important for seasoned users, but scary 
for new adopters, I've introduced a standard footer. This is where links for 
participation requests (e.g. developers) and reporting bugs should go. Take a 
look at http://www.mozilla.com/en-US/ to see how they have included a lot of 
"extra" information on the home page without it being overwhelming or in the 
way.

Bonus homework:
My next step will be to create a site map/mindmap that defines the links out of 
each of these boxes. If you're playing along at home and you want to create 
one as well, that'd be fantastic!! It will help us to ensure:
- appropriate titles are used for each of the regions
- all front-page-worthy material is identified and placed into the regions
- faster development of the internal wireframes and site 
structure/information.

Thanks again for your time. It's much appreciated!