– DRAFT –
Personalization Task Force Teleconference

<LisaSeemanKest> regrets, becky

issues https://github.com/w3c/personalization-semantics/labels/1%29%20content%20module

<LisaSeemanKest> https://github.com/w3c/personalization-semantics/issues/66

<JF> +1 Lisa

johns and matt action

johns and matt action

johns and matt action

matt and johns action

JF: Looking into the question of merging attributes with Matthew_Atkinson. There are different options in terms of how/how many attributes to merge.
… We are putting together a list of use case scenarios to illustrate particular aspects of mark-up where developers may have confusion.
… E.g. help: how/do we need to express that as an action/destination/...?
… We would like to take these use cases to people, such as on this call, and maybe others, to think about how we would mark up each of these [short] scenarios.
… Also thinking about other different people in W3C (e.g. Patrick Lauke, Steve Faulkner, implementors with whom LisaSeemanKest is working) to get their views on how the things should be marked up.
… We need to come to a decision but don't need to stop progress whilst we do this.

Matthew_Atkinson: +1 to what JF said. Some approaches posed in the Demo page, but we thought of others. Could see what we're doing as filling in a matrix of use cases/approaches, but we first want to seek views of people as to how to mark up the use cases.

LisaSeemanKest: We have already gone through this exercise with implementers, taking their feedback.

LisaSeemanKest: ... Important to bear in mind this was from practical experience with actual implementations.

<JF> and a strong +1 to weighing the value of what implementers are already supporting.

<JF> +1 Sharon

Sharon: Was expecting a whilte paper with a link from an Editor's Note in the spec to the paper. Didn't realise we were stopping CfC again.

<JF> Our current Working Draft dated January 2020: https://www.w3.org/TR/personalization-semantics-content-1.0/

<JF> W3C Editor's Draft 17 May 2021: https://w3c.github.io/personalization-semantics/content/

Matthew_Atkinson: We're not trying to hold up the process - will work on Editor's Note.
… Have any significant changes been made since the last round of feedback from developers? (E.g. action/destination value changes)

LisaSeemanKest: No

LisaSeemanKest: Should the issue be reopened?

Sharon: The understanding was that the paper would help us avoid going over this decision again in future, as we'd have somewhere to point to to explain what we were doing and why.

LisaSeemanKest: This doesn't seem to be what was resolved last wek.

LisaSeemanKest: The issue seems to be being reopened beyond what was agreed last week; we should postpone for now.

+1 (fine to postpone)

JF: Currently we have a working draft and editor's draft. We are proposing to place a note in the editor's draft to signpost that we are thinking about merging.

LisaSeemanKest: Need to postpone until we have draft wording for the note.

<LisaSeemanKest> https://github.com/w3c/personalization-semantics/issues/66

<LisaSeemanKest> https://www.w3.org/TR/personalization-semantics-content-1.0/#values-0

LisaSeemanKest: I think Joanmarie's concerns with destinations have been resolved, but not actions?

LisaSeemanKest: Can someone check?

LisaSeemanKest: Are we merging or not (determines next steps)?

Sharon: There are some issues that relate to action/destination/purpose.

