Taster: some ideas for a use case on paradata and accessibility opportunities

Note from the JLeRN Team:

One of the tasks we’ve commissioned from our informal task group is some ideas around use cases, from JISC TechDis, on the potential of the Learning Registry and paradata for enhancing accessibility of OERs. Terry McAndrew, the author, will be presenting at the JLeRN Final Workshop on Monday 22nd October and completing it based on feedback and discussion there; but we’d be interested in any questions or points you have as well prior to the final version being published here. The taster below is Terry’s initial thoughts; he’ll be updating them between now and Monday.

So, here is your taster:

Paradata and Accessibility Opportunities – Draft

By Terry McAndrew, JISC TechDis.

The opportunities for the use of paradata for accessibility information regarding resources should not be missed. However, getting all the actors to produce and consume this information effectively clearly requires some thought for a realising implementation. Here are some of the issues we need to consider.

Firstly, the ‘actors’ in these scenarios need to be aware of what is important to capture and share, to enable all potential participants to make the best of the learning and teaching resources available. Generally all actors need to understand that multiple formats for information are necessary to communicate information effectively – it’s just that many omit to produce multiple outputs when delivering to an audience.

These actors can be thought of roles in the learning and teaching cycle and are the Creator, Tutor, Student, Publisher, Curator, Librarian, Accessibility Specialist, Manager, and Technical Infrastructure Manager. An actor can have multiple roles.

If you are thinking all these actors will have to co-operate to use paradata in the same way, this would be a mistake. You would be right in thinking though, that these should be aware of the others’ perspectives.

The actors and their roles

Looking at how the data is modelled in the JSON representation it may be that these actors can be aggregated under ‘educator’ or ‘student’ with additional attributes for the roles they are undertaking at the time of the interaction with the resource. For now, let’s use actors in the looser scenario modelling sense.

Creator: Produces original resource but may be unaware of the accessibility needs e.g. a diagram that lacks quality descriptive information for a visually impaired user in effect needs a ‘radio’ quality description; or a video which needs a transcript for users with hearing difficulties – the transcript provides more usability though; discovery, indexing and usually a better output if the speaker works from a script. The creator however mat wish to declare the purpose or intention of the resource.

Tutor: Uses resources to teach but encounters many different student needs and learning styles; if only they could feed these experiences back into the network to remind the creators of the issues, and how other students with various needs resolved problems. Tutors need to understand that disabilities are by nature often discrete – students do not have their disability “tattooed on their forehead” as many systems would like, just to make it easy to assign the appropraite data. Tutors therefore need to be informed of the nature of the disability.

student: Receives a resource in a context often defined by the tutor, but also as an independent browsing learner. The student need to be able to manipulate a resource independently if they have a disability, i.e. without tutor/demonstrator assistance to engage if possible (mobility impaired: the last thing they want is for someone to move the mouse for them). How, as the consumer, do they feed back this experience in the paradata? Is it gathered by the tutor or given directly – and do they have to declare the nature of the disability (glossory of learning issues) to validate it? Students with a support statement will usually be more active and highlight issues they could have done without. Students without support tend to be more passive, having lower expectations. Paradata could be liberating!

Publisher: Promotes resource into a community, probably using a generic description from interpretation of a complex one. If the paradata was tightly coupled to the resource such that users can easily access the usage information – including the accessibility issues – then the value of the resource may be more quickly assessed. The publisher may be the repository cataloguer.

Curator: Someone who collects interesting information to forward to others with similar interests. They tend to highlight the ‘back-story’ first, as often demonstrated on scoop.it or paper.li, but the same resource will appear in different collections as it has different aspects to be highlighted. How useful would it be to be able to collect these views (why they qualify each other) and feed this into paradata?

LAMs: Library (and museum) staff are taking a greater interest in social metadata — content contributed by users — as it can assist with discovery and description to both augment and recontextualize the content and metadata created by LAMs. They need to be aware of the opportunity to collect accessibility issues and promote the benefits of online alternative where necessary.

