Re: [web-annotation] Allow >1 role per resource

> On 21 Nov 2015, at 23:36, Doug Schepers <notifications@github.com> 
wrote:
> 
> @iherman <https://github.com/iherman> Of course I agree with your 
reasoning to use the Priority of Constituencies (users over authors 
over implementors over specifiers over theoretical purity),
> 
O.k. This means that we should not argue about the complexities of the
 UA-s (because their increased complexity is minimal, ie, that is not 
really what counts). The only thing that really matters is what user 
may or may not prefer; UA-s will adapt.
> but I differ with your conclusion.
> 
That is fair. :-) 
> As @azaroth42 <https://github.com/azaroth42> points out, users 
aren't going to hand-code annotations [1]. Unlike tagging, where users
 can select from a pre-set vocabulary or even write in free-form tags,
 users won't be explicitly selecting the annotation motivation, 
they'll be selecting it from UI options, which are most likely to be 
modal (e.g. you either select the highlight tool, or the comment tool,
 or whatever other tool; for variations (like editing), you might type
 into the input field for some aspect, or leave it blank. Based on 
which tool the user selects, the UA picks the most appropriate 
motivation. (If the motivation choice isn't clear, then that's a 
problem with which set of motivations we've define, which is why I 
raised #113 <https://github.com/w3c/web-annotation/issues/113> ).
> 
> So, the question is, what behavior best meets user needs, each body 
or target having multiple motivations or a single one? You suggest 
that users will always select "more options"; I think it's more likely
 that users want simple choices (or better yet, to not have to think 
at all about the options at this level), to make it easier to create 
an annotation, and also will want their annotations to work the same 
across different annotation UAs. Both of these considerations could 
argue for a single value, which is simpler and more likely to achieve 
interoperablity.
> 
> Obviously, we could construct other arguments around "which is 
better for user experience"… but we don't have real data. I suggest 
that once we introduce multiple values for role, we are not going to 
have the option to step back out of that once we have real data from a
 variety of UAs; whereas, if we constrain it to a single value, we 
could revisit that decision in v2, if some evidence shows that we 
really do need it.
> 
The way I could summarize what you say is that.. we do not really 
know. We are all trying to make conjectures on what we believe the 
users would really use (and, thereby, how UA-s will adapt to those 
needs) and your conjecture is different than mine (more exactly of 
those who were in favour of allowing for more than one role, including
 me).

Where can we go from here? I see two possible alternatives:

1. Restrict the functionality to zero or one, and try to seek 
feedbacks later, with a possible extension in version 2 of the model 
later (although, at this moment, we do not know whether such a version
 2 would ever exist so I am not sure it is wise to plan for it this 
way already now).
2. Allow for the more 'liberal' approach, i.e., allowing any number of
 roles, and mark this features explicitly as an 'At Risk' feature in 
our document, which means that we are asking for the community 
(implementers and potential users) to comment on this issue. (This is 
quite a standard way of operating, we can keep it At Risk up to 
Proposed Rec if we wish.)

I am in favour of the second approach. I presume you will favour the 
first one...
> I like @BigBlueHat <https://github.com/BigBlueHat>'s suggestion that
 we write up examples of both models, and try to test the performance 
characteristics.
> 
Right. We could go down that road, too, but, as I said, I do not 
really believe the issue is on performance, it is, instead, on user 
expectation and usage. Which makes it very difficult to measure and to
 make really informed decision in a short amount of time.

Why 'short'? The current WG plan is to provide a kind of a 'frozen' 
version of the model sometimes very early next year. The current 
version of the model has been considered as being, 'essentially', 
final except for the multiplicity issue, and that is necessary in view
 of our further plan to be CR-ready around April next year, and in 
view of the much more complex open issues in the Protocol and the 
FindText documents. Compared to those, and compared to the WG-s 
remaining timeline, I do not consider this issue is so utterly 
essential, i.e., I do not believe that we should put a major amount of
 work in testing user expectations (which I am not even sure how we 
would do). That is also why I am in favour of the second approach 
above, which would allow us to call out for the community for feedback
 but would also allow us to move on in a timely manner.
> [1]: "the number of annotations that are writen by hand without a UI
 is going to be vanishingly small". (I'm not sure why he though I was 
asserting that people would hand-code annotations… I was referring to 
different annotation generators, not people, making different choices 
about combinations.)
> 






-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/104#issuecomment-158752427
 using your GitHub account

Received on Sunday, 22 November 2015 11:50:10 UTC