OU blog

Personal Blogs

Picture of Christopher Douce

Personalising museum experience

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 Jul 2010, 17:48

Thyssen-Bornemisza museum, Madrid

 Last year has been a fun year.  At one point I found I had a number of hours to kill before I caught an onward travel connection.  Since I was travelling through a city, I decided to kill some time by visiting some museums.

I have to confess I really like museums.  My favourite type is science and engineering museums. I really like looking at machines, mechanisms and drawings, learning about the people and situations that shaped them.  I also like visiting art museums too, but I will be the first to confess that I do find some of the exhibits that they can contain a little difficult to understand.

Starting my exploration

I stepped into the Thyssen-Bornemisza museum (wikipedia) with mild trepadation, not really knowing what I was letting myself in for.  After the entrance area I discovered a desk that was renting audio guides.  Since I felt that I might be able to gain something from the use of an audio guide (and since I was travelling alone, it could offer me some company), I decided to rent one for a couple of hours.

With my guide in hand I started to wander around the gallery.  The paintings appeared to be set out in a very particular and deliberate way.  The gallery designer was obviously trying to tell me something about the history of art (of which I know next to nothing about).  The paintings gradually changed from impressionism, to modernism, through to paintings that I could only describe as thoroughly abstract (some of which I thoroughly liked!)

Extending my guide

I remember stopping at a couple of paintings at the impressionist section.  The disembodied voice of my guide was telling me to pay attention to the foreground, and the background: particular details were considered to be important.  I was given some background information, about where the painter was working and who he was working with.

On a couple of occasions I felt that I had been told a huge amount of detail, but I felt that none of it was sticking.  I didn't have a mental framework around which to store these new facts that I was being presented with.  Art history students, on the other hand, might have less trouble.

What I did discover is that some subjects interested me significantly more than others.  I wanted to know which artists were influenced by others.  I wanted to hear a timeline of how they were connected.

I didn't just want my guide to tell me about what I was looking at, I wanted my audio guide to be a guide, to be more like a person who would perhaps direct me to things that I might be interested in looking at or learning about.  I wanted my audio guide to branch off on an interesting anecdote about the connections between two different artists, about the trials and tribulation of their daily lives.  I felt that I needed this functionality not only to uncover more about what I was seeing, but also to help me to find a way to structure the information that I was hearing.

Alternative information

Perhaps my mobile device could present a list of topics of themes that related to a particular painting.  It might display the name of the artist, some information about the scene that was being depicted, perhaps some keywords that correspond to the type under which it could be broadly categorised.

Choosing these entries might direct you to related audio files or perhaps other paintings.  A visitor might be presented with words like, 'you might want to look at this painting by this artist', followed by some instructions about where to find the painting in the gallery (and its unique name or number).