Accessibility specialist: Translates information into advice and technologies. They would be ideally placed to bind or interpret common issues. May be occasionally working with staff developers.

Managers of professionals: Who need to recognise that engagement with paradata is part of professional scholarship. They allow time and resources to be made available to use paradata.

Infrastucture managers: Who enable the network and facilities to be utilised most effectively – if paradata recommends a resource in conjunction with a technology solution then that can make anticipatory provision based on this evidence.

So, how can we realise this interaction?

In oder to better understand the work going on with paradata I chose to inform myself, as many do, with the explanatory videos released by the LR team. Technical text needs context in order to understand it better adn get the impression of where it is heading, what elements are ‘concrete’ and others which are still under debate. From these I understood that ‘slice’ waas a practice which could enable the subselection of relevant information. I took this to mean that tools which only needed a smaller proportion of the data could be available to display or capture only the necessary information and therefore reduce confusion. In effect, not to be scared of the complexity that the system can cope with by any given actor role. For those of you without a nervous disposition…

On LR data services http://www.youtube.com/watch?v=gT7YKwmwOoA&feature=related

I was struck by an example given for what was assumed to be a typical use – “state recommends a resource from the khan academy for teaching…” and became concerned that the state may not have considered the accessibility issues it has raised, and whether they would be one of the actor roles I envisaged above? Would they be ones to utilise accessibility paradata when making these recommendations? What tools would they need?

Not too long ago in the subject network (<10 years) we had many discussions about the metadata standards for cataloguing and interoperability – the dreaded ‘i’-word. Committment withered away eventually because all the actors who needed to use them would/could not significantly engage with them, and the supporting infrastructure to aggregate the services through each subject discipline needed consistent management buy-in. This needed to be better informed technically to appreciate the network solutions benefits. However, it was clear that significant work would have to be put into evangelising good practice with interoperable resource database to in effect, establish usage as a professional digital literacy. The community was shifting to less complex solutions – social networks and folksonomies.

Metadata itself maps to a procress already embedded in the business of cataloguing resources – it’s another way to capture and manage classification information so it is a small step to conceptualise this to operate the same processes in another landscape; what was done in libraries and understood by the lay person (who could physically observe books being catalogued and ordered), moved online. Those using online catalogues to search their library could visualise the translation even without technical knowledge, and retained confidence in the process. Those who are more aware of the ­­power of metadata could federate their searches through other agent software, and in effect be in many libraries at once. Paradata is a little more difficult to communicate as a concept; its the library of the conversation about all those books from the library, and more besides.

However, I don’t have to be a developer to get to grips with this – I just have to be able to understand some potential for development.

There is a problem when new technical solutions are facing a new attention challenge; it’s another practice to learn and the community that could benefit from them needs convincing there is a significant gain to be achieved. These potential users may have shifted attention to establishing their own online communities of interest through other free innovations which may be more satisfying to use e.g. curation tools and social bookmarking. They may be far from perfect but they can qualify information about resources and help one find allies with similar teaching problems. This shrinks the gap between the problem and the solution, making paradata capture and exchange less of a vital solution. Now that we have professional CPD from mailing lists to twitter, other innovative solutions need to have similar community benefits; finding similar others etc. Does the paradata networking promote this opportunity? If there are less efficient but far more effective alternatives then these will win out when the perspective of effectivness is from an individual’s perception, not an organisational one.

I followed the technical information to a something called Twitcurl – is this a potential method of harvesting the collection of tweets around a specific hashtag, or quickly poking information into a paradata network from ones own tweets? Could a hashtag and a shortened URI, coupled with account registration (to capture the twitter ID and map it to ones actor roles), be enough to record an interaction with a resource? This may be appealing to educators and students in the same way that using #fb posts status updates.

Another alternative may be a simple Widget to gather reflection by professionals  – something that could be available on all tutor’s and student’s devices to share interaction comments with a resource as it happens – but a context tag of accessibility info, would probably help. At this point a controlled vocabulary for disabilities may be required e.g. V.I., Blind, Deaf, Hearing Impaired, Print impaired, Mobility impaired etc. We are drifting back to metadata standards again. Oh dear!

