Re: Reverting symlinks to Recommendations

Thank you for the careful response.

> No other content was to change, and we designed the style sheets to 
> not interfere with editor-provided styles by using prefixes. 

Am I right that you also changed fonts, in some cases colors, etc.?  All 
of those things can either improve or detract from the readibility of a 
document, sometimes even for accidental reasons (lack of contrast with 
colors in an image).  I really think that good editors proof their 
documents in several user agents, and with an eye toward things that might 
not have been obvious at the markup level.

> You can select print mode when reading on your screen or, obviously, 
> when printing.

I don't like the idea of overloading the "print" abstraction this way.  In 
my experience, there are a variety of things one sometimes need to do to 
get printing right, e.g. to fudge font sizes to keep boxes from blowing 
off the sides of the printed page.  I believe I worked on that on and off 
for several weeks for the SOAP Recommendation.  In those days, CSS wasn't 
as robust (or I didn't know it as well), so I think the fonts we used were 
the same for screen and print, but they were the result of considerable 
experimentation with Print Preview in a number of browsers.   If you do 
want to have all that other stuff as the default when looking at a Rec on 
screen, then I would probably prefer a button like "Clean screen" or 
"Document-only" or some such if an interactive user wants a clean copy.  I 
think the "print" meme is really a relic of advertising-driven sites, that 
want you to believe that their clean views are only for print. 

I still think that less is more:  a very simple, small header line, or 
maybe a small wrapround box in the upper right as a wormhole into more 
help would in many cases be better than something elaborate.  Most of us 
who open a spec just want the best rendering we can get of the spec 
itself. 

Noah

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








Ian Jacobs <ij@w3.org>
10/19/2009 11:55 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     chairs@w3.org, chairs-request@w3.org, Chris Lilley 
<chris@w3.org>, Robin Berjon <robin@robineko.com>, spec-prod@w3.org
        Subject:        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:56:20 UTC