If this alternative sounded interesting (but it wasn't your main interest) you might be able to store this potentially interesting diversion into a 'trail store', a form of bookmark for audio guides.

Personalised guides

Of course, it would be much better if you had your own personal human guide, but there is always the fear of sounding like an idiot if you ask questions like, 'so, erm, what is impressionism exactly?', especially if you are amongst a large group of people!

There are other things you could do too.  Different visitors will take different routes through a gallery or museum.  You might be able to follow the routes (or footsteps) that other visitors have taken.

Strangers could be able to name and store their own routes and 'interest maps'.  You could break off a route half way through a preexisting 'discovery path' and form your own.  This could become, in essence, a form of social software for gallery spaces.  A static guide might be able to present user generated pathways through gallery generated content.

Personal devices

One of the things I had to do when I explored my gallery was exchange my driving licence for a piece of clumsy, uncomfortable mobile technology.  It was only later that it struck me that I had a relatively high tech piece of mobile technology in my pocket: a mobile phone. 

To be fair, I do hold a bit of fondness for my simple retro Nokia device, but I could imagine a situation where audio guides are not delivered by custom pieces of hardware, but instead streamed directly to your own hand held personal device.  Payment for a 'guide' service could be made directly through the phone.  Different galleries or museums may begin to host their own systems, where physical 'guide access posters' give users instructions about how visitors could access a parallel world of exploration and learning.

Rather than using something that is unfamiliar, you might be able to use your own headphones, and perhaps use your device to take away souvenirs (or information artefacts) that relate to particular exhibits.  Museums are, after all, so packed with information, it is difficult to 'take everything in'.  Your own device may be used to augment your experience, and remind you of what you found to be particularly interesting.

Pervasive guides

If each user has their own device, it is possible that this device could store a representation of their own interests or learning preferences.  Before stepping over the threshold of a museum, you might have already told your device that you are interested in looking at a particular period of painting.  A museum website might be able to offer you some advice about what kinds of preferences you might choose before your visit.

With the guide that I used, I moved between the individual exhibits entering exhibit numbers into a keypad.  Might there be a better less visible way to tell the guide device what exhibits are of interest?

In museums like Victoria and Albert and the Natural History Museum, it takes many visits to explore the galleries and exhibits.  Ideally a human guide would remember what you might have seen before and what interests you have.  Perhaps a digital personalized guide may able to store information about your previous visits, helping you to remember what you previously studied.  A digital system might also have the power to describe what has changed in terms of exhibits if some time has elapsed between your different visits.  A gallery may be able to advertise its own exhibits.

Challenges

These thoughts spring from an idealised vision of what a perfect audio (or mobile) guide through a museum or gallery might look like.  Ideally it should run on your own device, and ideally it should enable to learn and allow you to take snippets or fragments of your experience away with you.   In some senses, it might be possible to construct a museum exhibit e-portfolio (wikipedia), to store digital mementoes of your real-world experiences.

There are many unsaid challenges to realise a pervasive personalized mobile audio guide.  We need to understand how to best create material that works for different groups of learners.  In turn, we need to understand how to best create user models (wikipedia) of visitors.

Perhaps one of the biggest challenges may lie with the creation of a standards-based interoperable infrastructure that might enable public exhibition spaces to allow materials and services to be made available to personal hand held devices.

Acknowlegement: image from Flickr by jonmcalister, licenced under creative commons.

Permalink
Share post
Picture of Christopher Douce

Understanding Moodle accessibility

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 2 Dec 2008, 17:13

moodle-logo-small.gif

To really understand why things are the way they are today necessitates understanding what has happened in the past. This blog post is an attempt to build up an understanding of the current state of Moodle accessibility by looking into what has happened during parts of its development. My methodology is simple: begin with internet (and Moodle forum) searches, ask a few people to see what they know, and see where it takes me!

Initial results

A quick search using Cuil took me to some Moodle developer pages and the Moodle Accessibility Specification which has the headline, 'the document specifies improvements to the accessibility of the Moodle course management system for version 1.7’' This is useful. Both the page itself and the release number can point me towards some dates. Version 1.7 of Moodle dates from November 2006 onwards (until March 2007, when version 1.8 is released).

Digging a little further in the Moodle documentation, I discover the release notes for version 1.7. This provides a huge amount of information. Release notes are very often overwhealming for the casual reader. So, to help my search, I search this page for the term 'accessibility'.

Under Moodle 1.8 release notes, the words 'the Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards' catch my eye. This is interesting, but what does this mean? Thankfully, there is a link. I’ll try to uncover what the significance of XHTML Strict later. Let's continue with the search for discussions relating to 'major accessibility standards'.

Moodle Accessibility Page

The link found on the 1.8 release notes takes me to the Moodle Accessibility page. The page provides several groups of other links: starting points, standards, legislation, tools and resources. A couple of things jump out at me: a link to the development tracker that relates to Accessibility Compliance in Moodle 1.8, a link to Italian Accessibility Legislation Compliance, and a link to an accessibility forum (guest login required).

It looks like I might be finding some very useful stuff! So much stuff, I need to focus down on what is often very important to me: source code. Code cannot lie, but on its own, it cannot always tell you its history... Thankfully, there are other ways to understand how (and why) things have changed.

Looking at the detail

To enhance the accessibility of Moodle, the developers have created tasks within a combined bug tracker and change management system. This is something that is common to loads of other software developments. Change management systems help developers to keep track of what has changed, when and by whom. If bugs are accidentally introduced as a result of changes, keeping records can help us to understand why. A side effect of a good tracker is that it can also tell you what changes are incorporated into individual releases.

Let’s have a look at a tracker entry to see what one of them says: Indicate type of resource in the name of the resource. This is an interesting one. For screen reader users, having advance warning about the file type is useful, particularly if a link is to a resource that is handled by an application outside of the browser, such as a PDF file, for example.

It’s also interesting to see that the tracker can also contain information about debates about the development of the software and, sometimes, its requirements. Clicking on the 'change history' may sometimes present you with a file that summarises the modifications that a Moodle developer has made to several files to make the accessibility enhancement.

Higher level advice

As well as the Accessibility Specification, one of the developers has created a useful page entitled Accessibility Notes (found within the developer area). This includes an executive summary of some of the guidelines, a roadmap for further accessibility developments, pointers towards future areas of development and a link to some accessibility 'patterns' which have been derived from the Web Content Accessibility Guidelines (WCAG).

Relationship to WCAG?

You often hear WCAG mentioned in relation to different levels of conformance, specifically A, AA and AAA. Whilst searching the terms Moodle and WCAG, I found myself back at the forum that I mentioned earlier which had the title, a forum to discuss 'planned conformance to standards/laws such as the Web Content Accessibility Guidelines (WCAG), Special Educational Needs and Disability Act (SENDA), Section 508 (USA)'

It should be said that there is no formal way to 'conform' to the WCAG guidelines. Whilst some of guidelines can be assessed by machine (by the use of a computer program), some sections of the guidelines require real people to determine whether or not a web page is accessible (according to the guidelines). It should be noted that even if something is accessible under one measurement, to some users, this might not be the case.

The issue of compliance is also complicated by the fact that Moodle (along with many other learning management systems) can make use of different blocks, modules or components in a range of different ways. The way that an application is use and configured can significantly influence its accessibility.

Although there is no definitive statement how Moodle adheres to the different WCAG 1.0 levels, but I have discovered a forum posting that relates to a question about the American Section 508 procurement legislation. But will there ever be a statement about WCAG? I decided to dig further by speaking to one of the contributors to the Moodle Accessibility Specification.

Whilst WCAG is great for content, it doesn’t work so well with interactive systems. The Moodle accessibility specification has been created by distilling accessibility principles and ideas from a number of different sources, WCAG as well as an organisation called IMS (see also the IMS Guidelines for Developing Accessible Learning Applications).

Future work?

It was recently announced that the latest version of the WCAG guidelines (version 2.0) will be soon released. One interesting piece of work would be to carry out an assessment of a 'vanilla' (or out of the virtual box) installation of Moodle against these new guidelines.

Strict!

Earlier on I mentioned that I might explore what is meant by the mysterious words XHTML Strict. Whilst browsing the Moodle accessibility pages, I discovered the Moodle tracker task that asked the developers to move to web pages that are 'marked up' in this way.

One part of this tracker jumps out at me, specifically: 'avoid using, within the markup language in which the page is coded, elements and attributes to define the page's presentation characteristics'. In essence, use semantic tagging on web pages as opposed to tagging that relates to the change of the visual characteristics of a display. Rather than using bold tags to indicate a heading, a developer should instead use heading tags. This way, the tags that 'add meaning' to a document can help users who have assistive technology navigate through a page more easily.

A further comment on the subject of semantic tagging is that if a developer needs to add visual formatting to a page, cascading style sheets should be used (CSS). CSS can be used to separate the structure of the content from how it appears on the users screen. A great illustration of what CSS is and what it is capable of can be found within the CSSZengarden.

There is another line within the tracker problem that was interesting: 'for all new sites, use at least version 4.01 of HTML, or preferably version 1.0 of XHTML'. What does this mean, and is there a difference between the two, and why is a difference preferred? Let’s have a look what they are in Wikipedia which contains a paragraph that explains how XHTML relates to HTML.

It seems there are little differences between the two, except that the HTML pages become well-formed XML documents. Not only can then the resulting pages be manipulated by programs that can manipulate XML (and more easily check for different types of conformance – page checking is mentioned in the tracker comments page), but by insisting that they are 'well formed' may prevent the possibility of 'ill-formed' pages confusing assistive technologies, such as screen readers.

The tracker provides more information about how XHTML relates to accessibility. WCAG states that content authors (and you could argue that a page generated by Moodle is content) should 'create documents that validate to published grammars' (checkpoint 3.2). Other useful WCAG checkpoints include guidance not to use deprecated (now obsolete or old) features, and select W3C technologies when they are available, and use the latest versions. In essence, take advantage of new technologies when they are available for use.

Summary

It seems that accessibility, as a subject, has been discussed on the Moodle forums since November 2005. Since this date, a lot of work has been carried out to improve the accessibility of Moodle, some by the Open University. Evidence of this work can be found documented within the Moodle project without too much difficulty. I hope this post has helped to show where (and how) to find information about Moodle accessibility.

Although it can be argued that no platform is totally accessible, strides have been made to make Moodle more suitable for users of assistive technology. Anyone who uses Moodle has to be aware that the accessibility of such a system does not only depend upon the programming code alone, but also how it is used, and what materials it presents to learners.

Acknowledgements are extended to those who I spoke to during preparation of this post. You know who you are!

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 924218