Re: [personalization] Task Force - first call minutes

Hello Baldur,

I wonder if - to allow vanilla browsers managing Web Publications - having a publishers' developed Web Application "importing" and presenting Web Publications from the same publisher could be a proper solution. Doing so, a publisher could centralize the code necessary for paginating and personalizing the publication. The bad aspect would be that each publisher would offer a different personalization UX, but it would avoid a per-ebook UX at least. 

It would clearly differentiate the notion of application from the notion of publication, and at the same time create a seamless experience for the user. 
  
Cordialement,
Laurent


> Le 28 juil. 2017 à 14:21, Baldur Bjarnason <baldur@rebus.foundation> a écrit :
> 
> Hi all,
> 
> One of the biggest use cases for web publications is using the browser as a UA. That is a major, core use case for many of us participating in this process.
> 
> That absolutely means that we have to account for situations for when the ‘reading system’ is actually embedded in the publication rather than provided by the UA because that’s key to providing a nice progressively enhanced experience. Most browsers probably won’t provide a publication-specific UI, and even if they do, it will take time to implement and we still have to provide a good experience for the users on older browsers.
> 
> What will happen if you don’t account for the UI for reading and personalisation being provided by the publication instead of the the UA is that most publications just won’t support personalisation. Reading in the browser is certain to be a major discovery and consumption path for web publications, no matter how little or much support browsers end up having for web publication specs.
> 
> This also means that if we want to support UA-provided UIs we also need some mechanism for publications to discover when they don’t need to provide an UI. This has the potential to be hairy which is, I’m guessing, one of the reasons why Leonard favours the ‘everything is provided by the publication’ approach.
> 
> - best
> - Baldur Bjarnason
>  baldur@rebus.foundation
> 
> 
> 
>> On 28 Jul 2017, at 07:53, Laurent Le Meur <laurent.lemeur@edrlab.org> wrote:
>> 
>> Hi Leonard,
>> 
>> It would be useful to specify common vocabulary to be sure we understand each other. I can make a try, but I'm not a native english speaker so ...
>> - presentation: the appearance of the content
>> - personalization: results of actions a user can apply to the presentation of the content
>> 
>> An author must have control on the default presentation, I guess there is a strong consensus there. 
>> A question is: should the *actions* (buttons and selections) offered to the user for personalization be provided as part of the content? 
>> IMO the answer is no: such actions must be at the UA level, and resulting CSS modifications must be "injected inside the content" by the UA. 
>> Do you agree with that?
>> 
>> laurent
>> 
>> 
>>> Le 28 juil. 2017 à 13:10, Leonard Rosenthol <lrosenth@adobe.com> a écrit :
>>> 
>>> Sorry I missed the call – great stuff and thanks for the minutes.  I am really glad to see us moving towards heavy semantics for content from which presentation can be derived!
>>> 
>>> I do want to comment on one item in there:
>>>> some people in the working group think that reading systems should not exist and that everything should be included inside the publication.
>>>> 
>>> I am one of “those people”.  
>>> 
>>> I believe that an author should be able to have control over the *default* presentation of their content.  Meaning that the way that the user should initially presented with the content is one that behaves accordingly to the author’s wishes.  *BUT* if that isn’t a presentation that works (eg. accessibility or device-size considerations), then a user should then be able to apply their own personalizations/choices as needed.
>>> 
>>> I also believe that some aspects of the content *must* always be preserved by personalization – for example, relative font “categories” and sizes.  For example, if the author picked a sans-serif font for a particular piece of text, then while a user may prefer a different sans-serif font, they can’t replace it with a serif font.  And if headings are 1.5% of body text, that relationship must remain even if the actual sizes increase/decrease.
>>> 
>>> Leonard
>>> 
>>> From: "Teixeira, Mateus" <mteixeira@wwnorton.com>
>>> Date: Thursday, July 27, 2017 at 10:47 AM
>>> To: "public-publ-wg@w3.org" <public-publ-wg@w3.org>
>>> Subject: [personalization] Task Force - first call minutes
>>> Resent-From: <public-publ-wg@w3.org>
>>> Resent-Date: Thursday, July 27, 2017 at 10:46 AM
>>> 
>>> Thanks, all, for joining our first conversation about the personalization of web publications. Minutes are here: https://www.w3.org/2017/07/27-pwg-ptf-minutes.html
>>> 
>>> It sounds like we have a rather clear direction on how to approach this issue. As I said in the call, I will go through our discussion and pull out threads we can delve into more deeply in GitHub. As we discuss, I will formulate a skeleton draft that we can collaborate on.
>>> 
>>> Best,
>>> Mateus
>>> 
>>> ---
>>> 
>>> Mateus Manço Teixeira
>>> Co-Director, The Norton Lab
>>> Manager, Ebook Production
>>> 
>>> W. W. Norton & Company
>>> Independent Publishers Since 1923
>>> 500 Fifth Avenue, New York, NY 10110
>>> wwnorton.com
>>> 
>>> 
>>> From: mteixeira@wwnorton.com
>>> When: 10:00 AM - 11:00 AM July 27, 2017 
>>> Subject: W3C PWG Personalization TF
>>> Location: WebEx - See info in invitation body.
>>> 
>>> 
>>> Hi all, 
>>> 
>>> Tomorrow is the inaugural call of the Personalization Task Force. Our role is to define personalization in a Web Publication context, and to identify restrictions, use cases, and overlaps between our work and other parts of the specification (and between our work and existing standards). Especially as a newbie, I am looking forward to working with you and gathering your feedback and guidance. 
>>> 
>>> 
>>> Agenda 
>>> 
>>>  • What do we mean by "personalization" and what use cases do we need to consider? [1] 
>>>   • User's customization of the user agent and publication 
>>>   • Author/publisher's customization of the publication and prescriptions to the user agent 
>>>   • (Other avenues for personalization?) 
>>>   • Restrictions to personalization 
>>>  • Difference between content authoring and user choices 
>>>  • Where does our work overlap with other WP task forces? 
>>>  • Where do we intersect with other W3C work? 
>>>   • Assign/forcefully-but-nicely volunteer people for scouting and outreach. 
>>> 
>>> 
>>> Logistics 
>>> 
>>> IRC: #pwg (barring any objections) 
>>> 
>>> WebEx: W3C PWG Personalization TF 
>>> Thursday, July 27, 2017  
>>> 10:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr  
>>> 
>>> Meeting number (access code): 634 347 893  
>>> 
>>> Meeting password: NxVpjSx6 
>>> 
>>> When it's time, join the meeting. 
>>> 
>>> 
>>> 
>>> Join by phone 
>>> 1-650-429-3300 Call-in toll number (US/Canada) 
>>> 1-866-469-3239 Call-in toll-free number (US/Canada) 
>>> Global call-in numbers  |  Toll-free calling restrictions 
>>> 
>>> 
>>> 
>>> [1] Laurent shared the following existing views on personalization as it is defined in most reading systems today: 
>>> 
>>> - currently, personalization generally includes  
>>> * display variants for collections of books (list/mosaic, sort order) 
>>> * night mode 
>>> * theme 
>>> * font size, font, spacing, margin size, text justification,  
>>> * appearance of page numbers (or other way of locating the user in the book) 
>>> * background and text color 
>>> * page animation (turn ...) 
>>> * management of bookmarks and annotations 
>>> 
>>> - we will study in the future additional a11y features like 
>>> * activation of specific key controls on a desktop app 
>>> * activation of vocal controls on a desktop app 
>>> * activation of specific displays for cognitive impaired people (incl. dyslexic people), using enriched content 
>>> 
>>> Note that Jiminy Panoz is currently working for EDRLab on a Readium CSS project, which tackles the difficult subject of the differentiation between what the author's CSS will propose and what the user choices will impose, taking into account what the reading app CSS will require (mostly pagination). More on https://github.com/readium/readium-css/issues. 
>> 
> 
>