Re: Proposal for updating links on

In discussing this proposal during the Content Task Force call today, 
the group wasn't sure how the next level would be organized. We'd like 
to see how this works at that level, in order to get a better sense of 
the user's experience.

On 12/12/12 11:48 AM, Chris Mills wrote:
> I guess that would be the ideal. So we'll need to have a think about how to provide both capabilities in a seamless way. Would it work to have something like this?
> Have a top level menu item of "Docs"
> On hover it comes up with three subitems
> Docs
> |
> +- Browse by technology
> |
> +- Browse tutorials and concepts
> |
> +- Browse references
> If you click Docs or the first option, it brings up the docs page pretty much as we have it now. If you click on the second or third pages, it brings up alternative landing pages  that just cover the tutorials/concepts, or references, laid out in a different way?
> These would need auto generation so that things stay current and it doesn't become a maintenance nightmare.
> What do we think? Good? Terrible?
> On 12 Dec 2012, at 17:26, Eliot Graff <> wrote:
>> I was under the impression--and I think this a good idea--that we were providing both navigational models. Readers can find what they're looking for by technology: go to Canvas and then look for tutorials, reference, etc. for canvas. They can also navigate by content type: go to the tutorials and find tutorials on canvas, appcache, and CSS.
>> This is what we're striving for, yes?
>> Eliot
>>>>> 1. I think it is good to be able to go to one landing page for all
>>>>> documentation, be it ref or tutorial - docs currently does this. This
>>>>> immediately fragments the user's navigation decision and makes them
>>>>> think about what they want in the first instance. "HRM, I want to
>>>>> learn something about technology X. Do I want reference documents or
>>>>> tutorials?" versus "I want to learn something, so I'll start off by
>>>>> going straight to docs." Once they've made a click, they are already
>>>>> invested in their journey into the site.
>>>>> 2. I think people are more likely to want to search by technology,
>>>>> rather than type of documentation, so breaking it up like this in the
>>>>> first instance is not the best way to go, imo.
>>>> I see what you're saying. But then why do we separate out reference in
>>>> the first place? And how do we show the relationship between the two
>>> sections?
>>> In the new landing pages I have created, the pages will be separated out first
>>> by technology, so HTML, CSS, JavaScript, DOM, etc.
>>> Then on each sublanding page, the pages will be separated out by page types.
>>> So CSS learning pages (tuts and concepts), CSS property reference, CSS at rule
>>> reference, etc.
>>> It is still worth separating out the page types, as each will require different
>>> info. And there will be relationships forge by the related pages links we are
>>> planning to add to each page.
>>> I am now also thinking that it would make sense to have a page just containing
>>> links to all the tutorials. But then, getting between them would be made
>>> easier when we have this global WPD navigation menu we have been talking
>>> about. Whihc is another thing we need to decide upon ;-)
>> on your doc)

Janet Swisher <>
Mozilla Developer Network <>
Technical Writer/Community Steward

Received on Thursday, 13 December 2012 21:24:37 UTC