Re: Reverting symlinks to Recommendations

Ian Jacobs wrote:

> * I'm less inclined to do rewriting now that the editors have made 
> clear how strongly they feel about our reformatting  specs after the 
> editors have put on their finishing touches. Other valuable lessons 
> included:  don't put non-w3c branding on specs@

I share your inclination to be very conservative in moving ahead.  Not 
only have we learned that change in this space is very difficult, I read 
you list of what the requirements were for the last attempt, and find that 
even some of them seem less then clearly beneficial.  So, it's not only 
the implementation impediments, IMO.

>     - Providing dynamic status information

I'm not sure what dynamic means

> Simplifying the front matter ("nobody reads the status 
> section!") 

It's often the first thing I read.  Very often I'll wind up looking at a 
draft because it was hyperlinked from a public (non W3C) email discussion 
or blog;  the first thing I want to know is whether I'm looking at 
something that's well along in the process, if it's not a full 
Recommendation, or whether it's some working draft that is likely to 
change.

>     - Providing useful context (links to tutorials, validators, etc.) 
> on the right side

Might make sense on wide screens, and when users run with wide browser 
windows, but what fraction of the time that I read a Rec. do I want to get 
that other stuff?  Often the, screen space is better devoted to keeping 
things simple.  Also, aesthetics aside (and they do matter, I often prefer 
to see this stuff at the top where it can be scrolled off the screen as I 
read, if it's even there at all.  I think the number one thing you want to 
devote screen space to is: the document itself.  Keep it simple.  Could 
one have a single link to "additional resources", perhaps with a popup on 
hover if you really want?

>     - Integration into the rest of the site while retaining much of 
> the branding of the original style.

Yes.

>     - Getting all this without changing pubrules requirements or 
> authoring practices.

Going to be very hard.  Please do ask a broad range of working groups what 
their tool chains, stylesheets, and publication process is like.  I think 
you'll find in some cases quite a bit of sophistication/complexity, and 
quite a bit of variety as people have adapted to meet the particular needs 
of particular specifications.


>     - Giving multiple views of the specs (desktop, mobile, print) so 
> that people could hide navigation.

If it's there at all, yes.

Just my 2 cents.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Ian Jacobs <ij@w3.org>
Sent by: chairs-request@w3.org
10/19/2009 11:13 AM
 
        To:     Chris Lilley <chris@w3.org>
        cc:     Robin Berjon <robin@robineko.com>, chairs@w3.org, 
spec-prod@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Reverting symlinks to Recommendations



On 19 Oct 2009, at 9:04 AM, Chris Lilley wrote:

> On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:
>
> RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>>> We've completed the rollback. This includes:
>
>>> * latest version URIs restored
>>> * reformatted specs no longer appear in TR views, current status
>>> pages, or spec histories.
>
>>> Let me know if you see any issues.
>
> RB> Excellent, thanks a lot, and again many kudos for the rest of 
> the site!
>
> RB> Should we maybe have a BoF/quick session/beer/whatever about new 
> TR
> RB> templates at TPAC?
>
> That sounds like a good idea.
>
> The recent alteration of /TR had a similar effect to 'Last' Call, 
> i.e. it was the first time many of us took a serious look at the 
> proposed changes :)

My current thinking is this:

  * There were a number of things we wanted to accomplish via the 
rewritten TRs, including:

    - Providing dynamic status information
    - Simplifying the front matter ("nobody reads the status 
section!") while leaving the most important bits up front.
    - Providing useful context (links to tutorials, validators, etc.) 
on the right side
    - Integration into the rest of the site while retaining much of 
the branding of the original style.
    - Getting all this without changing pubrules requirements or 
authoring practices.
    - Giving multiple views of the specs (desktop, mobile, print) so 
that people could hide navigation.

    We set up the "print mode" for TRs to look almost exactly like the 
classic TRs (modulo minor formatting
    bugs we could fix in a matter of days). However, I doubt that most 
people realized this, and we didn't
    advertise it loudly. (Perhaps making the classic view the default 
view would have helped, but even then, the
    status section had migrated to the bottom.)

* I'm less inclined to do rewriting now that the editors have made 
clear how strongly they feel about our reformatting  specs after the 
editors have put on their finishing touches. Other valuable lessons 
included:  don't put non-w3c branding on specs@

* And so I would like to find another approach to providing some of 
the benefits mentioned above without any rewriting. For instance, we 
might offer a (prominently displayed) service where one can provide a 
spec uri (or get it through a link or pulldown) and a tool generates 
dynamically the currents status information, available tutorials, etc.

* We had not done this before because it is simply to get all the 
information at a URI rather than having to do the two-step of going to 
a service to get the information.

Thanks again for moving this discussion forward constructively.

  _ Ian

--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447

Received on Monday, 19 October 2009 15:35:20 UTC