Getting from fp.o to a download
Objective: Make it as easy as possible for a new Fedora user (who may not be familiar with Linux or even operating systems, but knows that he or she wants to "download Fedora" for whatever reason) to get from http://fedoraproject.org to having the appropriate file downloaded on his/her computer.
What's hard about it now
- Max Spevack's blog post
- Mel's braindumps
- thoughts in comic form - also read the comments.
What other distros do
Mark and Max looked at what other distributions look for this. Assumptions and results below.
Assumptions
- On the main sites of the distributions below we only looked at how easy it was to get to the download page
- and how good (or bad) does that look compared to fedora
- and how obvious a link to the download page was
- The idea was: how would new users, any new users experience the road to the fedora download page
- that includes complete pc n00bs
- and highly advanced pc users
Fedora
On the fedora main page: no clear direct place to download it. Even better not a single "download" on the page. At first sight not obvious at all where you need to click. If you click on the big fedora "banner" you are linked to the tour page. Every single link outside the menu brings you to some place else then the download place! The only places where you can click to download it is: the small banner on the top left with the lion in it or the relatively tiny "Get Fedora" link in the menu. This is not obvious and requires the user to just look around first. Might be a good marketing trick but to me personally it's just annoying.
OpenSuse
"Get It".. and then? then you get a range of radio buttons. Ah no, i have to make choices! Avoid that at default and provide an advanced option with those choices.
Mandriva
At first sight not clear where the download button is (http://www2.mandriva.com/) but when you click that (top center) then you get a very fancy looking download page. It looks clean and to the point. We should have something like this or better.
Ubuntu
You can't miss the download there! it's right in the header and not something you miss. We both saw this as a very clear and fast way to download it but is it nice? We didn't think so.
Mockups
This section is for mockups of designs that would make the objective better.
Get Fedora
This is a mockup of the Get Fedora page. This is just to show how it could be done. The colors are way out of the fedora range but it does show the simplicity for new users.
Main fedora page
This is a mockup of the FedoraProject.org homepage. This is just to show how it could be done. The colors are way out of the fedora range but it does show the simplicity for new users.
Signing up for the web group
This is something Mark noticed when he needed to sign up for the web group. It's not said on that page anywhere! Perhaps not needed?
- I don't understand -- there's a box right above the red comment that says you don't need to apply for the 'web' FAS group right away. Was Mark making the point that this box says something that's not true? Or did he not see it? --stickster 11:40, 13 June 2009 (UTC)
- I don't understand -- I did see that but if you want to subscribe i would expect it to be described on that page. The page only says you don't need to be subscribed. Just something i noticed. --markg85 17:31, 18 June 2009 (UTC)
Things fp.o visitors should be able to do
This section needs work and expansion into a potential tasks/deliverables/milestones list.
Roles
It may make sense to frame these things in terms of a number of roles... (from old notes from Max)
- Look and feel: This is a group of contributors whose interest and expertise is in making the Fedora family of websites look and feel consistent. They're ambassadors to/from the Fedora Design Team and come up with a unifying CSS and look/feel for all Fedora sites.
- Infrastructure: This is a group of contributors whose interest and expertise is in the process of running a variety of websites, and in making sure that we have a good way of keeping content updated. They're ambassadors to/from the Fedora Infrastructure team and make sure that we have processes and procedures that are as light as possible while still giving us a consistent way to push updates and keep our content correct. These folks also maintain a list of all fedora-owned domains and subdomains (like fp.o, fedorahosted.org, spins.fedoraproject.org), or "major fedora web applications" (like the wiki or FAS).
- Content: This is the group of people whose interest and expertise is in the actual content of our websites. They're ambassadors to/from the Fedora Docs and Marketing teams. They work with the marketing team on the strategic messages that we want to send in different places of our web portfolio (and in what medium - is it text, video, podcasts, etc?) and determine where the best destination for that content is (including fp.o sites, but also other press and RH communications such as Red Hat Magazine). And they write it and keep it up to date.
- Spins: This might be a SIG or project group that draws on the skillsets of the roles above, but since this is such a big construction project... the aim of this group is to build a web app that can be a useful spins inventory, repository, and acquisition mechanism. This is going to require some recruitment of other volunteers, as it is a pretty major engineering endeavor that needs to be run in the same was as any other Fedora Feature is.
Ticketing system
Proposal: that we use bz to handle both work tickets and email "support" requests sent to webmaster@fp.o.
Benefits:
- easier to search for outstanding tasks and see completion status
- more flexible tracking of outstanding tasks; metadata sortable, etc. vs multiple wikipage tables
- easier threading of discussions on outstanding tasks
- easier to track who is assigned to what, and ping them (and, if bz's nag list functionality is enabled, to get reminders for yourself)
- websites contributions get tracked "at the same level" as other (code, particularly) contributions
- perhaps we can even configure bz to send an autoresponse to webmaster@ queries
Risks:
- people might not switch over to the bz system - this is mitigated by having someone on the ball to port things over and remind people for a month or so until it becomes habit. Mchua volunteers.
- others?
Implementation cost:
- one-time transfer of wiki tasks lists to bz (simple; one person can do it in an afternoon, Mchua volunteers)
- hooking webmaster@ requests to go to bz, or assigning someone to forward and file them as such (should be fairly simple, a few minutes)
- optional: configure bz to send an autoresponse to webmaster@ queries
- documentation of process (an hour, and then another hour in a week or two to follow up and finetune based on usage)
- letting everyone know how to use it (biggest timesink and most difficult part)
j.fp.o experience
One possible effectiveness metric for our website might be the number of contributions each release gets from new contributors (i.e. contributors whose first contributions were in that release) - in other words, "does join.fp.o work"? (Not that j.fp.o is the only thing that will get more people pitching in, but that's what it should aim for.)
The joining experience should be toured through and documented, as a first step... then the rationales behind the design of each step should probably be examined.