It appears the accessibility content could be expressed as an ‘activity stream’ when sharing specific actions on what people did with an object, but the accessibility information is not simple transactional information – ‘teacher posted a transcript’ is not ‘teacher found it necessary to post a transcript to engage hearing impaired students’.

A resource could have accessibility paradata information utilised in parts of the JISC curriculum lifecycle – design, (re)develop, deliver, support, evaluate. Being able to collate evaluations from students and teaching staff could feed into the next design loop – being able to share a response to the evaluations would promote developments to other potential users (you asked for ……., we did ……..). Being able to filter this by disability may help refine the flow of information between actors and show how a resource is responding to feedback, but a culture change would have to occur to make this commonplace.

Our TechDis Accessibility Passport approach has been available for designers and developers to reflect on the features that may present issues so these can be addressed before a resource is released to the outside world. It works, but has not attracted large numbers of users as they are not finding a need to create a passport for their resources to be used elsewhere – when it is someone else’s risk.

‘One of the key challenges… is how to engage students, peers and tutors in creative and mutually beneficial dialogue characterised by innovative and reflective critical thinking – both in face-to-face, distance and work-based flexible learning contexts.’

Professor Peter Chatterton, Critical Friend to the JISC Transforming Curriculum Delivery through Technology programme

Should we look for accessibility information could be captured by proxies? Colleagues or attendees to presentations who could also see accessibility issues/opportunities – where do they pass comment? How could that be useful for paradata on the same topic? Where do you record your thoughts against this presentation? Does it have an event ID?

Video output online suffers from often suffers from poor quality comment streams – would reflections of its teaching potential be recorded through the nodes and then be harvested against the video by some other merged output.

Finally, I tried to think about how it might be expressed, just so I could visualise what tools might be available to create and use this paradata. Perhaps

{
“activity”: { “actor”: “email address”,”verb”: “recommends”, “disability”: “dyslexia”
“object”: http://resourceurl/resourceX/,
“content”: “individual recommends Xerte LO for dyslexic users to organise and plan”}
}

Some degree of identifer would help collate suitable resources and experiences with them. Does it have to be repeated for each type of disability? that seems wasteful and probably burdensome (repeated entries need repeated human input?)

Using appropriate attributes to capture roles, information could be coupled with type of disability and the purpose for the use of the resource. Here’s a modified example:

{

“actor”: {“role”: “teacher”,
“attributes”: [“elementary”, “math”],
“context”: [“site”, “NSDL”],
“disability”:[“dyslexia”,“planning”},
“action”: {“action-verb”: “viewed”, “count”: 2200, “context”: [“detail page”]},
“time-frame”: {“start-date”: “2011-05-01”, “end-date”: “2011-05-31”},
“object”: {“uri”: “xyz”, “attributes”: [“volcanoes”]}

}

The flexibility in the system exists, and it’s not my role to specify how this can be defined, but I see it can be. I believe it is worth attention to do so to capture an ‘accessibility context’ for any experience.

We have to think about how to engage all the actor “roles” with the process and visualise some scenarios. Perhaps pre-prepared widgets that may be available to all class participants as an experience review (quick feedback form) or class activity review. At primary school it could be part of the leveling processes that are recorded against curriculum performance, perhaps a tool for special needs support worker. In Higher Education it may work best as a reflective tool used by the student to reveal the issues each resource creates. The teaching staff (tutor and demonsrators) may add other observations against the resource but would need to be aware of the disabilities in the class, and how they manifest themselves – input into the accessibility comment may benefit from some professional qualification.

I am less of a fan of the ‘build it and they will come’ approach than I used to be: there are too many competitors for attention. The value of paradata needs some appealing tools for all sectors to slice this information they wish to use, in the way that suits them best. However, each of these interface tools should recognise the value of capturing accessibility information at the same time for the benefit of every potential user.

Single Post Navigation

← Older Entry

Newer Entry →