New design proposal
David Tenser
*ducks*
That graphics below the "New to Firefox" box is kinda random, but it's
there to give you the idea that I'd like some sort of artwork or
graphics around that box, to catch the attention. Maybe a part of the
Firefox 3 UI, zoomed in. E.g. the reload icon or something. It just
looks naked without something (http://djst.org/temp/SUMOmockup2.png).
Some points:
* Less vertical space used. No more worry about items getting placed
under the fold.
* Three columnn layout, allowing a proper menu placement.
* More discoverable Thunderbird logo, reducing the number of people
looking for Thunderbird support.
* Footer with links to About page, etc.
* For locales that want to list their own local support sites in the
menu, that should be possible. In other words, the menu would be part of
the wiki body of this page.
Some technical requirements:
* The "New to Firefox?" box would be dynamic in that we would be able to
hand-pick 3-5 tutorials, and they would use the localized titles for
other locales. (We're obviously limited to the "in-product" content here
if we want to guarantee a localized experience).
* All text should be localizeable.
Chris Ilias
What's the minimum width required for a three column layout? Right now,
I test KB articles at 1024 x 768.
David Tenser
The mockup I made is near 1024x768 and there's plenty of empty space
between the columns. The menu will be pretty narrow. I think 800x600
should be the minimum width.
Majken Connor
> _______________________________________________
>
I like where it's going, I think it would look better in the upcoming style
or add-ons rather than the current style. My big nit is the free floating
search box. Otherwise, there's some cohesiveness that would need to be
worked on, but I think I like the layout.
Jason Barnabe (np)
> * Three columnn layout, allowing a proper menu placement.
As long as something sensible happens if there's not enough room for
all the columns.
> * The "New to Firefox?" box would be dynamic in that we would be able to
> hand-pick 3-5 tutorials, and they would use the localized titles for
> other locales. (We're obviously limited to the "in-product" content here
> if we want to guarantee a localized experience).
You're going to have to localize the entire page, so I don't see why
this has to be dynamic.
Where does Home go? Where does Browse the Knowledge Base go? Where do
Privacy Policy, Legal Notices, and Credits go?
How will users who posted in the forum previously find their questions?
David Tenser
> On Jan 24, 3:49 pm, David Tenser <djst.mozi...@gmail.com> wrote:
>> * Three columnn layout, allowing a proper menu placement.
>
> As long as something sensible happens if there's not enough room for
> all the columns.
>
>> * The "New to Firefox?" box would be dynamic in that we would be able to
>> hand-pick 3-5 tutorials, and they would use the localized titles for
>> other locales. (We're obviously limited to the "in-product" content here
>> if we want to guarantee a localized experience).
>
> You're going to have to localize the entire page, so I don't see why
> this has to be dynamic.
I was thinking that the list of articles in the "New To Firefox?" box
would be dynamic much like the top 10 list is (supposed to be).
Basically, we could setup a "content id" tag for this, using the en-US
title names, and tiki would automatically use the localized article
titles in the list if you're navigating to e.g. support.mozilla.com/de
>
> Where does Home go? Where does Browse the Knowledge Base go? Where do
> Privacy Policy, Legal Notices, and Credits go?
Home -> support.mozilla.com (maybe not needed, but pretty standard to
include a link to the start of the site)
Browse the Knowledge Base -> same as today
Privacy Policy, Legal, Credits -> just part of the mockup; stuff we
could link to in the footer that would make sense there
>
> How will users who posted in the forum previously find their questions?
Good point, and we need a link that takes the user back to previously
asked questions. Either a direct link to the Forum, or a more
action-based link reading e.g. "Previously asked questions"
Majken Connor
> _______________________________________________
>
Hadn't we talked about having a different page for "New to Firefox?" that
would have links to tutorials and even videos, rather than having that box
on the main page? Then it would be a menu item as well.
David Tenser
> Hadn't we talked about having a different page for "New to Firefox?" that
> would have links to tutorials and even videos, rather than having that box
> on the main page? Then it would be a menu item as well.
Yes, we've talked about that, and it's still in the plans. That
"different page" (I refer to it as the product landing page) is
basically the start page shown here, but with the "top 10 support" list
replaced with a featured tutorial, and possibly without the menu. I want
the content to be auto-generated because we're using so many localized
versions of the page.
I think the "New to Firefox?" aspect is important enough to warrant its
own box -- not just another item in the menu. It could, however, just be
a big link (similar to the Thunderbird link on that page) and not
actually containing the list of 4-5 in-product articles on the regular
start page. The actual list would then be on the other start page. I
know that mconnor suggested it being just a link.
A slight layout variation:
[Main menu] [New to Firefox? ] [Popular Support]
[ * ] [ ] [ * ]
[ * ] [ Start here! ____] [ * ]
[ * ] [ * ]
[ * ] [Looking for ] [ * ]
[ * ] [Thunderbird Support?] [ * ]
The change here from the mockup is that the New to Firefox? box is just
a big link, and the Thunderbird link is placed below it.
And then for the product landing page:
[New to Firefox? ] [Featured Tutorial ]
[ ] [ ]
[ * Using Firefox ] [ "Exempeltext från ]
[ * Customization ] [ en artikel..." ]
[ * Tabbed Browsing ] [ ]
[ ] [ Read more ]
Here, the main menu is not visible; the New to Firefox box actually
lists articles relevant for new users (all taken from the in-product
help and thus localized); the Popular Support articles list is replaced
with a "featured tutorial" box, containing the first few sentences and a
Read More link. This featured tutorial would also be taken from the
in-product help, and thus localized. Ideally, we (SUMO admins) would be
able to hand-pick and rotate the featured tutorial which would be
reflected on the start pages of all languages.
Of course, the search box is still there above the two boxes on this
landing page, and at the bottom of the search results, we would show a
link saying e.g. "Can't find what you're looking for? Try the search on
the full Firefox Support website!", which would be the exit from this
in-product sumo subset to the full sumo website.
David Tenser
Lucy, you mentioned that you don't like the placement of the search bar,
and I've played around with the current start page by removing the text
between the search bar and the two columns. That seems to have solved
the "under the fold" issue for most screens. So, a possible variation of
my initial suggestion would be to keep the search bar where it is
(perhaps make it use a little less green padding), but still move
forward with the introduction of the three column layout (meaning a
proper placement of the menu).
Note also that I'm trying to do two separate landing pages; one main
page for web visitors, and one focusing on in-product help, which would
use a simpler css, but essentially the same layout. Things that would
probably go away for the in-product landing page are the mozilla.com
header, the footer, etc.
Chris, I noted that you think we should keep a menu even on the
in-product landing page. Could you elaborate that? From my point of
view, that menu couldn't possibly include anything useful, unless we
want to point in-product users to the forum and live chat right on the
start page.
Chris Ilias
Is this design proposal for
<http://support.mozilla.com/kb/Firefox+Support+Home+Page> or
<http://support.mozilla.com/kb/Firefox+Help>?
Majken Connor
> I'd very much appreciate some feedback on this so we can reach a decision.
>
> Lucy, you mentioned that you don't like the placement of the search bar,
It's not the placement, it's in a good neighborhood, it's more themeing
issues. It's free floating rather than attached to something. IMO that was
creating extra "areas" the area between it and the header, the area between
it and the content, the area between it and the edge.
Your playings around, have you linked us to them at all? That is, should I
be able to see what you mean or are you just describing it to us for now?
Another question I had was, in product help isn't going to open in its own
viewer, right? I'm wondering if it's really ideal to separate "in product"
content visually from the rest. Isn't the point to drop the idea of "in
product" altogether, but to create a special entry page to the KB for people
who are getting there from the in product link? That is to say definitely
have a different start page with a different layout, but the theme should
be the same and the headers etc shouldn't change.
David Tenser
Both
David Tenser
> On Feb 5, 2008 3:44 PM, David Tenser <djst.m...@gmail.com> wrote:
>
>> I'd very much appreciate some feedback on this so we can reach a decision.
>>
>> Lucy, you mentioned that you don't like the placement of the search bar,
>
>
> It's not the placement, it's in a good neighborhood, it's more themeing
> issues. It's free floating rather than attached to something. IMO that was
> creating extra "areas" the area between it and the header, the area between
> it and the content, the area between it and the edge.
What I'm saying is that keeping it centered like it is now creates less
of a visual/theme problem, since it's fine where it is now. And by
removing the text under it, and reducing the padding a bit, it appears
we create enough extra vertical space to eliminate the problem for
(reasonably) small screens.
I'd be open, though, to ideas for how to make it look not "free
floating" (not sure what you mean by it) and keep it up there on the
right side of the title bar.
>
> Your playings around, have you linked us to them at all? That is, should I
> be able to see what you mean or are you just describing it to us for now?
>
I only linked to the original mockup, with the search bar moved up to
the left. I'll do a new mockup with the search bar back in center, and
with the changes of columns as discussed earlier.
> Another question I had was, in product help isn't going to open in its own
> viewer, right? I'm wondering if it's really ideal to separate "in product"
> content visually from the rest. Isn't the point to drop the idea of "in
> product" altogether, but to create a special entry page to the KB for people
> who are getting there from the in product link? That is to say definitely
> have a different start page with a different layout, but the theme should
> be the same and the headers etc shouldn't change.
It's not going to be opened in its own special viewer, but in its own
regular Firefox window (possibly sans some chrome like statusbar, etc).
I can see the benefit of at least getting rid of the top mozilla.com
menu bar from that view because it could be a visual distraction, but
this is just a suggestion. The window is likely to be smaller than a
regular Firefox window, and because of that it might make sense to
simplify the layout.
Anyway, glad that we can continue discussing this. I'll get back with
some new mockups to illustrate the ideas.
David Tenser
OK, I've realized this variation in two mockups:
1. http://djst.org/temp/SUMOmockup3.png
Here, the search bar is centered, but with reduced padding and keeping
the Firefox logo at the top left. Please don't worry so much about the
background artwork in the "New to Firefox?" box; again, it's just there
to show that I'd like _something_ eye-catching there.
2. http://djst.org/temp/SUMOmockup4.png
Here, the search bar is up on the top right side again, but this time
I've "anchored" it by making the green box expand to the edge of the
window. This makes it looks less like it's just floating. This layout
could certainly be used for the article views as well, meaning this
might be more consistent throughout the entire site.
Thoughts on this?
Majken Connor
Yes, 2 address what I was concerned about with position. I would still make
some tweaks, for instance the gradiant shows a bit from the bottom, that's a
*really* tall gradient. Ideally the green area would cover the gradient
entirely, but making the box taller also seems like the wrong thing. I'd
rather see the gradient shorter.
I would improve the text, though not sure to what. It says "Search Firefox
Support" right next to "Firefox Support" I might change this to "Ask us a
question" or some other non repetitive text that gives the user an
appropriate instruction.
With the current theme, I would make the green box come out not quite so
far, and I would make the search box longer so there's less green space
between the button and the edge of the screen, though, this is because
aesthetically it's odd to have so much green on that side but not on the
other. If we're redoing the theme altogether, maybe the whole header can
have a green background and the search box can live in it, as well as the
"Firefox Support" heading.
I'm wondering if we should steal the menu/searchbox layout from AMO?
http://people.mozilla.com/~basil/amo/start.jpg
David Tenser
I agree that we can definitely improve the details, but do you guys
think the suggested layout makes sense in general?
Anyway, since you focused on the details, here's some quick feedback:
Agreed about changing the text from "Search Firefox Support" to
something else. Your suggestion is exactly what I had in mind when
discussing this on IRC with chofmann and nelson, since that would also
give us better statistics on what people ask for. But the question was
how well the search engine handles search strings phrased as questions,
and it turns out the answer to that is "not so well." Maybe that's just
about what words you use in the question, but I noticed that e.g. "where
did my bookmarks go" resulted in Lost Bookmarks at fifth place.
Actually, what I had in mind with the green at the right of the Search
button was to make the green expand to the end of the page, regardless
of the user's screen width, meaning the green area would be even wider
if you had a widescreen. Maybe it's better to do the opposite, and let
the search bar have a fixed width and just follow the window's right
border (meaning if you used a widescreen, there would instead be lots of
space _between_ the "Firefox Support" heading and the search box)?
About the blue gradient showing below the search bar, I actually find
that aesthetically pleasing. :) Maybe it's just a matter of taste, but
if people agree with you that it's not looking good, a quick solution
would be to just make the gradient shorter (and make the search bar a
little thicker again). So, no big problem I think.
Stealing the searcbox layout from AMO effectively requires us to use the
centered approach, which defeats the purpose of mockup4, which was to
save vertical screen space. Or did you mean stealing the shape of it,
but still putting it next to the "Firefox Support" heading?
Majken Connor
> > http://people.mozilla.com/~basil/amo/start.jpg<http://people.mozilla.com/%7Ebasil/amo/start.jpg>
> _______________________________________________
>
Actually I believe their mockups are still a win on vertical space as they
have the search bar much closer to the gradient than we could get away with
moving the content to. Of course, if they're still using too much vertical
space for us, are they using too much vertical space for them? If the
concept is most things that we want, maybe iterating together is also an
option.
Then again, how similar are other sites going to look to that and do we want
a separate visual identity? If we like the layout though we could do that
with colors.
But about the mockups you're proposing, all sounds good. my only concern
with fixing the search box relative to the right would be that on very wide
screens the search box would be too far to the left. Of course fixing the
search box relative to the left and letting the green expand also poses
possible issues. It would be interesting to see all the choices on one of
mozilla's 24" monitors ;)
David Tenser
>
> I'm wondering if we should steal the menu/searchbox layout from AMO?
> http://people.mozilla.com/~basil/amo/start.jpg
One thing I like about it is that it doesn't use the word Search, and
instead uses an icon -- less l10n effort.
David Tenser
I also wonder how this AMO mockup would handle a really wide screen.
Would the text field in the search box expand to an eternety? Setting a
maximum width using CSS shouldn't be a problem if we don't want the site
to be too wide. Of course, that pretty much rules out the option of
letting the green background extend to the right page margin.
Majken Connor
centers
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
David Tenser
> Looking at the screenshot already, it looks to me like it's fixed width and
> centers
Yeah, I realized that they're using the maximum width that I even
mentioned in the same paragraph. :)
Anyway, I measured the pixels down to the content in their mockup vs the
mockup I made with the search box centered
(http://djst.org/temp/SUMOmockup3.png) and it's virtually identical,
meaning, not so good.
Of course, if we made our search box as thin as theirs, we would win a
few pixels.
One more benefit I see with having the search bar on the right side of
the heading is that we can keep the layout consistent on all pages,
meaning the search bar could have that location even on article page
views, saving an equal amount of vertical space there.
I'd like to take the thin search bar from AMO and play with it some
more. Might put up more mockups tomorrow. :)
Majken Connor
> _______________________________________________
>
http://people.mozilla.com/~basil/amo/details.jpg this is their version of
an article page. The side nav rolls up to create a wider content area, but
preserving the menu. Not sure if that's as big a win for us, but it's
definitely a cool idea. That could possibly be our "need more help" area.
If we're going to leave the search bar on all pages, I think we should do
what they have, and allow for a dropdown that switches between kb and
forum. I've actually been confused by that a few times myself, though I
know we discussed this at some point, not sure what we agreed on. That's
minor with regards to layout though.
David Tenser
That's an interesting discussion, but let's keep that separate since as
you say it's more of an added functionality of the search bar.
As for the placement of the search bar they're using, it doesn't give us
a win in vertical space usage from what we're having now. That's why I
want to like the right-aligned search bar more, since that gives us
better space usage. I'm torn between the actual visual appearance
between the two alternatives, though.
Alex K.
As a likely 'consumer', in the context of providing support to other
users, I'll add my $.02, for what its worth.
I prefer the appearance of the search bar on the top, as in mockup4,
although I do agree that it should be limited, in some fashion.
In mockup3, it just looks a bit 'disjointed', to me, anyway. Thats the
impression/feeling I get from it.
And to further muddy the waters, I'll add that I also like the
appearance of the amo screenshot, linked above, with regard to the logo,
menu, & search bar layout. It just seems 'visually appealing' to me, as
well as very convenient. I have quick access to the menu, I can search,
as well as choose to limit my search, all from the top of the page.
As I said, just my thought/opinions on the matter. Hope it helps.
--
Alex K.
Majken Connor
> David Tenser wrote:
> > Majken Connor wrote:
> >> On Feb 6, 2008 6:28 PM, David Tenser <djst.m...@gmail.com> wrote:
> >>
> >> http://people.mozilla.com/~basil/amo/details.jpg<http://people.mozilla.com/%7Ebasil/amo/details.jpg>this is their version of
> _______________________________________________
>
Well that probably clears the waters a little, actually. So far everyone
agrees out of David's mockups, so we can play with those as much as we need
to and then compare them to the amo layout afterwards.
Chris Ilias
> Chris Ilias wrote:
>> On 2/5/08 3:44 PM, _David Tenser_ spoke thusly:
>>> in-product landing page. Could you elaborate that? From my point of
>>> view, that menu couldn't possibly include anything useful, unless we
>>> want to point in-product users to the forum and live chat right on
>>> the start page.
>>
>> Is this design proposal for
>> <http://support.mozilla.com/kb/Firefox+Support+Home+Page> or
>> <http://support.mozilla.com/kb/Firefox+Help>?
>
> Both
Okay, I think it's important to identify which page each comment is
about. I thought this thread was just about the web start page.
My comments about having a menu were for the in-product start page.
Content to have:
- search
- new to firefox
- feature tutorials
- ask a question
Content the in-product start page should not have:
- thunderbird help
- top articles
I can see the in-product being a little like
<http://www.mozilla.com/en-US/firefox/features.html>, where a bunch of
features are listed, but with links to their corresponding tutorials.
The current in-product start page has an in-depth menu, and I don't
think it's a bad thing. I'd like to have something similar for the sumo
version.
David Tenser
Thanks for the feedback. I'd like to take a step by step approach to
make sure we move forward while still ironing out the details.
Can we agree on having a proper menu as suggested in all of the mockups?
In that case, we can start working on the wiki syntax of the new start
page and build the new theme using e.g. a copy of the existing mozms.css.
We can then figure out how we want to style this (with search bar
centered or right-aligned, borders around centered page layout, etc)
later on.
The current start page has some css built into the wiki page itself
which I'd like to strip out. Ideally, I'd like the start page to just
define the boxes of information, then the theme would decide completely
how it would look like, including 2/3 column layout and search bar
placement. I believe that should be possible.
David Tenser
> On 2/6/08 4:36 AM, _David Tenser_ spoke thusly:
>> Chris Ilias wrote:
>>> On 2/5/08 3:44 PM, _David Tenser_ spoke thusly:
>>>> Chris, I noted that you think we should keep a menu even on the
>>>> in-product landing page. Could you elaborate that? From my point of
>>>> view, that menu couldn't possibly include anything useful, unless we
>>>> want to point in-product users to the forum and live chat right on
>>>> the start page.
>>>
>>> Is this design proposal for
>>> <http://support.mozilla.com/kb/Firefox+Support+Home+Page> or
>>> <http://support.mozilla.com/kb/Firefox+Help>?
>>
>> Both
>
> Okay, I think it's important to identify which page each comment is
> about. I thought this thread was just about the web start page.
>
It is, initially. But I don't think the in-product start page will
differ too much from the regular start page, so it is worth discussing
that as well.
>
> My comments about having a menu were for the in-product start page.
> Content to have:
> - search
The search bar will be included in the in-product start page as well, so
why does it have to be in the menu? The search should be different here,
though, since it should only search the tutorial/how-to/reference type
of articles (the Help content, as defined in
http://wiki.mozilla.org/Support:PRD#Content_Types).
> - new to firefox
The whole start page will ooze "new to firefox" content. What would this
menu item link to?
> - feature tutorials
What I had in mind here was to have the "Using Firefox" article featured
as one of the boxes on the start page, showing the first couple of
paragraphs or so. When clicking on it, the whole article would be shown.
> - ask a question
I think what we should highlight in the in-product help is the search.
At the bottom of the search, we could include the "Need more help?" box,
and/or a link to perform the search on the full SUMO.
>
> Content the in-product start page should not have:
> - thunderbird help
> - top articles
Agreed.
>
> I can see the in-product being a little like
> <http://www.mozilla.com/en-US/firefox/features.html>, where a bunch of
> features are listed, but with links to their corresponding tutorials.
> The current in-product start page has an in-depth menu, and I don't
> think it's a bad thing. I'd like to have something similar for the sumo
> version.
Having a menu listing the 13 or so "in-product" articles might make
sense, but that could just as well replace the "top 10" box. Something like:
[ Large search box ]
[ List of in-product articles ] [ Featured article ]
[ * ... ] [ ... ]
[ * ... ] [ read more ]
David Tenser
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=416814 about
this. Jason, could you help me cleaning the start page up and define the
associated css in a separate stylesheet instead? Maybe we could
experiment with it on e.g. your personal tiki setup?
The goal here is to have a generic start page that looks like today, but
allows us to implement the design changes later on without modifying the
wiki source of the page.
Mike Connor
On 11-Feb-08, at 9:35 AM, David Tenser wrote:
> The search bar will be included in the in-product start page as
> well, so
> why does it have to be in the menu? The search should be different
> here,
> though, since it should only search the tutorial/how-to/reference type
> of articles (the Help content, as defined in
> http://wiki.mozilla.org/Support:PRD#Content_Types).
Sorry, catching up on mail, why should it only search the "help" and
not the "support" docs? If I think X should work, but it doesn't
because of bug Y, I will not find the article talking about bug Y, I
will only find docs that tell me that X should work, and not why its
not working. The entire point of having "Help" and "Support" in the
same place, at least for me, was to avoid making an arbitrary
distinction and making it one-stop shopping, and a single search
process. People call tech support for how-tos, and read manuals to
try to solve technical problems, its not a clear-cut line in the real
world, and I don't think there's any benefit to trying to force
arbitrary distinctions. (Especially if there's only 13 "in-product"
help docs, which makes the constrained search almost a little silly)
> Having a menu listing the 13 or so "in-product" articles might make
> sense, but that could just as well replace the "top 10" box.
> Something like:
>
> [ Large search box ]
>
> [ List of in-product articles ] [ Featured article ]
> [ * ... ] [ ... ]
> [ * ... ] [ read more ]
I think its a bad assumption to base design off having only 13 in-
product docs, since I bet if I look around I can find material/a
structure that'd work better with 50 docs (I skew towards smaller and
more specific docs for userdocs though). Just because en-US uses
that structure doesn't mean (I hope) that all locales are locked into
the same structure.
-- Mike
David Tenser
> Sorry for delays, my inbox has been a mess lately.
>
> On 11-Feb-08, at 9:35 AM, David Tenser wrote:
>
>> The search bar will be included in the in-product start page as well, so
>> why does it have to be in the menu? The search should be different here,
>> though, since it should only search the tutorial/how-to/reference type
>> of articles (the Help content, as defined in
>> http://wiki.mozilla.org/Support:PRD#Content_Types).
>
> Sorry, catching up on mail, why should it only search the "help" and not
> the "support" docs? If I think X should work, but it doesn't because of
> bug Y, I will not find the article talking about bug Y, I will only find
> docs that tell me that X should work, and not why its not working. The
> entire point of having "Help" and "Support" in the same place, at least
> for me, was to avoid making an arbitrary distinction and making it
> one-stop shopping, and a single search process. People call tech
> support for how-tos, and read manuals to try to solve technical
> problems, its not a clear-cut line in the real world, and I don't think
> there's any benefit to trying to force arbitrary distinctions.
> (Especially if there's only 13 "in-product" help docs, which makes the
> constrained search almost a little silly)
I'm sorry too, I didn't see this reply until now. Just for everyone
else, we've had a meeting where we've agreed on the search approach and
you can read about it here:
https://bugzilla.mozilla.org/show_bug.cgi?id=421149
>
>> Having a menu listing the 13 or so "in-product" articles might make
>> sense, but that could just as well replace the "top 10" box. Something
>> like:
>>
>> [ Large search box ]
>>
>> [ List of in-product articles ] [ Featured article ]
>> [ * ... ] [ ... ]
>> [ * ... ] [ read more ]
>
> I think its a bad assumption to base design off having only 13
> in-product docs, since I bet if I look around I can find material/a
> structure that'd work better with 50 docs (I skew towards smaller and
> more specific docs for userdocs though). Just because en-US uses that
> structure doesn't mean (I hope) that all locales are locked into the
> same structure.
>
> -- Mike
I'd really appreciate more feedback here. I hear you say that presenting
the 13-14 docs on the landing page is not a good idea, but what would
you suggest we do instead? Some problems:
* How can we make sure people understand that the "in-product documents"
really are just a subset of the content available? I.e. how can we make
it obvious that people should search for their problem/task?
* How can we present the documents on the start page, for people that
are used to more traditional product help systems. Do we want to show a
TOC or similar? Right now it's split up between how-tos and references,
because incidentally it turned out there were 7 of them, respectively,
and it worked well with the two-column layout we're currently using. But
that's potentially far from optimal.