LisaSeemanKest: We should be able to deal with implied essentiality levels (#184) today, perhaps others (#170)?

Sharon: We need to confirm that the changes proposed were made.

Matthew_Atkinson: Anything I'm posting assumes any changes to action/destination/purpose are _not_ going ahead.
… Regarding #66, think we have "end" as an action and a destination.

LisaSeemanKest: Do we prefer extra comments in a new issue or on the same thread?

This is the URL I was using for the duplicate "end" attr value: https://w3c.github.io/personalization-semantics/content/

Sharon: If it's a different issue, then it needs to be a new issue.

<LisaSeemanKest> https://www.w3.org/TR/personalization-semantics-content-1.0/#values-0

Matthew_Atkinson: the TR version is older than the Editor's Draft version.

JF: It's over a year older.

LisaSeemanKest: There seems to be a problem with the Editor's Draft version.

Sharon: Maybe that Roy was making an edit to somehing which bumped the version.

Didn't JF make a PR that was merged recently? That would've gone into the Editor's Draft?

LisaSeemanKest: Need to discuss on coordination call.

Sharon: There is a holiday next week [as well as for some of us today].

LisaSeemanKest: Be sure to file new issues if a comment is not clearly an extension of the issue at hand.

Sharon: Will check on #170

<LisaSeemanKest> https://github.com/w3c/personalization-semantics/issues/184

LisaSeemanKest: simplification has "critical", "medium" (the default) and "low"

LisaSeemanKest: "critical" is to be used for controls that are essential for the key function (from the user's perspective)

LisaSeemanKest: Note the definitions of the levels: https://w3c.github.io/personalization-semantics/content/#values-2

LisaSeemanKest: What was the reasoning for "delete" being critical?

Matthew_Atkinson: Just wanted to understand the reasoning—by the definitions in the spec it may only be sometimes.

LisaSeemanKest: "escape" can be critical if the user is completely stuck without being able to access it (but not always?)

LisaSeemanKest: options (1) leave as-is; (2) make it implied critical; (3) make it critical but change the definition of "critical" such that it's included.

LisaSeemanKest: do we feel that "escape" should be included? If you're making an app for someone with a progressive disease such as Alzheimer's, and they need to reduce the complexity of the UI
… then when we are looking at an absolutely minimal set of functions to send an email, do we need "escape" or do we just want "send"?

<JF> "Escape" always exists (close the browser window)

LisaSeemanKest: Tempted to say that we may still want "escape" to be there.

<Zakim> Matthew_Atkinson, you wanted to ask about relationshiop with "cancel"

LisaSeemanKest: Let's deal with escape and cancel relationship next.

<LisaSeemanKest> +1 for impies criticle

<LisaSeemanKest> 0 eave as is

<JF> in that scenario, what is the difference between cancel and escape?

Lionel_Wolberger: will cancel be included with escape? What would the user do if they had written an email that they no longer wish to send?

LisaSeemanKest: Is "cancel" currently classified as critical?

Sharon: yes

Lionel_Wolberger: so we're asking if we need to add "escape" as being critical even though they have "cancel" and "send"?

LisaSeemanKest: They may not have "cancel" in any given UI.

LisaSeemanKest: "escape" may not always close the page.

<LisaSeemanKest> other way

LisaSeemanKest: Seems that it should also have an implied simplification of "critical". Escape would always close the page; cancel may not.

<LisaSeemanKest> +1 for impies criticle on eskap

<LisaSeemanKest> (Implied simplification = "critical".) on escape

<LisaSeemanKest> +1

<CharlesL> +1

0

<JF> 0

<Zakim> just, you wanted to point out, Apple left escape off their keyboard

CharlesL: if there wasn't a cancel option on the page, but the developer put in an "escape" action, then the "escape" would be critical. If we are leaving both in, and the developer could choose either, we should make both critical.
… Also I am happy to add a note to the document to that effect.

Lionel_Wolberger: This was a sidenote to mention that Apple left Esc off their keyboards for a while.

LisaSeemanKest: A note would be good becuase Escape is critical when "cancel" is not available.

LisaSeemanKest: Does everyone agree with adding that sentence?

+1

<Lionel_Wolberger> +1 to adding the sentence

<LisaSeemanKest> +1

<Sharon> +1

LisaSeemanKest: The second part, about cancel and escape and the relationship between them.
… I think it's more like a Venn diagram with interlocking circles where sometimes they're related but sometimes they're not.
… E.g. cancel may close a form but not a whole window of the application.

<Zakim> JF, you wanted to muddy the water

JF: Was going to ask about "undo"—or do we want to leave this for now. I like your analogy of the Venn diagram. Can leave this for now if it would delay progress.

LisaSeemanKest: "undo" is about returning to the prior state before making changes. Thinking of people who have perhaps got moderate dimentia, and may be able to perform tasks on the web when three buttons are availalbe [in a box] but adding a fourth would be too much.
… It may be useful often, but not often enough to add it in this extreme case of critical controls.

LisaSeemanKest: Do we mark this closed, or wait until feedback from CharlesL?

<LisaSeemanKest> https://github.com/w3c/personalization-semantics/issues/182

Definition: https://w3c.github.io/personalization-semantics/content/#description-3

LisaSeemanKest: perhaps it normally has a value of low (default?) but it could be used for things that are triggers. So should leave as-is?

LisaSeemanKest: It can't be critical, but it could be moderate or low.

<LisaSeemanKest> leve as is ?

<LisaSeemanKest> +1

Lionel_Wolberger: What if a distraction is an alarm, where something has gone wrong and we need to get your attention?

LisaSeemanKest: We defined distractions specifically as things that are non-essential.

<LisaSeemanKest> detracting content should be distractimg

Lionel_Wolberger: Thank you for all of your facilitation.

+1

<JF> +1 to thanks

<LisaSeemanKest> non-essential detracting content should be non distractimg

LisaSeemanKest: Leave distraction as-is?

<LisaSeemanKest> +1

<JF> +1 (with the spelling mistake fixed)

<LisaSeemanKest> any objectins

<Lionel_Wolberger> +1

0

<JF> I can meet next monday

<janina> https://www.w3.org/wiki/Holidays

<JF> I can

<LisaSeemanKest> who can make next week