Re: Proposal for updating links on webplatform.org

Hi, Chris:

Not sure where we left off, but a few more things have come up around the
global nav:

* We are going to have an Editor's Guide at
http://docs.webplatform.org/wiki/WPD:Editors_Guide for contributors.
Instead of "Join", maybe that link could just be "Editors" and link to the
editor's guide.
* The Events page 
(http://docs.webplatform.org/wiki/WPD:Community/Community_Events) isn't
easily discoverable. Should we have that at the top level for a while? If
not, can you think of a place where we can expose it?

J

----------------------------
julee@adobe.com
@adobejulee





-----Original Message-----
From: Chris Mills <cmills@w3.org>
Date: Wednesday, December 12, 2012 8:55 AM
To: julee <julee@adobe.com>
Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
Subject: Re: Proposal for updating links on webplatform.org

>
>Chris Mills
>Opera Software, dev.opera.com
>W3C Fellow, web education and webplatform.org
>Author of "Practical CSS3: Develop and Design" (http://goo.gl/AKf9M)
>
>On 12 Dec 2012, at 14:15, Julee Burdekin <julee@adobe.com> wrote:
>
>> 
>> 
>> -----Original Message-----
>> From: Chris Mills <cmills@opera.com>
>> Date: Wednesday, December 12, 2012 2:58 AM
>> To: julee <jburdeki@adobe.com>
>> Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
>> Subject: Re: Proposal for updating links on webplatform.org
>> 
>>> On 11 Dec 2012, at 21:31, Julee Burdekin <jburdeki@adobe.com> wrote:
>>> 
>>>> =A few observations=
>>>> 
>>>> * +1 on More not being useful in this schema.
>>>> * Several folks have commented to me that distinction between Q&A and
>>>> Chat
>>>> categories is not intuitive.
>>> 
>>> Maybe we should change them to more intuitive wording, such as "Post a
>>> question" and "Live IRC chat" ?
>>> 
>>>> * Unless we provide example-only or code-only pages, I'm not sure how
>>>> that
>>>> would manifest.
>>>> 
>>> 
>>> Yeah, the suggestion of a "Code" link was really just another idea to
>>> throw out there.
>>> 
>>>> =An alternate global nav=
>>>> 
>>>> Can we help users out with our current architecture of the site by
>>>> handing
>>>> them those actual categories? We could do content types:
>>>> 
>>>> | Reference | Concepts & Tuts | Community | About | Blog | Join |
>>> 
>>> Hrm. I can see where you are going with this, but I also see a lot of
>>> issues with it, and don't necessarily think it is better than the
>>> direction we are going in already.
>>> 
>>>> 
>>>> Where these pages point to the following subcategories:
>>>> 
>>>> ==Reference==
>>>> Platform APIs (ptr to /apis/)
>>>> "DOM" APIs
>>>> CSS APIs
>>>> SVG APIs
>>>> JavaScript Language & Libraries
>>>> 
>>>> ==Concepts & Tuts==
>>>> (aka, Docs: landing page that points to: beginners, general_concepts,
>>>> html, css, accessibility, javascript, dom, svg)
>>> 
>>> My problems with this:
>>> 
>>> 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 ;-)
>
>>> 
>>>> 
>>>> ==Community==
>>>> Forums
>>>> IRC
>>>> Mail list
>>> 
>>> I quite like this idea, of lumping the different communication
>>>mechanisms
>>> together in one top level link. But I'm not sure if "Community" is the
>>> right term for it. Maybe "Talk to us" or "Contact us". The whole thing
>>>is
>>> a community.
>> 
>> Agree. Only thing is "Contact us" sounds like there are two camps. What
>> about "Talk with us"© Main point, though, is providing a list of all
>> channels available.
>
>"Talk with us" sounds good to me.
>
>>> 
>>>> 
>>>> ==Abou==
>>>> Latest news (ptr to Blog)
>>>> What it is
>>>> How it was formed
>>>> General Philosophy
>>>> Stewards
>>>> How you can join (ptr to Join)
>>> 
>>> Yup, so we agree on an "About" top level link.
>>> 
>>>> 
>>>> ==Join==
>>>> Register for this site
>>>> Register for email list
>>>> Logon to IRC
>>>> Check out the forum
>>>> Contribute (ptr to Getting_Started)
>>> 
>>> I think we do need to make the process of joining more intuitive from
>>>the
>>> outset, so maybe we could have a "Join" link. But surely it'd be better
>>> to have registering/logon for forum, mail list, IRC, etc. covered on
>>>the
>>> pages for those tools (e.g. what you've put under "Community", above)
>>> rather than having completely separate pages for them over here? On
>>>going
>>> to those page you could have a bit at the top that says "Login like
>>>this,
>>> or go and register like this", which could take them to the join page?
>> 
>> I like this idea of moving people to a Join page if they're not
>> succeeding. But, we've had more success with getting people on all the
>> right channels by providing them with a cheat sheet like this:
>> 
>>https://github.com/JuleeAtAdobe/wpd/blob/master/getting-started-for-edito
>>rs
>> /getting-started-for-editors.rtf
>
>Right. So kind of a "Get started" type page? I think this is largely
>covered (or intended to be covered in the Editor's guide on the Wiki). I
>think a combination of this and the "Join" page would be good for getting
>people working (The Join page could explain how to get an account, and
>also how to use IRC, Q&A, etc. like points 1 and 3 on your doc)

Received on Thursday, 10 January 2013 18:06:53 UTC