Version Control Web sites

Over the last year I've been running around to various conferences spreading the word that is Bazaar. (Just in case you missed the word, the word is good.) In each of the presentations I've made it very clear that I don't care what version control system (VCS) people use, just so long as they're using something. I was personally drawn to Bazaar because of their incredibly friendly developer community which was confirmed in Lenz Grimmer's Bazaar presentation at DrupalCon Szeged. I've always been encouraged by Bazaar folks to ask as many questions as possible and have only ever been asked to pay back the time by writing up documentation. (Which is a very good trade.)

This week I started on a new adventure: Martin Pool has asked me to help out with the redesign of the Bazaar Web site and I'm thrilled to be working on this project. 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. In other words I am very excited to help make version control more appealing.

In giving the presentations on Bazaar, and evangelizing on the merits of (personal/freelance-friendly) version control within the Drupal community, I've come to realize that version control systems do a really crap job of promoting themselves. If you've seen me scrapping with Sam Boyer or Selena Deckelmann you know that the arguments are mostly fun and full of hot air. This makes the 'discussion' virtually useless in helping you pick a VCS that's right for your needs. Taking a scan through the existing VCS Web sites also makes it very clear that none of the players have gotten it right on the home page. Below is my Request for Comments on how to make the Bazaar home page better--a quest that started with the bzr vs git project.

I would be delighted if you participated in this open call for comments and contributions to the new Bazaar Web site. The best place is to participate is ON THE MAILING LIST. But I've included the RFC as part of this post as well.

The goal for this first step is to make the Bazaar 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

Proposed Bazaar site front page

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. 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.


  • 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. :)

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: (it's not version control, but it is a product)

You can see these sites broken into their components at:

Solving 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 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!

Sorry to post here. I don't

Sorry to post here. I don't know if I'll have time to do my remix of the wireframe... but here is a quick one:

Bazaar - it works when cathedral doesn't (distributed version control system)

A bit geeky but tacky and catchy at the same time, don't you think?

Damit they've changed the

Damit they've changed the site:

They used to have their DAG much larger spanning almost full height. From a child's eyes it was intriguing to follow it.

I want to see a very branchy tree as part of the design.... (I know bikeshed colours....)

Completely unscientific,

Completely unscientific, but... Git seems to have taken off when GitHub was born and well known projects like Ruby on Rails switched to use Git and GitHub. Most of the people I talk to who use Git do so because of GitHub. I have my doubts whether these same people would be so inclined to use Git had GitHub not been so compelling.

I use CVS (thanks drupal),

I use CVS (thanks drupal), SVN, Git, and BZR on a regular basis and personally don't care which one I use. When it comes to making bzr more friendly for people one of the things that would be good to highlight is the packages it integrates with, like Eclipse.

For many, they are looking for something that integrates well into their workflow. This is part of the reason GitHub works so well. For a DVCS it really makes it easy to socially code, fork, share, and manage projects. It fits into their workflow and makes it easy.

So, projects, plugins, and services that make bzr easy to fit into the workflow of developers would be a real bonus and selling point. Sadly, this is where bzr fails. Launchpad needs a redesign or some good competition. Programs like coda, NetBeans, and others really need bzr integration to make the project move further/faster. Highlighting these when they come out can be a good selling point, though.

Personally, the first (and

Personally, the first (and second, and fiftieth) time I go to a VCS' website is to look up the command for something I don't do often. That means that for me, I want to find the Documentation section more than any other part.

That said, a quick reference for common and less-common functions would be a boon for any VCS website.

Me too, but I get there

Me too, but I get there though my folder of "docs" bookmarks. If I can find it when I first want it (and if it stays put thereafter,) I'm happy.

One think a lot of people

One think a lot of people doesn't understand are the differences between git/bazaar/mercurial (including me)

I don't know if a comparison of the three systems is a good idea on the bazaar website, but somethink like this would be great.

By the way. i like the Bazaar Personas idea ;-)

So, I took a little time and

So, I took a little time and mocked up my own wireframe. The proportions aren't necessarily approaching accurate, so don't nit pick that too much as it was free hand in skitch.

Maybe imagine this as a 3 column layout? instead of the funky thing it is now. :-)

Ultimately, we end up with a simpler design here, and hopefully consolidate our content. I'm unconvinced that "install" needs as much space as I gave it, but... w/e :-)


RATIONALE: So, odd column


So, odd column count for a more engaging layout.

I removed items I felt were either duplicates of others, or could be consolidated into others. This primarily shows itself with "Extend" and "Help". In the case of help, I simply removed it in favor of making Support and Documentation more prominent. Extend, on the other hand, is a great catch all for things like Plugins, community, and contributions. As such these would probably show up as sub headers within it.

Install, specifically, concerns me since it's not enough room to deliver anything useful to a user for an actual install process, and is really best served by perhaps moving into "support/documentation" as well? I'd actually suggest that, and then create a news section in the same place. That or developer blogs or something.

As the image mentions, I feel that the product should be the center piece (well, this design doesn't have a center, but w/e). The user has come there, HOPEFULLY, to get the product. The site wants the user to HAVE the product. Make it easy, Win/Win. If the user hasn't come there for that reason, that's fine, but we want to convert as many new visitors as possible to our product, so it should be the most prominent item on the page. This goes with out saying, it should also be above the fold...

Those are my thoughts. :-)


In some of your previous

In some of your previous article I had read about Bazaar & Git.But I think this one is better than the previous one.So thanks for it & hope more such articles from you.Olympic weight plate sets

Git for Teams

Git For Teams

Best selling title from O'Reilly media. Covers essential skills needed to use Git in a team environment.

Available from O'Reilly media, and better bookstores worldwide.

Collaborating with Git

Collaborating with Git

Practical how-to videos to get you, and your team, up and running with Git. A complementary video series for the book, Git for Teams.

Available from O'Reilly media.

Drupal User's Guide

Drupal User's Guide

Site building for Drupal 7. Includes in-depth information on Drupal's most popular site building modules, SEO and accessibility. Two complete case studies are included in the book along with the tools you'll need to build (almost) any Web site with Drupal.

Available from

Front End Drupal

Front End Drupal

The industry go-to for learning theming in Drupal 6. A great companion to Lullabot's book, Using Drupal.

Available from