Re: Reverting symlinks to Recommendations

On 19 Oct 2009, at 10:34 AM, noah_mendelsohn@us.ibm.com wrote:

> 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

That means: the specs would change in place over time to reflect two  
pieces of information:

  * Is this a rec?
  * Is this the most recent thing for this publication series?

>
>> Simplifying the front matter ("nobody reads the status
>> section!")
>
> It's often the first thing I read.

Good to know. We hear a lot of the other as well.

>  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?

That's why we created the print mode: to hide that if you wanted to.  
You can select print mode when reading on your screen or, obviously,  
when printing.



> 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?

[Part of broadening topic of "what UI" for TPAC and moving forward.]


>
>>    - 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.

We have. That's why we intended to require no changes to pubrules. The  
idea was: if you give us a pubrules-compliant document, we will wrap  
it an only made these modifications:

  * Add top, right, left, footer
  * Move status section to the bottom
  * Add new status table at the top.

No other content was to change, and we designed the style sheets to  
not interfere with editor-provided styles by using prefixes. (NOTE:  
Bugs are bugs and we could have worked those out.)

  _ Ian


> 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
>
>
>
>
>

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

Received on Monday, 19 October 2009 16:01:58 UTC