W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2012

Re: Proposal for updating links on webplatform.org

From: Chris Mills <cmills@w3.org>
Date: Wed, 12 Dec 2012 16:55:05 +0000
Cc: public-webplatform@w3.org
Message-Id: <CF4D97A5-5147-49CE-B2F0-1E34BAACE34E@w3.org>
To: Julee Burdekin <julee@adobe.com>

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-editors
> /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 Wednesday, 12 December 2012 16:55:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:45 UTC