Chaals,
I agree that mediaFeature is the most important property here and I think you're right that we need to be thinking about how we can make implementation easy for developers of search software. Your point on accessMode is also particularly strong when we consider that many times users have already filtered out a lot of content by the type of resource they have chosen to search for. For example, if a user is doing a video search on Google on Yandex, they have already narrowed the accessMode possibilities to visual and auditory combined. If they are deaf, they are most likely only looking to filter their video search by mediaFeature equal to captions or transcript. And if they are blind, they are most likely only looking to filter on mediaFeature equal to audioDescription or transcript. The transcript choice is a fallback choice for both cases.
During the development of the proposal we did a lot of work on use cases and also relied on significant prior work. Chuck Myers is compiling that work in a more consumable form and will be following up shortly.
Cheers,
Gerardo
Gerardo Capiel
VP of Engineering
benetech
650-644-3405
Twitter: @gcapiel<http://twitter.com/gcapiel>
Fork, Code, Do Social Good: http://benetech.github.com/
On Sep 11, 2013, at 1:05 PM, Charles McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>
wrote:
On Wed, 11 Sep 2013 18:43:06 +0400, Gerardo Capiel <gerardoc@benetech.org<mailto:gerardoc@benetech.org>> wrote:
Common use cases we have not really discussed much are based on what happens in integrated classrooms where teachers are trying to serve both students with no disabilities and student(s) with different disabilities. Below are some use cases based on my experiences with users of our Bookshare web library and it's related applications:
[snipped some really good use cases]
Some of these use cases indicate a need for the user to know about the combination of access modes the resource uses and what adaptations exist within the resource to support the assistive technology used by the end user. I believe that merging accessMode and mediaFeature into one property makes it harder for users to make those determinations themselves.
Yeah. I totally agree.
My basic thinking is in part conditioned by how I present this to engineers in Yandex, and in part by what I heard, which included several times that "accessMode isn't really that helpful and we rely on mediaFeature and a set of complex algorithms for matching".
As I see things right now, mediaFeature seems really important as a way to rank results for things that can be useful. I see accessMode as a quick way of removing things that the user simply won't want from that sorting process.
The idea is that if we have 200 resources, and 120 are unable to meet the user's need, we save a LOT of processing by eliminating them quickly. Then we run the more complex ranking algorithms on the smaller set of things that, in principle, *could* meet the user's *needs* - but not all will be equally preferred.
One way I am thinking is that I want to use accessMode as a shortcut to make it cheaper to do more careful checking of mediaFeatures, so users get an exact match.
I'll keep the use cases Gerardo posted, because they are along the lines I have been trying to build up. I think we actually need to make a lot of these, to work through the issues of how we best satisfy them.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> Find more at http://yandex.com