[rfc] notes on a bazaar homepage refresh

[Martin Pool]

2009/1/23 Karl Fogel <karl.fogel at canonical.com>:
> Martin Pool <mbp at canonical.com> writes:
>> beuno, jml, and I talked about refreshing the bazaar homepage to make
>> it more attractive and to better address our audience.
>>
>> Some notes are below; comments welcome.
>
> Great ideas!
>
>> functional requirements:
>>  * if we split from a wiki, we want the web site to still be easy to update
>>  * in particular want it to be easy to update for new downloads
>
> Well, why not keep the site in bzr? :-) Just as plain HTML/CSS files, I
> mean.

I think we do want to keep it in bzr.  Putting just html in there to
start with would be ok, though I think we'll soon want it to be
something that allows templating across various pages to avoid
repetition.

>
> Keeping it as a wiki would be fine if it didn't interfere with visual
> layout (which is important on a home page).  However, I think the wiki
> does interfere with making things look exactly the way we want, am I
> right?  Not sure how to do arbitrary layout in the wiki syntax.

Right.

>
> Regarding overall layout: the Subversion home page (which has various
> visual distractions that we *don't* need to emulate) is laid out into
> four general quadrants:
>
>          [Get Subversion]           [Get Help]
>
>          [Report a problem]         [Join in Development]
>
> While we don't have to emphasize those exact same areas, it might be
> good think of overall usage categories: what are people coming to the
> site for?  Can they easily find what they're seeking?
>
> In other words, instead of thinking of audience in terms of individual
> identities, let's think in terms in functional categories.  The same
> user may come one day to get help, another day to report a problem.
>
> Because bzr is especially trying to introduce itself to newcomers, it
> might be good to lead off with the "Why Bazaar?" ("What Can Bazaar Do
> For Me?") area.

Yes, indeed.

>
>>  * want a good news feed, and this too could be taken from launchpad
>>  * easy to update both the style and content
>>  * new wiki theme without the header, etc, but matching
>>  * Bazaar brought to you by very large prime numbers :-)
>>  * could theme the documentation site into this too
>>
>> questions:
>>  * how to do this with IS
>
> If non-wiki solution, I assume we'd use the "push-and-update" story from
> http://bazaar-vcs.org/BazaarForWebDevs (?).

We could do it with bzr-upload.  However, if we're going to want it to
do templating, or to read in feed data from other places, then I'm
thinking a cron job that pulls a branch and then runs a script on it
may be best.

>
>>  * more visibly linked to Canonical
>>    - move to bazaar.canonical.com?
>
> What will do the bzr project the most good -- being linked with
> Canonical or with Ubuntu?  Could the project live at bazaar.ubuntu.com
> (with bzr.ubuntu.com as alias)?  Or would those be reserved for bzr
> services related to Ubuntu already?

I think at present Ubuntu has the stronger brand.  Putting it there
could be good, though Canonical and Ubuntu have different names for a
reason (I guess).  Canonical is more than just Ubuntu and Ubuntu is
more than just Canonical.

>
>> use cases:
>>  * people thinking about using bzr
>
> Yes.  Maybe we should break that down into:
>
>   + people new to version control thinking about bzr
>   + people coming from centralized VC (proprietary or svn or cvs)
>   + people coming from other decentralized (git, hg, bk)
>
> A side note about the other-dvcs case: we ought to be looking in their
> issue trackers for unimplemented feature requests that are doable in &
> consistent with bzr.  It never hurts to implement features that people
> say they want and that others are not providing!

Nice point.

>
>> people have different ways to decide what to do:
>>  * scan the documentation,
>>    - look for docs that specifically relate to them:
>>  * social proof - eg who's already using it, and what did they say
>>  * news and signs of activity
>>  * just download it and poke at it
>>  * screenshots
>>  * screencasts
>>  * faq or bug lists
>>  * look at the source code
>
> Take a look at http://subversion.tigris.org/ for how we organized a very
> similar list.  Again, there's a lot of visual distraction around the
> core site, so I'm not holding that up as some kind of ideal, but there
> are some good presentation ideas there I think.

Yes, that was one of the sites we looked at, and it's pretty good,
though has you say quite crowded.  In fact it's kind of a good example
of why the project home page as such should be separate from the
meta-level elements introduced by putting it in a wiki or a project
collaboration site.

It's very information-dense but still pretty readable.

I heartily sympathize with the wish that people would read the bug
report instructions but it sounds a bit, um, beleaguered to ask for it
three times on the home page.  It conveys a bit of "our users aren't
as smart as we'd like".

It could do with some more color or pictures or screenshots, and so could we.

The download page is interesting because one of the comments we've had
is that ideally you'd get an installable package with a single click
from the homepage, as you do from say <http://getfirefox.com/>.  This
is not quite trivial:

 * detecting the browser's OS requires a bit of server-side or js
code; it's probably not rocket science
 * at the moment we have two or more windows builds for different
situations; we may or may not be able to reduce them to a single
installer with options
 * for some unixy os's the best advice is not a download but a command to run

Still I think we could have buttons for "Windows", "Mac",
"Ubuntu/Debian",  "Red Hat/etc", and then "other options", to get
source, old versions, etc.

>> team blog?
>>  * would we generate enough content?
>>  * would people feel happier doing "official" content there than on a
>>    personal blog?
>>  * will it just compete with the planet
>>  * could get summaries of
>
> As a user, I've never felt I was more likely to choose a piece of
> software because its team had a blog, nor because of anything they were
> saying on the blog.  Have you?

I have looked at blogs in clicking around to get an impression of the
software before installing it, and it does help shape my impression of
how active they are, how they think about their project and their
users, and so on.  I don't know if it's ever tipped the balance.

I do think a too-rarely updated blog is possibly worse than none at
all, but also that there are interesting stories that are not formal
enough to be announcements, but maybe more impersonal than a personal
blog.

>> call to action(tm):
>>  * send this to the bzr list - danger of bikeshedding
>>  * beuno may be able to help with design
>>  * can do the script in parallel with getting it design
>>  * or should we use eg Drupal?
>
> What would Drupal get us that Launchpad wouldn't?  (Not a rhetorical
> question.)

Hm, I'm not sure how it would be an alternative to Launchpad.  What I
meant was Drupal as an alternative to keeping source and html
templates in a branch.

My answer to that would be: the general topic of taking some text and
other content, mixing it with html templates, and both reading and
writing feeds in the general type of thing that Drupal does, and it's
worth considering if there's something off the shelf.  But, great as
Drupal seems, I think it's not a good tradeoff for us: we don't need
many pages, we want editing through a branch rather than a web
interface, and if we do need some custom code to make the

-- 
Martin <http://launchpad.net/~mbp/>