<Thaddeus> +present
<Thaddeus> presnt+
<scribe> scribe:becka11y
<scribe> scribe: becka11y
Lisa: we don’t have a full list
of use cases, yet. We are trying to determine if 3 attributes
work or doesn’t and we need more attributes
... content filtering given as a use case; numberfree and
extrahelp - for someone who needed both;
... this isn’t right
Becky: concerned because I don’t
understand how to do this, yet
... I think the problem is that I don’t understand the 3
attributes; Why is one of the 3 attributes, easylang?
Lisa: easylang is text it could be another name; in second example is was something else
Charles: second example is easly lang and aui-number free; We don’t have to use all three; In this example easylang is I am running late and that is going to replace what?
Lisa: when you use easylang it also has to be numberfree
Sharon: was trying for one
sentence that needed both; easylang was replacing the whole
sentence; but if someone only needed the numberfree then it
would be the original sentence with just the numbers
removed
... me idea was user would have picked which they needed -
easylang; numberfree, or both. in the case of both they would
get the easy lang
Lisa: added usecase for someone who is good with numbers and bad with text; and another someone who understand literary stuff well but numbers are the problem
<janina> No problem, Charles.
Lisa: meeting is starting 10 minutes is okay for person who understand numbers but come a bit later is better for somewho who doesn’t want numbers
I couldn’t really do this example in three attributes to help both users
Steve: the first one has options nested but futher ones separate them
Lisa: I think we can get rid of many attributes by using token; but with URI or text ones it gets more complicated; gets confusing when need tokens for multiple items
Steve: can have span with easylang and no context, and then another span with context
Lisa: aui = accessible user
interface
... we can have nested via text pairs; we didn’t want value
pairs because we felt it was too complicated
Steve: nesting is complex and error prone; Clear choices are easier although does have some duplication
Charles: if multiple options, numberfree (remove numbers) and easylang (simplify/shorten) how to combine?
Steve: if say numberfree someone still has to write alternative text; easylang has to do that same (alternative); but if have both have to have 3 alternatives - numberfree only; easylang only, both
<Zakim> janina, you wanted to explore Steve's understanding
Janina: in both cases we are substituting spans of text with different results based on someone’s requirements;
Lisa: but this isn’t all the
time; you might want both numberfree and easylang but not the
same
... easylang is like alternative text; feedback tells you what
just happened (email has just been sent; you have submitted
this request). explain - is a bit more information about how an
interface works
... example: type in a medication and results will give
different aspects of the medicine; dosage; side-effects; etc.
as you select buttons; Some infomation might be marked
critical; so explain might provide a tooltip about what the
side-effects button does; the feedback would be related to
pressing the button and would provide “you are now viewing the
side effects for medicine name"
Steve: we are talking about alternative types of context - which is a simpler concept
s/were/are
<Zakim> janina, you wanted to suggest Lisa is speaking to an orthagonal construct
Thaddeus: thinks Janina example of separating two items is easier to follow and build on
Janina: original was substituting text; now we have branched to feedback which is adding context (rather than substituting); And we are struggling to how to present these different types of context; in case of substitution we mayneed a span; in the case of interjecting we need to know where
Lisa: discussion is how to implement - but we need to make certain we can deal with the more complicated examples
Charles: suggest start with simple use case and get those working before building out the more complicated ones; and a some point it may break and we can go back;
Janina: do we have enough to keep building use cases and continue with the rest of the agenda
<Thaddeus> baselining items as subsition or injection, etc is a standard way of problem solving
Charles: maybe we need to organize this use case document better to distinguish between simple; nesting; substitution
Steve: we are mixing the requirements - we need to separate out what we need vs what we need to implement
Michael: action item to populate a requirements document; and also put a better explanation into each document about what we are about
this pull request removes the content from the modules and replaces with a sentence referring people to requirements document; put the use case section into the 2nd part of the document - what the user might experience using personalization; moved requirement like language to a section and shows how it fufills uses cases and points back to that section; does the same for properties;
requirements - have 3 subsections - what we want personalizaiton to do; added vocabulary structure how we want that structured; 3 host language requirements ( needs to be accepted by host language, not overly complicated, etc)
Lisa: am confused on what goes where? What does specification now look like?
<MichaelC> https://rawgit.com/w3c/personalization-semantics/requirements/content/
Lisa: tried to click through to where it had code (numberfree)? is that meant to take us to a module?
Michael: yes, the only change to
the modules (section 2 use cases and requirements) previously
it had several sections - now it just has a sentence because we
don’t want to provide examples in the module
... only change to the modules is to remove the use cases and
examples into the reqeuirements
Steve: what are modules?
Janina: the different publications
Michael: move the use cases and
requirements into the requirements document - still more work
to be done to organize them properly
... next step is to reword things to be more use case -like and
more requirements-like - will be more clear after further
editing
... use cases describe what a user should be able to do - they
should be high level;
example: simplification - a user changes settings to simplify the content based on importance
<Thaddeus> I agree
<Thaddeus> agree
Michael: need many simple use
cases before move on to more complicated one
... need to expand the number of use cases; would like the use
cases to be more generically worded
... requirements: what are we planning for the tech. to do;
important identification -mechanism to identify the features
based on importance - I would restructure: we need a feature to
identify by importance base on these 3 levels
... feature describe a vocabulary term and its properties;
feature shouldn’t be part of the requirements
Charles: and all use cases need examples?
Michael: I don’t think we have to
have a 1:1 mapping of use case and examples
... not sure if we need personas - rather can be descriptions
of user needs that are worked into use case
Lisa: we do have persona from the
COGA group and some from WCAG; we can link to the COGA
ones
... we developed the wiki page of use cases in order to better
understand how the implementations might work; Need to be clear
if we are just building use cases or building them to test the
possible implementation
... most times we are using these attributes you need more than
one; so we need to make sure we include these more complicated
use cases
Michael: I’m not clear what the
goal of the use case wiki page is; we are getting questions
about the number of use cases and need more
... use cases and feature are currently intermixed and need to
be separated out in the spec.
Lisa: this wiki was to help people understand if the vocabulary proposals would work; for example: would you want more than one easylang in an example;
Michael: want to have clearer structure for use cases and requirements in the specs. - that was the purpose of this pull request
<Thaddeus> +1
Charles: think we can except the structure change; does anyone reject to the pull request as is?
<Thaddeus> I have to drop to take out my dog
<clapierre> +1
<sharon> +1
<Roy> +1
Charles: looks like everyone accepts the change (there were no -1)
Lisa: divide use case wiki into sections to separate out simple and more complicated use cases
Steve: and change the title to make it more clear what the purpose is
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) FAILED: s/were/are/ Present: Thaddeus clapierre janina stevelee Lisa Roy Becka11y MichaelC Found Scribe: becka11y Inferring ScribeNick: Becka11y Found Scribe: becka11y Inferring ScribeNick: Becka11y WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]