Characteristics for the users of a hypothetical OER

25 Oct, 2015 11 min read digital-literacies, ux

Context

This post is another entry related to a hypothetical user interface design as part of my study towards an MSc in User Experience Design. These blog posts should be viewed as rough and reflective and are concerned with a project for a fictional university. The first point to clarify is, what exactly is an Open Educational Resource and why would a potential client want to build one? I personally find the following definition from Jisc to be the most helpful:

What is an OER?

Open educational resources are teaching and learning materials that are freely available online for everyone to use, whether you are an instructor, student or self-learner. Examples of OER include: full courses, course modules, syllabi, lectures, homework assignments, quizzes, lab and classroom activities, pedagogical materials, games, simulations, and many more resources contained in digital media collections from around the world. Jisc, from “Open educational resources (OERs)” (direct link).

So the point is that an OER can be almost anything, what distinguishes it is the fact that it is an openly available resource. In the interest of being more specific, from this point forth I shall refer to what I am designing as a learning object; a self-contained learning exercise, which in this case is delivered online from a designated server space or Learning Object repository. This Learning Object will be a basic web application with a “choose your own adventure” type learning exercise based on the creation and format of study materials with some interactive gamification elements thrown in. A lot more thinking and development will be required before we can get to that point.

About my hypothetical client

My imagined client for this project is a UK university (enrollment = 20K+) and the intended audience for the Learning Object are their academic staff. The university would like the Learning Object to be openly accessible as it is a mode of publicity (shared via social networks with university branding) and it shows that the university are forward thinking and considering staff professional development and digital capabilities. As the link to the resource will be openly accessible and find-able via search engines, this means that potential users could be anyone with an interest in the accessible presentation of resources, for example: primary school teachers, lecturers, student support tutors, learning technologists, students in teaching training, etc. Potential users could also be anyone who works with a Virtual Learning Environment (VLE) or a Learning Management System (LMS) and there are many flavours VLE/LMS on the market. Furthermore users may also come from anywhere in the world, which means that if I wanted to serve all potential users the Learning Object (LO) would need to be available in multiple languages. The unique paradigm presented by OERs is explained very nicely via metaphor from Jisc - interestingly Jisc also use the consumer and creator definitions, although I came up my definitions independently and found their page after the fact.

Farm production as a methaphor for OERs from the producer, e.g., cow, to the owner, to the repository, to distribution. — OER Metaphor

Hold-up…this is getting really complicated

However that is not the model that I am going for in this case, the LO is not meant to be all things, to all people. It is for a very specific purpose and that is to help academic staff at a university in the UK gain awareness of different strategies for making learning materials accessible as a response to the forthcoming changes to Disabilities Living Allowance. These changes, planned by the current government will take effect halfway through 2016 and may affect the support provisions available to some students in the UK. This LO serves a specific need, for a specific client so is to a certain extent propriatary, the way that we achieve the “open” aspect is make the URL accessible to external users outside the university; use metadata to support search engine optimisation; license the underlying code with a GNU General Public License 3; and make the source code available via a repository like gna.org which is hosted in France and supports git version control (to comply with EU safe harbour ruling).

On the topic of technical construction…

Upon consideration of how the Learning Object will be created, I think that it will be a custom coded html5 site with MySQL backing (this is subject to change). A facet of the brief is that data needs to be entered by the user in some way, web applications like Xerte which allow for the fast creation of html5 Learning Objects are not suitable as the resulting LOs seem to be read-only. So although these LOs can be interactive, no data that is entered is actually collected thus the need for a custom solution rather than using an established LO creator application. As the plan is to make the source code publicly reusable this will need to be considered during the construction process, to ensure that there is sufficient documentation to guide those who may wish to reuse the code. In this model there are two key user groups:

those users from the university who interact with the LO;
those users from outside the university who interact with the LO.

We also need to consider:

those external users who consume first and then move on to create; as in copy and adapt the LO using the source code.

These user-creators fall outside the scope of the design for interaction, but should be considered throughout the design and coding stages to ensure that documentation for the code is sufficient and the design allows for future customisation. For example clear image tags and labeling need to be in place to allow any screenshots taken from Moodle or a different VLE to be substituted for the original screenshots taken from Blackboard (see paragraph below).

As I mentioned before there are many different VLEs out there, however as we are talking about the UK (and anyone else is welcome to go to town with the content) then the two most prevalent VLEs in the UK are Blackboard and Moodle (UCISA, 2014, p.10). As a consequence, those users who consume will fall into two camps - those with an interest in Blackboard and those with an interest in Moodle; the principles presented in the Learning Object will be the same for each system but the visual aesthetics differ between the two. My client is a university that uses Blackboard, so the LO will be blackboard focused but we hope that someone will create Moodle and other versions in the future based on our source code.

Friday, 6th of November 2015 - Update:

I have changed my thinking on the LO, as VLEs are updated fairly often this would limit the shelf-life of the LO. It was also proving to be too complex. So I have decided to focus on the idea that I am building one LO, of a hypothetical many, and the LOs are all about the different kind of materials going into the VLE. The LO I am designing will be about creating accessible documents in Microsoft Word. For more on this, see this later post.

General Characteristics
Characteristic	Detail	Design Implications	Practical Design Ideas to keep for later
Direct	Users from the university: academic staff	The design needs to be approachable with goals for the LO clearly outlined. It is quite important that users do not need to login in order to use the LO. A sort of login fatigue is a major issue and some university users may wish to remain anonymous.	It would be helpful to track how many academic staff complete the LO, so a potential method for this would be allow the production of a completion certificate at the end of the LO, this will only be generated after the user logs in (using an existing university LDAP easy proxy). Users will have the option to skip the certificate, if they wish to remain anonymous. External users and anon users will still be able to generate a basic completion certificate, but it won't have full university validation (or something along those lines).
	Users from the university: students, admin staff, researchers etc.	Although the intended audience are the academic staff at the university and the LO will be clearly labelled as such, other types of university users will not be prevented from accessing the LO.	At the beginning of the LO the users will be asked to type in their role which will auto-populate an entry cell based on a predefined set of options. E.g. What is your role? I am... offer a drop-down list (e.g. a student; a researcher, an administrator etc.) and autocomplete, if "other" is selected then they will be asked to specify. In order to gain some basic usage stats, users will be asked to self-identify whether they work/study at the client university (to differentiate between internal and external users). This data will not be completely accurate as people may forget to self-identify or an external user may incorrectly identify, however it will give an indication of use.
	Users external to the university	External users will have access to the LO. These users could come from anywhere in the world and English may not be their first language.	As login is not required to use the LO, any entry fields must be validated to ensure that malicious code cannot be entered in the LO. The option for a basic certificate, where the external users enter their preferred name and a PDF is generated for download needs to be available. Write the LO in plain English, this will help all users. Where specific technical terms are used, provide a glossary and/or rollover definitions as technical terms differ per country.
Indirect	These are users who access the derivative versions of the LO.	The experience of these users is, to a certain extent beyond our control. However the development documentation should recommend best practices for accessibility.
Remote	Technologist/s responsible for monitoring the use of the LO needs a way to download usage data. These users are also support users.	Require access to a basic online dashboard showing how many academic staff per department/school have completed the LO. Counts of other users should also be included in the dashboard and an option to download the data as a .csv.	It would be ideal for this data to be displayed as a leader board; a graph showing the top school through to the bottom school. However this is really out-of-scope, as that is a separate application. It would be nice to show users school stats after they have logged in for their certificate. E.g. you are 1 of 48 people in Computing who have completed the LO. Computing is now the 2nd most engaged school. However if robust .csv export features are added visualisations could be produced periodically in Excel and other programs and the leader board could be added at a later stage. Any more complex anonymous data about visitors to the LO should be reviewed through Google Analytics.
Collateral	Those accessing derivative versions of the LO via third-party repositories.	The LO may loose some value in its iterations and therefore when it is placed in repositories by third-parties, the owners of these repositories may not want it to be there. The client university's branding graphics will not be included with the source code, as it needs to be clear that derivatives are not still owned/maintained by the university.
Prohibited	Someone who wishes to inject malicious code into the LO in order to target users.	Validate all data entered into the LO according to set parameters; disallow html tags and certain words/characters. There is little that the university can do to prevent this in the derivative versions of the LO, but a disclaimer should be included in the source code stating that the LO should only be used when delivered/served by reputable providers.
Support	Technologist/s (employee/s of the university) who support and maintain the system. These folks are also direct users and	This knowledge and level of access will also be shared with employees of the university. They require documentation/training prior to providing access. As the original creator, of the LO we/I will have a level of involvement in it's continued maintenance, updating the code for an agreed time period.	Supply limited support to external users through the gna.org repository.
Number of Users	Intended users from university: academic staff	1,300 estimate of academic staff across the lifespan of the LO. The lifespan is estimated at academic years 2016-18 (24 months).	Need to identify how many academic staff would be expected for each school at the client university.
	Additional users from university: other staff and students	300+ across the lifespan.	Of limited interest to these users, so we expect only those users who have a specific interest. It is likely that, for example, an inquisitive student who ran across the LO will not complete it, as it is not aimed at their needs.
	External users	720+ - around 30 users per month across the lifespan of the LO (14 months).	Hard to tell how many external users will access the site

References

UCISA. (2014). Survey of Technology Enhanced Learning for higher education in the UK. Retrieved from the UCISA website.

Some more examples of learning objects, made with articulate (software). Articulate does allow templates to made and re-used, but it is proprietary software so not ideal for the open nature of this project.