Sussex University is a research-led Higher Education institution using a customised Moodle install called Study Direct. We have 1,500 editing tutors, 15,000 students, 2,099 2012/13 Moodle courses  and 13,500 unique hits per day.

The e-learning team is a team of five including two developers, one front line support officer, one teaching support officer and one manager. We don’t have any departmental learning technologists like many institutions.

What does that mean?

One, we cannot train all our tutors to make beautiful sites

Two, before we made changes to our interface, many of our hard working, conscientious tutors made Moodle courses which were long lists of links (#listofdeath, c.f. #scrollofdeath). The courses our tutors created gave our students a poor experience and left tutors, who had tried their best, unsatisfied and demotivated.

What if our tutors made BBC web pages?

Would BBC pages stop looking like this?

And start looking like this?

We decided we couldn’t rely on training to ensure that our tutors would create rich learning resources for our students. We needed something cleverer.

Implicit and explicit calls to action

We started to look at other content creation tools.

People using word processor applications would struggle to create a learning resource that looked like a Moodle course.

People using spreadsheet applications would struggle to create anything that wasn’t a spreadsheet.

Presentation software has explicit calls to action such as “Click to add a title” which help people create understandable presentations.

Blog editors have explicit and implicit calls to action such as title input boxes and text editors which make it obvious how to create understandable web pages with text and images.

We concluded that an interface has the power to explicitly influence the shape, design and type of content the user creates.

Moodle calls to action

So what does the Moodle interface look like and what are the calls to action on the busy academic tutor when he or she come to build a Moodle course?

Well, if they work out to “Turn editing on” this is what they get:

Hey! The primary call to action is to add a resource or activity. Yes, they could choose to add a label but what is a label anyway? Or they could add a summary to their section but how do you do that? Can you guess?

Should we be surprised that our tutors created lists of resources and activities without context?

Adding calls to action to Moodle

What would happen then if we added the calls to action that helped our tutors to create engaging learning courses. What might that look like?

Well, this is what our Moodle install looks like:

What are the primary calls to action on this page? If I were a tutor what would I do first to create a learning course for my students?

I see that there is an implicit call to add a section title and section content. I think I’d start with that. What about you?

And guess what. When I am adding the title and content I am adding contextual online learning material and not simply adding to the “list of death”. Nice start!

What then?

The bright green colours give me a clear steer.

It is asking me to add a site image. That sounds nice. I can add a visual representation of my course much like the cover of a book.

I can also see how I can add another section.

The “add activities” and “add resources” are large green calls to action at the bottom. They boldly indicate how I can add interactive content and detailed materials that I would like my students to drill down into.

Ah and then there is a dashboard. That is where I do the administrative gubbins for my course.

So what has this meant for our users?

We have found that, in many cases, these prominent calls to action have changed the habits of our tutors. The courses they create are more similar to the first image of the BBC than the second – more similar to content people are used to seeing on the internet.

We are seeing an increasing number of tutors create engaging online learning sites with content and context.

We think our changes have substantially improved the tutors’ workflow and our students’ online learning experience.

We have made other changes, briefly covered in our presentation, such as ‘pages’ opening in an ‘accordion style’ so this content always has context, but I’ll leave these for another post.

Future

We know we haven’t got it right yet and we have a long way to go, but we have great ideas.

For example, should the resources and activities go directly into the web editor?

We are not sure, but if they should it might work like this:

Or even like this:

Despite having loads of good ideas we are faced with the same dilemma as all developers using Moodle – whether to improve the tutors’ and students’ experience of our VLE/LMS or stick with the Moodle core. We are walking a tight line, but we want Moodle to become something like our Moodle install – in fact something better.

We know if Moodle is to continue to be successful it will do this – it is just a question of time.

As a small development team we can’t contribute much code ourselves, but these blog posts hope to generate ideas and help steer its direction.

Finally, I’d like to extend a big thank you to the organisers of MoodleMoot Dublin #mootie13.

A lot was covered in the discussions, but I’m just going to pick out the areas that were particularly relevant for us.

Support issues – challenges and how they will be addressed

Tom Rees (Product Specialist Lead in Newcastle) talked about the challenges that the support team had faced over the last year, caused by unpredicted high growth in the user base. Support hours based in the UK were being extended to 7.00 to 17.30 Mon-Fri with some weekend cover too. A nasty reminder that using Turnitin can involve support issues outside of the control of your own institution, and that this needs to be factored in to any policy.

There was also a detailed conversation about how Turnitin should communicate information about specific problems. The general approach is to offer a number of channels so that institutions can pick what suits them.

https://twitter.com/TurnitinStatus (option to enable mobile alerts)

Strategy, implementation and training resources

Strategy, policy and procedures

Helpful resources available at http://www.plagiarismadvice.org/

• 10 key resources for an institution developing its academic integrity / plagiarism policy – looks like some very useful stuff, extremely relevant for Sussex at the moment
• research papers
• blog – plagiarism in the news

Using Grademark

Grademark online tutorial: http://www.turnitin.com/demo/dv

The tutorial is set within the Turnitin document viewer and invites the trainee to carry out a series of tasks that enable them to use Grademark features in a real marking exercise. For Sussex, where we are keen to give our lecturers and senior managers a flavour of using Grademark, this could provide a very easy, low stakes way of doing it.

Marking schemas in Grademark

One of Grademark’s strengths is that it makes it relatively easy for marking schemas (Grademark calls them rubrics) to be shared with appropriate staff. For large class sizes  where a number of faculty and associate tutors will be marking work, the use of schemas can help with maintaining consistency. The US Common Core State Standards (CCSS) initiative has authored some rubrics for assessment of maths and writing skills at levels K9-12 (translation – secondary school age), and Turnitin has built these into Grademark for its US market. Some of these have been made available for UK institutions. They aren’t directly relevant, but they give a good idea of how to implement a coherent rubric.

ACTION: embed into Grademark on test platform for demo purposes.

Turnitin – new developments

Will Murray, VP of International at Turnitin, presented the product development news.

Keeping up to date with information about product

https://twitter.com/TurnitinProduct/

Quarterly product talks from Tabitha Edwards (Product Manager):http://pages.turnitin.com/talk.html

(next session at time of writing is 19th March 2013)

Document viewer memory leaks – March 2013

Will confirmed that there had been some real issues with the document viewer in Turnitin (this is the screen that you use to view the Turnitin report or to mark within Grademark), including some memory leaks that had been particularly challenging.

Engineering update

Will acknowledged that the Turnitin platform had creaked at times, and had caused significant inconvenience to users with assessment deadlines.

Christopher Minson had been appointed as  VP for Engineering, with a remit to make considerable improvements to the QA process. “We are going to start testing software before releasing it.”

iPad app for Grademark – May 2013

This was probably the announcement that generated the most interest in the room, judging by the tweets at any rate.

The iPad app is due to be released in May 2013. The date at the meeting for it being publically available within the App Store was 3 May 2013, but the circulated notes from the meeting indicated that this had slipped, but not what the new target date was.

It uses “class based authentication” – in other words, the tutor needs to get a code for the assessment they wish to mark from their usual Turnitin grading screen. They then enter this code into the iPad app in order to download the student work and associated materials including marking schemas.

The iPad app will make it easy to see which student work has been marked and which has not.

From the iPad app, the tutor will be able to view the Originality report, and see which text in the student’s work matched sources within the TII database.

The app will allow tutors to add Grademark’s quickmarks – the pre-prepared marking comments. It also supports the use of marking schemas.

The great news is that this will provide an offline tool for marking using Grademark on an iPad.

Is this going to be our tutors’ preferred marking style?

Interestingly though, Will confirmed that there were no current plans to produce an offline version of Grademark for laptops / desktops.

There is also no current plan to release an Android app.

Document viewer version 2 – Q3 2013

This project is due to run for the next 6 months, based in Newcastle. The aim is the rewrite the document viewer so that it uses the HTML5 Canvas element, and to improve the speed and fluidity of the viewer.

Support for multiple markers in Grademark – Q4 2013

This sounds like a useful feature that brings in the idea of review layers. Review layers enable multiple markers to work independently. The initial release will not implement privacy, so all markers will be able to view all layers, but further releases will enable this.

Changes to marking will be tracked, and an audit tool provided.

Admin tools – Q4 2013

As we move to supporting more complex setups in Turnitin than we do at present, the new admin tools are likely to be extremely useful. The tools are basic admin tools that really should have been there all along. When we are using Turnitin more widely across the institution, we will need to factor in the costs of additional support for staff and students. We will need Turnitin admins who can bridge the gap from moodle into Turnitin and be able to confidently manage Turnitin assessments within the Turnitin interface when necessary. These tools should help with that.

• it is easy to use
• it is reliable
• it is fast
• it only imports questions used in the quiz while maintaining question category structures that are used
• it shares many similarities with our custom rollover tool
• clicks to import materials is a minimum of 3 compared to the standard moodle which has a minimum of 6
• it imports embedded files without bringing all files (unlike Moodle 1.9 import)

Click here to view the embedded video.

Technical stuff

Anyone with experience of Moodle’s import, backup and restore features will know that reliability is an ongoing problem. If you are in any doubt try following the backup and restore discussions.

Further to this it is still a bit clunky to use. For example, it takes too many clicks, it brings all questions in quizzes whether they are used or not in the quiz you are importing (see bug tracker issue) and, in our version, it does not bring embedded files or images.

Our import does not rely on the backup and restore functionality. This means it does not create a temporary zip of an xml representation of the course and associated files which is useful when transferring courses between Moodle installs and keeping course-based backup, but inefficient when importing materials between courses within a Moodle install. Instead it copies records within tables and data files. As  a result our import is fast and reliable where, in our experience, the standard Moodle import hasn’t been.

Please feel free to ask any questions!

I am relatively new to user experience. My colleague, Stuart, is a keen advocate and a lot of what he says makes undeniable sense. I have therefore started to dip my toe into this new world. I began by reading The Elements of User Experience by Jesse James Garrett. His name made him sound like a cowboy. Not a cowboy as in someone who does building work badly, but a cowboy as in Henry Fonda and this was good enough for me. The book was a good read and gave practical advice for staging and managing the design and implementation of a product; any product but particularly a web site. It included easily accessible process management principles which resonated with my Master’s in software management I completed years ago.

Last November I had my second toe dipping into UX when I attended the Brighton UX conference, and it was an absolute hit with me. It confirmed what I thought. UX covers a lot of the bases of successful software design, implementation and management and is easily accessible.

The first talk, “The web that wasn’t” was given by Alex Wright. This talk gave an overview of Alex’s thought on some technological ideas that got left behind. He premised the conference with three philosophical ideas.

• First, that a software developer engages with problems which require them to make novel decisions to reach novel solutions. Arguably from a subjectivist epistemology our decisions are always novel but perhaps those made by software developers can be more earth shattering
• A second, that history does not plot a trajectory of human progress, it simply plots time when things happened and those things things often affect other things
• And a third, that our society is based on planned obsolescence. As human logic dictates when you shoot you shouldn’t shoot yourself in the foot, so capitalist logic dictates that when you build something to sell you shouldn’t build it to last

Click here to view the embedded video.

Ben Bashford gave a talk on future shock. He argued that technology was moving so fast that it is scary to many of us. And that as designers of new technologies we need to make our systems less scary by giving them human traits. Ben proposed we design technology with the traits which we would like our users to think of it, giving it emotion and character.

Click here to view the embedded video.

Karl Fast talked about models of learning. He argued in favour of theories of learning that describe the importance of tools and environment to our learning, such as embodied cognition, distributed cognition and activity theory (a personal favourite I am using in my doctorate in Education).

He gave a number of examples to make his point:

• Its easier to make words in scrabble when we move the letters around to make words
• Its easier to do a jigsaw puzzle than to think about it
• Experienced and capable Tetris players over rotate the pieces more than those inexperienced and poor at it. Over-rotation is a pragmatic and epistemic action that is faster, simpler and less prone to error
• Brainstorming is easier when using sticky notes than retaining the information in our heads
• When we talk we use our hands. Our hands help express things. This is independent of the person we are talking to. We do it on the phone, we do it when talking with the blind and even blind people do it. The hands are a tool which help us think

He made the point that a phone on its own is useless but a phone in someone’s hand is powerful. Turn this on its head and a person with a phone is more powerful than one without.

We wouldn’t get rid of iPhone, iPad, Facebook or youtube – its the infrastructure for much of our knowledge; information is cheap – understanding is expensive.

Click here to view the embedded video.

Other talks included Mark Bachler, games designer, who discussed issues that came up when designing natural user interfaces such as the Kinect interface and Guy Smith-Ferrier gave a very amusing talk on neuro headsets which could literally read your brain waves.

Click here to view the embedded video.

Click here to view the embedded video.

Interface design for rich, beautiful and engaging Moodle courses

Most of our Moodle courses used to look to like messy file repositories. The students’ experience of using them was usually functional, but rarely pleasurable. The courses largely consisted of files for the students to download and open in non-web based, proprietary applications such as MS Word or PowerPoint.

We relatively quickly realised our tutors weren’t doing this by chance. Our tutors are not web designers. They do what the technology they are using encourages them to do. In the case of our Moodle this was to upload resources one after the other with the minimum of context. This usually resulted in the students’ learning sites looking like their tutors’ file directories.

In order to counter this we made a concerted effort to encourage tutors to create rich, beautiful and engaging learning resources for their students. We did not do this by coercion or strict training programmes. We made focused modifications to the Moodle editing interface which changed the tutors’ workflow and enticed them to add inline text, images and videos. This improved the look and feel of the sites and made them easier to use by their students.

This, combined with a focused communications strategy, has made a considerable difference to the learning sites our students are using today. To find out more come to our presentation!!

The Sussex import grew out of a proof concept project that wanted to establish that we could import materials between courses without using the expensive backup functionality. It only became a project when we realised it wasn’t only possible it was immanently sensible. As a result we needed to build in our testing framework after we had written the import feature.

We wanted the testing framework to expose changes to the database contents so we were confident the feature wasn’t compromising data integrity. This would compliment our usual testing.

We looked into the inbuilt Moodle unit tests, which in our 1.9 version of Moodle was based on SimpleTest. We thought that the implementation of SimpleTest in Moodle was potentially powerful because it could run multiple tests before a project went live which establish that the changes haven’t broken the functions being tested.

However, we ultimately decided that SimpleTest was unsuitable in this case because the import creates entities in the database. Running this for each Moodle module every time we wanted to run a unit test would be too labour intensive.

Instead we decided to write our own unit tests (loosely described) which logged the results of the tests in the browser console.

The tests would collect data before and after the import and then compare the data returned. The comparison would give the tested pass and fail results.

The comparison looked at a number of data components including:

Course module count

The course module count established that the course modules in the source course stayed the same and the course modules in the target course incremented by one for each asset imported.

Section count

The section count established that the sections in the source course stayed the same and, if the section of the imported asset existed in the target course, the sections in the target course also stayed the same. And, if the section of the imported asset didn’t exist in the target course, the sections in the target course incremented by one.

Assets count

The assets (module) count established that the assets in the source course stayed the same and the assets in the target course incremented by one for each asset imported.

Asset specifics

The asset specifics tested that modules had been correctly copied. The most complicated module was the quiz. The test established that the source course quiz, quiz questions, question answers and question categories all stayed the same and that a new target course quiz is created, with identical quiz questions and answers put into a new category associated with the course.

An example of how the test data helped

The comparison data would return like this in the browser console:

In the case above it can be seen that there is a problem in the target sections. The details were also stored in the console log so that the programmer could look into the details and see what actually happened.

The details showed that the import did not increment the number of assets added to the section.

The unit tests proved a useful addition to the project allowing us to feel more secure in the fact that the import was not compromising data integrity.

We hope this blog detailing our approach will be useful to others.

As always, your comments welcome!

In order for students to have great learning experiences, we believe that students, and the people who teach and support them, need to have great user experiences.

That’s been at the heart of the work that we’ve been doing since 2010.

John and I are in Manchester at ALT-C 2012, where we’ve presented a paper exploring this issue.

Better user experience, better learning experience? ALT-C 2012 paper

These videos – and Graham’s subsequent report – were very helpful to us in deciding on the priorities and approaches to adopt in taking forward the work that we’ve done with Moodle since then.

We can’t post the videos because we didn’t request appropriate permissions from the interviewees, but here is a totally anonymous transcript of a short section of one of the interviews.

This is a screen shot of the Moodle site from 2010 they are looking at:

Interviewer: Imagine if we suddenly decide that it would be much better if it was in 10 sections? How would you go about changing it to 10 sections?

[4 second pause]

Interviewer: If I can ask you,  just to talk out loud about the things you’re looking for or what you would expect.

Staff member:  [replies straight away] Well, we need something to add onto here [with her mouse she is indicating the final section in the 5 sections visible on the screen - marked with a green star on the screenshot] …. but i’m not quite sure how you’d do that [2 second pause]

[starts to look at other parts of the screen – goes to the Site menu – the top left hand block]

Site menu [reads and runs mouse along the link] “Topic 1” [moves mouse across the Section 0 which is parallel to where it says topic 1]

Is that Topic 1? [shakes head][6 second pause in which she shakes head, looks around the page, ]

I really don’t know[now sliding mouse into the sussex library resources block]

[starts reading the list within this block] “Reading lists” [confidently, this is something she recognizes, then tailing off again]

No  [shakes head, looks to bottom of screen and says quietly] I don’t know let’s just go down

[Scrolls a bit further down the page, sighs, sits back in chair in a gesture of defeat] Sorry.

Interviewer: What would you like to  see?

Staff member:  [much more quickly and confidently] Um a drop down menu. [Moves mouse to the Site menu]

Or – [interrupts herself, sounds less confident, moves mouse to Site menu] This is a site menu ..

Interviewer: Mm [neutral tone]

Staff member:  [sigh] [pause][sits back in chair] I just think it’s completely .. [turns to where the interviewer is sitting] confusing

We found that the Moodle import is based on the Moodle backup feature. Moodle backups create external representations of courses as a zip. It’s great at keeping packaged archives of Moodle courses, and sharing them. However, incorporating backup into the import process meant packaging mods into temporary zip archives and then unpackaging them again, even though all it really needs to do is copy a mod and associated files.

We found that relying on Moodle’s backup wasn’t the most efficient method.   Our new import isn’t based on the Moodle backup functionality and as a result is faster, more robust and easier to use. Unlike the standard Moodle import tool it is also able to copy files linked from html within mods.

In this first of a trilogy of posts we’ll sketch out the database schema we are copying.

Database schema for generic course modules

The generic database schema for course mods looks like this:

Some of the Moodle mods have no further data associated with them than this. Others only have user generated data which the import doesn’t need to copy.

In our Moodle install mods with no further data associated with them include resources, assignments, chat modules, journals, forums, wikis and labels.

Some of the Moodle mods have subtables associated.

For example the choice mods have an associated table with choice options, the database mods have an associated table with database fields, and the feedback mods have an associated table with feedback items.

The lesson mods have an associated table with lesson pages and these pages have an associated table with lesson answers.

Database schema for glossary modules

The glossary was the only mod where we decided it was important to import user data as these included glossary definitions added by the tutors and a glossary without definitions wouldn’t be worth importing. As a result the database schema was a little more complicated. Glossary mods have associated tables with glossary entries and categories and there is a linking table between entries and categories. Furthermore, entries have an associated table with aliases.

Database schema for quiz modules

By far the most complicated mod was the quiz. The quiz has associated tables quiz feedback and quiz question instances. Quiz question instances joins questions from a Moodle question bank. The questions are in categories which are associated with the quiz itself through the context table.

There are number of questions types all using their own database schema. Most of the question types use the question answers table.

There are a number of question types which randomly pick questions. The random short answer matching (slickly named!) picks any short answer question in the category that is not currently in use to make a matching question by pairing the question and answers of the short answer questions.  The random question will pick any question currently not in use in the quiz that is in the same category or a subcategory.

We hope this approach will be useful to others who have problems with import in moodle.

In the next posts we will talk about the unit testing we did to establish that import was working and finally the Sussex import feature in its working form.

As always, comments very welcome.

• Clean separation of content and decorative elements
• Icons scalable for different devices
• Optimisation of icons and markup for page loading times
• Easy to skin/theme

The moodle roadmap currently contains an issue – Completely new default icon set and graphic design – and that is a rather wonderful thing but i will miss the ye olde moodle icons…..

Moodle icons today

Let’s take a look at the current state of moodle icons. I think we all find standard icons in moodle are rather characterful, and somehow our hearts have grown rather fond of them.

They have a fantastic naive charm but unfortunately to the rest of the world something about them instantly makes moodle look cluttered and dated, no matter how modern the theme you apply is.

The same is also unfortunately true for the markup displaying the icons.

<li class="activity forum modtype_forum" id="module-1772">
<div class="mod-indent">
<a href="#">
<img src="http://demo.moodle.net/theme/image.php?theme=nimble&amp;image=icon&amp;rev=500&amp;component=forum" class="activityicon" alt="Forum">
<span class="instancename">News forum</span>
</a>
</li>

It’s a lot of code, for something relatively trivial. In my screen reader this read out “Forum (from img alt tag)  - News forum (from link text)” .

Editing icons are based on the same model :

<a class="editing_moveright" title="Move right" href="#"><img class="iconsmall" alt="Move right" title="Move right" src="http://demo.moodle.net/theme/image.php?theme=nimble&amp;image=t%2Fright&amp;rev=500"></a>


which was read by my screen reader as “Move right (the a title) – Move right (the img alt) – Move right (the img title)” . I can see what the developer is doing here – using alt tags and title tags for accessibility, but unfortunately not achieving what they want.  Other screen readers might read the title, alt or even nothing. Because there is no actual text in the a link, some screen readers will actually read the link as ‘ ‘ or announce the url address. It’s a well intentioned model that we can examine improving.

Icons on the rest of the web

Let’s think about most web icons. They are mostly what is can be described as ’decorative’. Web standards for accessibility tell us these decorative elements shouldn’t be causing clutter to any users.

Decorative icons don’t need title or alt attributes, the content should always be the text in the actual dom node. Applying this to our code gives us :

<a title="move right" href="#"><img src="http://demo.moodle.net/theme/image.php?theme=nimble&amp;image=t%2Fright&amp;rev=500">Move right</a>


That’s a bit clearer, but we can take it a step further :

<a title='Move right' class='move_right' href="#">Move right</a>

You’ll recognise this approach as those first magic steps to the separation of content and display. There are no erroneous title and alt tags, the simple a href content does most of the work for us as Tim Berners-Lee intended. We are now free to use css to add decorative styles.

.move_right {
text-indent: -3000px;
display:inline-block;
padding-left:16px;
background: transparent url({path to icon}) 0 center no-repeat;
}


One line of css gives us the same as an img tag and src for every move icon on a page. It is a dramatic step towards optimising any site’s performance, while keeping code clean, improving accessibility, maintainability  and  giving us that all important separation of  content from display.

Edit icons as css background-image demo

For activities we can use the same approach:

<li class="activity forum modtype_forum" id="module-1772">
<a href="#">
News forum
</a>
</li>

Activity icons as css background-image demo

Another advantage is that this separation makes it a lot easier for developers to make fantastic themes for a cms.

Fun with html entities as icons

You can also use html entities as decorators to save on http requests and image load time.

Edit html entity as image demo

Our approach at Sussex

There have been a lot of people asking about our EDITING ACTIVITIES, LABELS & RESOURCE blog post, so here’s  basic walk though.

Without changing the core code changing the icons in moodle is currently an interesting challenge. It involves going through folders in your theme and physically replacing icons while keeping to the naming conventions, icon size, icon mime types and folder structure specific to moodle’s guidelines. For us it proved an insurmountable barrier to integration with other systems where we wanted consistent icons cross cms, or dynamic icons for javascript interactions.

At Sussex we wanted to alter our moodle icons by using a web standards approach based on this separation of content from display, optimisation, accessibility in mind and mobile and cross device adaptability – we are still not there yet, but we plan to be soon. We did, unfortunately,  have to implement the changes to core code outlined above to move towards this.

Semantics

First we suppressed all the icons spat out by php in moodle. Second we devised a semantic structure for classes. For resources and activities it follows this pattern :

class="asset {resource or activity} {type} {mime_type}"

This allows you to use css to add icons based on the mime type of a file resource, the resource and/or activity type. It makes the asset itself self describing, the sort of thing that gives a web developer a little glint in their eye when they view source on a webpage (as compared to the sinking feeling of despair you normally get). We could than apply a our png icon set via css, and some sprite icons where appropriate.

Other icon formats

In other parts, such as the drop down arrows above, we used a combination of html entities and svg icons from the noun project. Path dependency was no longer an issue and we are able to use icons internal and external to moodle, in whatever format was most suitable.

For activities we chose a different approach of using text based ‘faux icons’.

It still relies on the semantic self describing markup, but instead of images we use css to create text ‘faux icons’, such as the Quiz and Forum above, with unique text and background colours.

Activity text ‘faux icons’ css demo

Icons on the web today

The landscape for how you create and use icons has really changed. The principles of keeping content and styling separate are still the golden rule, alongside semantic mark up, accessibility and optimisation of page load speeds – some of our four requirements.

The ability of users to view your content on devices with different pixel densities has opened up a requirement for scalable icons such as svg and font icon sets.

Twitter bootstrap font based icon set

Zurb foundation font based icon set

Next time we re-visit our icons at Sussex we will almost certainly be using a font based icon set. Frameworks such as  Twitter bootstrap and Zurb foundation are already providing beautiful font based scalable icons which can be styled with css – as you would any font.

So what can we takeaway for moodle from this blog post?

It would be great to see moodle moving towards the future in its choice of icon format. Perhaps even more importantly to developers is to see moodle move towards web standards of accessibility, semantic markup and separation of content from display.

Be interesting to see what happens and if you feel strongly about this, as always, please contribute to the future of moodle on the forums and tracker.

Section titles are important for a user to get a good experience of a Moodle site. They are used in the contents menu of the site thus making them primary navigation tools. They are like the chapter names in a textbook. They are essential for giving an overview of the site and for finding content within it. This observation was evident from focus groups we carried out earlier this year.

Section titles are particularly important for us at Sussex because we would like all sections to be a page of their own and thus remove the scroll-of-death problem inherent in Moodle. But in order to do this, whilst ensuring our Moodle is still highly usable in all sites, we need 100% section titles.

However some sites at Sussex still have no section titles at all. The lack of section titles has largely resulted from tutors copying old sites which did not have section titles.

In order to get to a position where all sites use sections as self-contained pages we have altered our interface design to encourage tutors to input a title for their sections.

We have made it particularly obvious to tutors that they have a section which needs a title by re-naming the section “Untitled section“. “Untitled” is the term commonly used to alert users that they need to name something. For example, MS Word and Googledocs use “Untitled document” for unnamed documents.

We have coloured the text green. The colour is significant because we use green all over the site to signify an action is expected by a tutor. For example, all our action buttons are green.

Finally we have made the title mandatory when a user is creating a new section.

Students still see the name of the section as “section x”, where x is a number, so as not to further compound their experience of the site.

We have also made efforts to educate our staff about the importance of section titles. Training sessions emphasize the importance of meaningful section titles and we have a dedicated site for tutors offering practical tips which highlights section titles as an area for concern.

The edit clutter can roughly be described as the screen ‘noise’ provided by all the amount of icons on a moodle site when your editing content. Alongside the edit clutter we also tried to help with a common question our tutors ask – ‘What do all these icons mean?’

We tested a few prototype with our users, and after a number of iterations this is resulting design pattern of user interaction.

Click here to view the embedded video.

As always, comments and feedback are very welcome.

Two weeks have passed since the Ireland and UK Moodlemoot and a number of participants have written some excellent blog posts that summarise their experiences of the event. I thought I’d use this post to focus on one particular presentation – by my colleague Stuart Lamour. It may seem a little strange to be commenting on talk that I had heard in its draft stages several times before the conference, but I have been thinking about it quite a lot over the past fortnight.

Stuart was presenting an overview of the changes we have made to our Moodle installation (branded as Study Direct) at the University of Sussex. These changes have focused on improving the user experience of Moodle, from both the staff and student perspective and are documented elsewhere in our team blog. Stuart’s presentation focused on techniques that the development team have deployed to identify issues with, and provide improvements to, Moodle’s usability.

Feedback on the presentation was extremely positive and Stuart’s talk was mentioned  as a conference highlight in a number of blog posts and tweets. Having thought about his presentation, I think there are three main reasons why the talk was received so warmly.

First, I think it gave an insight into what it was possible to do with the Moodle architecture and interface to provide a more intuitive, simplified and aesthetically pleasing user experience. In addition, by using Study Direct as the tool with which to give his presentation, Stuart managed to give the audience a real feel for how it worked.

Second, the presentation wasn’t simply a ‘this is what we did’ talk. It concluded with a call for us, as the Moodle community, to use the available forums to persuade Moodle HQ to give higher priority to usability issues.

Of course, this call to action can only work if people feel that action needs to be taken and this is the third, and most important reason, for the talk’s success. It became clear that there was a real appetite in the room to discuss Moodle usability and the user experience and to try and push it up the agenda within Moodle HQ. One of the suggestions given by those at Moodle HQ to raise the profile of usability was to post something to Moodle tracker – a site where users can post problems with Moodle and suggestions for improvement. Whilst there was lots of feedback via Twitter to suggest that people would now use Moodle tracker, others felt that Moodle needed to build UX principles into its core development – a blog post by James Clay and a post by Dominik Lukeš reflected these feelings.

In his Moodlemoot keynote, Martin Dougiamas did state that usability was one of the priorities on the Moodle development roadmap. Moodle HQ is seeking to address some of the system’s usability problems in future releases – Martin  has recently posted a proposal for paged course formats that will try to minimise the ’scroll of death’ that users encounter when they encounter sites with a large number of topics. It will be interesting to see how they develop their user testing processes and how (and, equally importantly, when) they involve the community in this process.

The reason why I wanted to write this post was because Stuart’s presentation was quite a rare beast – it clearly made an impact with the immediate audience at the conference, but may also have a more lasting legacy by encouraging us, as a user community, to give feedback to Moodle and to try and make the experience of using the system even better than it is already.

And I don’t think you can ask much more of a 15-minute presentation.

In order to make their lives easier we have introduced the concept of “favouriting”. When a user favourites a site it rises to the top of their site list. And when they unfavourite it it returns to the bottom of the list.

Apart from the improvements in efficiency they are likely to enjoy this interaction.

Click here to view the embedded video.

We obviously love it, and so did the judges at UCISA who gave it the award for best poster of the conference!

larger version

In 2009 my new colleague Stuart Lamour introduced me to a fundamental principle of form usability – tutors did not want more options, they wanted less! They did not want to be exposed to the complexity of what was possible, they just wanted a few simple options that would make their lives easier.

Throughout our Moodle we have forms with options that are rarely used. We are slowly going through these and making them simpler to use. In this blog post I illustrate how I have simplified the enrolments settings of the course settings form using user experience design patterns, intelligent defaults and progressive disclosure.

The first thing we did was to split up the course settings form and put the various sections on to different pages. These were all available through another Sussex development – the course administration dashboard.

Many enrolment options were not relevant to courses that were created and populated by the automated course feed. As a result the vast majority of courses only need four enrolment options – does it allow guest access, is it enrollable, and if so, do guests or enrolling users need a key and what role do enrolling users enter with.

Those courses which have been created manually and manage their enrolments in other ways need more enrolment options. These include: is it a meta course, is the enrolment period between a date range, is there an enrolment duration and, if so, are there enrolment expiration notifications.

Many of the options only make sense if another field is set in a certain way, for example if a course is a meta it cannot be enrollable. This means we can enable and disable fields according to other form settings, thus making the form even clearer.

The following video illustrates what we have done, but please note we use some different terms. For example we call Moodle enrolments “subscriptions” to disambiguate from University courses and enrolments to them and we avoid the term “meta course” as we think it will confuse our tutors. Instead we say “take subscriptions from other sites”.

Click here to view the embedded video.

Another reason we are excited by the integration is that Google docs provides friendly access to file types that are otherwise difficult or impossible to view on mobile and tablet devices. This is particularly important as access to our Moodle through mobiles and tablets increased five times since the same time last year and articles such as “Why mobile matters” lead us to believe that our Moodle will soon be accessed more by mobile and tablet devices than laptops or desktops.

On a development Moodle install we have integrated Google docs and Moodle. On this system a tutor can make files available through a download, Google docs itself for collaborative work or a Google docs viewer respecting the Moodle permissions.

Click here to view the embedded video.

There are issues about allowing our files to be accessed by Google docs as the files become subject to the standard Web 2 licensing models. We don’t know how our academics would respond to this. We are investigating other options too such as Crocodocs and Zoho viewer.

I welcome any comments or suggestions regarding the issues that this integration raises.

Security and technical details

The Google file viewer can respect the Moodle permissions. This is how we did it.

When the Google file viewer views a file  it does not have the user or session variables available and so the script which serves the file cannot require login.

To get around this we write a record storing the url and time of access is written to a database table at the time of selecting to view the file. When the Google file viewer attempts to view the file, the url and time (within a second) must match the record just written. If they match the file viewer can access the file and the record is deleted, otherwise access is denied.

We figured out the technical details with Moodle developer Mark Johnson at the 2012 Dev8D conference.

In the past we used a multilayered approach to help. We had the standard Moodle help methods, that explained how to do things but not how they would benefit their teaching, and the standard Sussex University FAQ system for providing help that we could tailor to our understanding of our users’ needs. The problem was that the user experience of help was fragmented – the Moodle help was too technical and the Sussex FAQs were on a different system.  We therefore decided to create a help page within our Moodle install that looks-up the IT Services FAQs.

When designing the look and navigation of our help pages we looked at other modern web applications including Facebook, Wordpress, GooglePlus and Dropbox.

We found help was consistently linked to on the right hand side of the top horizontal navigation tool bar, used search as a primary means of navigation and had a list of categories that the user could browse.

We liked sites that gave the user the ability to feedback the usefulness of the FAQ. We felt that made the help more personal and interactive.

And we liked sites where help included the name (and face!) of the user who last updated it, because there was a human to contact for more information about the subject.

And we liked sites which enabled the help to be printed easily.

Furthermore, we found that the logical categorisation of FAQs improved ease of navigation.

We found that the wording was important so that users could immediately identify if the FAQ would be of interest to them. Having rule sets for the creation of FAQs meant there was a consistency about the user experience.

When writing our FAQs we wished to reinforce Moodle terminologies, such as Sections, Blocks, Resources and Activities. Maintaining Moodle terminology was important so that users who looked for help outside our institution would not be confused. However, we added terms that the user used to the keywords so that our FAQs would be found in their searches.

Because we did not have evidence of the language used by our tutors we are tracking search terms used. This means that when we revisit the help pages we can start to rephrase the language so it is even more usable by our users. Furthermore tracking user searches will help us identify area which our FAQs do not cover.

We found that the search needed to use a meaningful algorithm. We wanted searches matching the question or keywords to be returned before searches that found the word in FAQ answers.

A cross platform vle?

With the increasing predominance of smart phones and tablets it is highly likely that any institution running some form of analytics will have seen the rise in their moodle site being accessed by Blackberry, IPhone & IPad and the ever increasing march of Android.

It’s predicted that by 2013 there will be more of what we call mobile devices accessing your website, than desktop.  As a browser based open source CMS moodle is perfect for being viewed in all these internet ready devices, but needs a bit of tweaking.

Moodle at its core wasn’t built to consider such devices. Pop-up windows, tables, iframes, the forms library, the lack of support for grid layouts, poor usability, an ancient WYSIWYG editor (moodle1.9) and many other odd things dwell in the core moodles framework, and indeed Moodle HQ have noted the fact that it “requires huge core changes to Moodle” to make moodle work in the current browser/mobile landscape.

For us as users and developers such changes would not only improve moodle for mobile users, but for all users. Almost all modern open source browser based CMSs are currently updating, or already have done, to support mobile users and current browsers. Those that don’t i fear will disappear.

So what is the current state of moodle for mobile users?

Moodle News pointed us in the direction of the moodle plans for mobile.

It turned out moodle have some wireframes and a plan for developing a plethra of platform specific apps.

The plan suggested hiring app developers, and using moodle2 web services to deliver content into these applications. Their are no details available on testing these wireframes with actual moodle users.

A moodle iphone app was released. Which causes some problems.

The implications are that anyone with a customised moodle would have to customise and release their own suit of native moodle apps. Individual institutional data you include in your moodle, which a standard moodle does not, would simply not be included in the moodle standard app.

At Sussex we do not currently support or maintain a native moodle app for our Windows, Mac OS or Linux machines. Patches to platform specific apps are something not currently included in our development cycles. We use moodle because its an open source browser based CMS – it crosses these boundaries to unite all our systems.

The app we use for moodle is the browser.

The app stores – one size fits all

Apps can be great – Apple are able to designing a native mobile interface for most of their systems, with fantastic results. But moodle isn’t Apple, Facebook or any of the other one size fits all service providers. As with any open source CMS we expect to able to customise our users experience of moodle, to fit there needs.

Developing the iphone app should not been seen as a waste of time. As with apple themselves the lessons learned from creating a lean user experience can be fed back in and become beneficial to moodle.

In moodle – one size does not fit all

The ecological diversity of moodles out there tells us people use moodle for very different things. People customise moodle. People want different workflows and focus from their moodle. Moodle has never been a one size fits all product which most native apps, by their nature, are. People have already developed their own moodle apps for their diverse requirements from moodle.

Other CMS systems like the Wordpress app allows editors to curate content (a standard workflow), but there is no official app to view the front end of every worpress site in this specific style for a very good reason. Drupal have never released a one size fits all suite of platform specific naive apps because they except their strength lies in the ability of their customers to mould the product to fit the business and user requirements – as moodle needs to.

From our own tests, with a variety of mobile devices, moodle is very close to working well on mobile and tablet already. Patching the issues in moodle isn’t something we can do alone – it needs a encouragement from the community. At Sussex we would prefer to see moodle’s energy put towards updating and developing the open source browser based CMS we love. We’d like moodle and the communities time and energy put towards supporting the future for all users, rather than any one size fits all platform specific native app development.

Best practice on the web

Moodle’s pursuit of apps sits rather uneasily with current web community best practices for mobile. Moodle is lucky enough to be a browser based CMS when there has never been a better time to be one!

The now famous A List Apart article showed us how to technically shape content for small screen.

Moodle2 happily incorporates parts of the community browser best practice code form html5boilerplate. So why not html5boilerplatemobile ?

CSS3 enables us to use media queries  and it would be great to have moodle featured on mediaqueri.es – the gallery which shows some of the best use of this pattern.

The open university has a pattern library/online style guides which utilise these media queries, and we are looking forward to seeing this implemented in their moodle.

The ‘recently acquired by adobe’ phonegap project lets us interface with mobile apis for upload etc..

And while your moodle may not currently be mobile/tablet/modern browser supportive, their are ways around it.

Anyone who read or saw the Jquery UI Mobile presentation by filament goup (highly recommended) will know of the projects objective as a browser based framework for mobiles and tablets.

John Stabinger ’s  moodle2 mobile based on Jquery Mobile theme gives you a moodle web app.

The future of moodle?

We would love it if moodle accepts and learns to embrace what it is – a browser based open source CMS – and what a great time it is to be one.

• Dunbar’s number (approx. 150) can be a good guide for cohort sizes in e-learning as well as soical media
• Boys like to ‘do stuff’ together to re-enforce social groups, girls like to ‘chat’ to re-enforce friendships – what implications does this have for the types of online activities you might provide for different cohorts?
• By 2013 the majority of your users will be accessing your content through a ‘mobile device’. Start planning for this today.
• Word docs, Powerpoint, pdfs – Does your ‘offline’ content work on mobile? (its a guessing game, but mostly no!)
• Users performing a single task may be doing so through many different interfaces (including face to face, the internet, a telephone conversation). A strong, cohesive IA which crosses all these channels gives a better user experience (Pervasive IA).
• We are all physical beings - People think about things, not ‘document groups’. A good UX leverages the semantics of a real world, not document types, as its structure.
• UX doesn’t start with wireframes, it start with understanding & often defining the domain model. Far too often these days – frequently in large organisations, unfortunately including the education sector – ux is mistaken for a nice css/javascript/html interface. User Experience design is not, and should never be seen as, fixing a domain through by a nice interaction design level.
• Your ‘homepage’ may no longer be the content entry point for most users. Search, deep linking etc all give visitors different entry points you need to anticipate. Put 70% of your effort into the content pages, not your ‘homepage’.
• There is a derogatory image of  older users. ‘Older users’ (in the UK > 50, EU > 45 ) technological needs are often very similar to other age groups.
• Behavioural cohorts are often better than personas – for all users.
• Users would often be happier to pay more for something simpler, with less features.
• A good UX project can be as/more powerful than a business consultant (electronicink)
• Our brains have become addicted to the constant random releases of dopamine we get through services such as facebook, text messages, twitter and other notifications. Our use of these can be comparable to adhd.
• There is no such thing as a good multi-tasker. It is a fallacy.  Each cognitive task has a cost, and the user becomes less and less effective.
• Users are can now take these additive interfaces into distracting environments.
• The ‘addictive’ designs we most admire are often the designs that are killing our users. There was a 20% drop in road accidents in the US during the recent period of Blackberry messaging downtime.
• Design strategies for coping with adhd/multi-tasking today -
  • Turn stuff off by default. People like adding stuff. People hate making the cognative choice to disable/turn stuff off.
  • Create focus on the important, and remove the distracting.
  • Increase users motivation by creating an ability to grow mindset instead of a fixed mindset (http://www.brainology.us/). Let users set their own goals or just do as much as they like.
  • Decrease pressure – only ask for as much information/detail as you really need.
  • Give focus when returning to a task (e.g. the kindle ipad app highlights the section your were previously reading on your kindle, and vice versa)
• It makes sense, and we could have a social responsibility, to design for distracting environments (Giles Colborne).
• People connect – watching a user testing session is much more powerful than reading about it.
• IA has changed – how the BBC learned to look Beyond the polar bear.
• The web has changed – how to be Future friendly.
• UX is changing -
  • context – where you use the web
  • outputs – display diversity
  • inputs – mouse/keyboard/remotes/freespace gestures!
  • connection – isp gives you loads, mobile restricts – offline web etc
  • ecosystems – content goes cross device  e.g. watching a video from your phone on plasma screen, reading a webpage with instapaper on a kindle etc..
  • Can the classic set of UX Design deliverables cope with the ‘wider’ web?

= lots of interesting and practical stuff.

I wholeheartedly enjoyed this years UX Brighton. Thanks to Danny & co for organising.

One of the reasons for this, suggested by our users, is that in comparison to most other web based content management systems moodle has no clear separation between the course editing settings and the front end.

Having this separation of a front end user interface & an editor facing interface is a well used pattern which makes it simpler for content editors to know where to perform a task. It makes your web pages a lot less cluttered. It also helps emphasise to editors what students can see, and cannot.

Front end vs editor patterns from popular cms

{click the image for larger view}

For most web based cms the differences between the front end most users see, and the editor interface are very clear. The workflow editors follow is clear. The front end ui remains uncluttered by admin links, and the dashboard user interface is clean and simple.

For our moodle at Sussex we will be launching a new development which tries to bring moodle more inline with these other cms by introducing an editor dashboard pattern.

A dashboard for moodle

Click here to view the embedded video.

We already have exciting plans on how to improve this moodle dashboard. Once you have a simpler editor pattern & information architecture you already know exactly where new features/content live – it makes extensions and new developments much clearer. I’m sure you can all think of some too!

The changes for our users are obvious, but introducing this separation also has some technical implications.

Technical advantages

From a technical perspective separating out these content editor parts of your cms from the non-editing user view you stand to make your system leaner and cleaner.

Web based cms generally have a standard look for the editor pages, while the non-editor view can have a custom theme/skin. Editor pages are, by their nature, heavier in load of javascript, css, php and database queries - while the non-editor view can often be extremely light with less db/php but could have js intensive or fancy ui interactions. The separation allows you to only load what is necessary (a particular js library,css, a db query) for the type of user – giving both admin and non-admin a better user experience.

By separating an editor pages writing a theme becomes much easier – you only do so for the non-editor pages. Writing a plugin becomes much simpler – the admin ui only has to work with one theme – the default cms editor theme.

The future of moodle?

This information architecture pattern of separating the editor/admin and users view can be seen all over the web, and we would very much like to see it as an information architecture pattern adopted by moodle at some point in the future. As always, your comments are very much welcome.

We were impressed when in UK 2011 Moodlemoot the University of Kent demonstrated the solution they had implemented. This was a simple tool to schedule a rollover from another course. Unfortunately they were not able to share this tool and so we have endeavoured to recreate it.

When a tutor comes to an empty 2011/2012 Moodle course site they are given the option to copy an existing site into it by scheduling a rollover. When the rollover is successfully completed the academic is informed via email. If there are problems with the process the e-learning team is informed so they can resolve the issue before the academic is aware of it.

Unlike the University of Kent we based the Sussex rollover tool on the existing Moodle backup and restore functionality. This means that it has not removed the unreliability of the process caused by PHP memory issues, but we should be able to hide some of the issues from the academics.

For a demonstration of the recent updates feature please view our video. Please note our Moodle install is called Study Direct and we call each Moodle course a “site”.

Click here to view the embedded video.

Currently to spot if any changes have occured to their moodle sites users have to rely on getting email updates or playing spot the difference for each site they have in moodle – often not a simple task.

There is already a solution to this used widely across the web called the updates pattern. The pattern tracks changes that occur which are relevant to the user, and displays them clearly to the user. The pattern is part of addictive design, encouraging users to interact with changes, and when applied to e-learning can lead to a virtuous circle where users are encouraged to engage.

As a result we have developed a recent update feed to which users can subscribe. The feed includes activities, resources and forum posts added to or updated on Moodle courses in the last month, and we consume this feed on the site itself to indicate updates to users, as they happen.

The first five recent updates is available to Moodle users in a drop-down menu available from all Moodle pages. The drop-down includes a link to all recent activity feed items in the last month and the feed itself so users can subscribe to it.

The design pattern used is the updates pattern, which should be familiar to most internet users who use services like youtube, twitter or facebook (as shown below).

So far user testing has proved the drop-down menu to be extremely popular with tutors wishing to disseminate their materials and students wishing to engage in their subjects.

As we are using a standard web pattern most users don’t need any instructions on how to use the updates, they already know.

For a demonstration of the recent updates feature please view our video. Please note our Moodle install is called Study Direct and we call each Moodle course a “site”.

Click here to view the embedded video.

In our Moodle install the native breadcrumb bar looks like this when viewing a forum:

There a number of things about the native breadcrumb that we do not like.

It does not include a link to the course section that the forum is on. It therefore doesn’t help me retrace my steps or tell me where I am in the course site.

The list of forums (sic) is a strange view of the course where I can see only the instances of forums on the site. If I were viewing another activity-type or resource-type I would have a link to a list of resources and activities of only that type. We feel this view of the site is unhelpful and that students should be seeing the activities and resources in the context that the tutor intended.

The short name of a Sussex Moodle site is concatenation of the course code and the year the course is running. As our Moodle courses are dynamically created we cannot generate a more friendly short name. We allow tutors to update the short name but they rarely do. Therefore the use of the short name in the breadcrumb bar only serves to display text which is nonsensical to the majority of students.

We have therefore made three significant customisations to the breadcrumb bar. One, we have added the course section. Two, we have removed the link to the lists of resources and activities of the same type. Three, we use the course full name. In our Moodle install the breadcrumb bar looks like this when viewing a forum:

The programmatic changes to do this were in the build_navigation function in /lib/weblib.php and in course/modedit.php. We have detailed them below.

In weblib.php at around line 3850 update:

'name' => format_string($COURSE->shortname),

to:

'name' => format_string($COURSE->fullname),

and at around line 3875 update:

$navlinks[] = array('name' => get_string('modulenameplural', $cm->modname),'link' => $CFG->wwwroot . '/mod/' . $cm->modname . '/index.php?id=' . $cm->course,'type' => 'activity');


to:

$topic = get_record('course_sections','id',$cm->section);
if (empty ($topic->name)) {
$format = ucfirst(substr($COURSE->format,0,-1));
$topic->name = "$format $topic->section";
}
$navlinks[] = array('name' => $topic->name, 'link' => "$CFG->wwwroot/course/view.php?id={$COURSE->id}&topic={$topic->section}", 'type' => 'topic');

In modedit around line 438 update:

$navlinks[] = array('name' => $strmodulenameplural, 'link' => "$CFG->wwwroot/mod/$module->name/index.php?id=$course->id", 'type' => 'activity');

to

if (empty($sectionid)) { $sectionid=$cw->id; }
$topic = get_record('course_sections','id',$sectionid);
if (empty ($topic->name)) {
$format = ucfirst(substr($COURSE->format,0,-1));
$topic->name = "$format $topic->section";
}
$navlinks[] = array(
'name' => $topic->name,
'link' => "$CFG->wwwroot/course/view.php?id={$COURSE->id}&topic={$topic->section}",
'type' => 'topic');

We have been going along to the teaching sessions for those courses that have been using Echo360 PCAP to distribute questionnaires to students and invite them to participate in focus groups to find out more about their experiences of watching the screencasts. Given that this work has taken place within the space of a couple of weeks, we now have a pile of questionnaire data to input…then analyse…then interpret in relation to the other data we have collected.

I’m not complaining – without the data we couldn’t say very much about what the students think of the recordings that the lecturers have invested their valuable time in creating. Its just that at this moment, staring at the tower of paper, its a little daunting to think how all the different pieces will fit together to form  a coherent story about the extent to which the screencasts have helped students to put their learning into context.

A criticism of research into learning developments is that they sometimes don’t tend to go beyond a conclusion of ‘the students liked what the teachers did’. It is often very difficult to gauge the effect of an intervention on student learning given the multi-factorial influences on a student’s experience on a course. There have been numerous discussions, research articles and reviews about what constitutes ‘evidence’ in educational developments. It is very tricky, for example, to have control and experimental groups in this field, although there are rare examples of studies where this approach has been taken.

So what about the Me2U project? We are using four sources of data:

1. Questionnaire data from students
2. Focus group data from students
3. VLE log data on student access to the screencasts
4. Interviews with staff

The questionnaire data will answer the ‘did the students liked what the teachers did?’ question (the answer to this will almost certainly be positive, as students like resources). However, it will also help us to understand more about which aspects of the students’ learning the screencasts supported, how often they viewed recordings and on which devices the recordings were viewed. It will also allow us to see if there is any relationship between a student’s technical confidence and whether they watched the screencasts. The focus group data will help expand on our findings from the questionnaire data and enable us to better categorise the main areas of learning that these short screencasts can support.

I have talked about the use of VLE logs in a previous posting. We could look at the extent to which individual students have accessed the recordings and their performance in assessment tasks (or compare a current cohort’s performance with a previous year).  However, as I mentioned above, the factors that will affect these variables would swamp any potential effect of screencasts.

Instead, I see the logs as contributing  to our understanding of when it is optimum to release the screencasts to students and the type of screencasts that were viewed most often by students. This will help to promote the use of short screencasts with staff  – given their time is in such short supply, they will want to know how to make sure the students get optimum use of the recordings.

Finally, the interviews with staff are critical. We all know that the academic staff are more likely to be persuaded by their peers than by those of us in learning development. If our participants discuss their use of Personal Capture and are willing recommend it to their colleagues then the barriers to the uptake of screencasts will be lowered.

What I hope is that the project will be able to provide some sensible recommendations – that are supported by evidence – to staff about effective deployment of screencasts to support student learning The next couple of months will reveal whether or not this can be achieved…

I also gave a short presentation about the project – this was recorded, and I’m guessing will be made available on the Echo360 website shortly.

Click here to view the embedded video.

We hope the pages format is similar to design patterns used in other websites, CMS and web based apps and as such familiar and intuitive for users. A by-product the pages format is that there is no ’scroll of death’ normally associated with moodle.

The format aims to improve the workflow for tutors creating content in moodle and improve navigation, overall usability and contextual information for students.

Paolo has already written a post that describes the improvements made to the groups functionality. To support our users we will produce some screencasts that will not only demonstrate the process of how to create groups, but also include scenarios that describe how groups can be used to support both learners and tutors. This post includes the first such screencast.

For some time, staff at Sussex had requested an easy way of setting up groups in Moodle that reflected face-to-face teaching groups (e.g. seminar groups, laboratory classes). Previously, these groups had to be set up manually by adding individual students to each group. Some of the larger courses (modules) have 250 students with up to ten teaching groups, so creating these groups within Moodle is a time-consuming process. The developments that have taken place enable the information about teaching groups in the courses database to be imported in Moodle, so it now only takes a small number of clicks to create these groups.

This screencast for our tutors demonstrates how this new feature works.

Click here to view the embedded video.

An example at the University of Sussex where the groups function in Moodle has been used to recreate existing teaching groups can been seen in the presentation given by Dr Andrew Chitty at one of our Study Direct users’ meetings. Andrew used forums extensively to support face-to-face seminar discussions – he wanted to create an online space where students could discuss topics in their seminar groups. The point at which Andrew’s course ran was before the work on creating groups automatically had been released so, unfortunately, Andrew had to create the groups manually. When the course runs next year, this feature will be a real time-saver for Study Direct users like Andrew.

Making the WYSIWYG editor content look the same as when its publish is something we did a while back in moodle. People at moodlemootuk2011 showed an interest in implementing in their moodle installs, so here is how we did it.

Here is a screenshot of  the WYSIWYG editor in our moodle1.9 with some sample text :

And here is the same content when published :

As you can see Headings, paragraphs, lists, italic, bold and all other semantic text elements have the same formatting in the editor, as when they apear in the published web page.

If your trying to achieve nice looking content and don’t have this correlation it can easily lead to a lot of frustration and confusion from users.

CSS

In your theme you need a css file which has all your styles which apply to text e.g. h1,h2,p,ul,ol, a, small, strong, em, sub, sup etc…

Lets call this file text.css

It’s good practice to take all these text/font styles out of the main theme style sheet, and include this text.css in your theme. That way when you edit the text.css it maintains consistency across your site.

e.g. in the config.php we include the layout.css and the text.css

$THEME->sheets = array('layout','text');

In the WYSIWYG editor

Now you just need to include this text style sheet in the WYSIWYG editor iframe.

In lib/editor/htmlarea.php set the path to your theme and the text.css

$theme_css = "$CFG->wwwroot/theme/$theme/text_style.css"; // theme css text styles

find the comment // Generate iframe content and in the javascript add echo your theme text styles into the iframe header

<style type="text/css">@import "<?php echo $sussex_css;?>";

n.b. moodle2  uses the standard Tinymce WYSIWYG editor. For anyone familiar with this, just follow the normal Tinymce method for adding editing styles, or in the moodle version of Tinymce look for $contentcss and add your theme text.css there.

Now any changes you make to your text.css in a theme will be reflected on the site and in the WYSIWYG editor.

We have made a post on the Moot blog, which has just been published. We’d love your comments.

This is our 200 word abstract:

This presentation is based on five years of Moodle development.  Sussex University runs a large Moodle installation with approximately 9,000 users logging in per week. In order to improve the experience of our users we have made a number of developments and customisations that will interest other institutions that wish to improve the user experience of their teachers and learners.  For example

• We have a tight integration with our institutional data so staff and student information, profile pictures, course modules, memberships and teaching groups are represented in our Moodle install. This enables our learning environment to be aligned to Sussex systems and curricula and reduces duplication of effort and teachers workload
• We have improved the interface to Moodle so that users can navigate the course sites more easily and are not overwhelmed with information
• We have improved tools for site development so tutors have a quick settings bar, an improved interface for choosing resources and activities and the option to provide an identifying image for a Moodle course

We’d like this presentation to contribute to a dialogue with Moodle managers and developers in order to improve the services that we can offer in all our educational institutions.

I think that producing a PCAP screencast about the use of the tool is powerful for a number of reasons:

• It provides an immediate example to potential users of an Echo360 personal capture screencast
• It may have more of a impact on academic staff, given that it has been recorded by one of their peers
• It can be more personal than a written case study
• It gives an alternative format to the written case study – suiting visual learners

Pre-existing Sussex systems

Sussex has a history of ORACLE development and the majority of business systems use a central ORACLE database.  In 2003 Sussex engaged in a major project exposing Sussex data through a password protected portal, or managed learning environment (MLE),  called Sussex Direct.  This included personal staff data, programme and course data and student data, including assessments and grades.  This system had been extremely popular with Sussex staff and students.

Nightly sync/enrolment process

In 2005 it was decided to move from a small-scale WebCT installation to an enterprise-wide Moodle installation for the 06/07 academic year.  This is called Study Direct. In 2005 we were awarded a JISC-funded grant to integrate our central administration database (DB) with Moodle.

One of the conditions of the funding was that we followed a standards-based approach to integration, hence we used the IMS Enterprise specification. An enrolment plugin-based on IMS Enterprise had recently been contributed to Moodle by a developer at UCL. It works by passing the data out of the central DB into an XML document of IMS Enterprise specification and reading this file into Moodle. It is a robust process and problems are easily traceable, and we are relatively happy with this solution.

Unfortunately since its introduction into Moodle core it has only been partially maintained and as a result at Sussex we configure and improve it for every Moodle upgrade we do.

All Sussex course modules have a Moodle site

Sussex course data is passed to Moodle and a site is automatically created for that site.  Before 2008 this was at the request of the tutor, however since 2008 a policy decision was made and all courses now have a Moodle site.

The data we pass includes course name, study level, academic year, department, learning objectives and the start date. These become non-editable fields in the Moodle site settings.  We decided early on to that a Moodle site should exist for the duration of a student’s study. For more information about this decision see blogs post on “maintaining sites for the students programme duration”. As a result the identifier passed to Moodle was the course code appended with the term and academic year.

Before 2008 Moodle sites were made available to the students through an interface in the MLE (Sussex Direct). This was so the central DB was updated with the Moodle course site state and links were established from other systems. Now this process is reversed and we make Moodle sites available to students in Moodle and concurrently update the central DB.

We currently do not pass the timetable or assessment data although we may do in future projects.

All Sussex users have a Moodle account

Sussex staff, students and associates who have a computer service account can log in to our Moodle installation through the LDAP authentication service, however this service passes limited user data to Moodle.  We therefore decided to pass all user data through our nightly sync. Data such as their name, username, person code, and email updates the user table.  Within the edit profile screen these fields become non-editable.  However, we have also created a local Sussex roles table into which we pass a person roles and the departments and schools for which they serve this role. For the student role we pass study levels, programmes, programme years and candidate number. The user searches have been customized to use the local Sussex roles table. It is also very useful when extracting data for Moodle use analysis.

A development for the Spring term will be to pass card photos to Moodle.  We will still allow staff and students to add a Moodle picture, but where one does not exist and they have allowed use of their card photo we will pass it. We will run a script every month to look for new Sussex account card photos. For more information see blog post on importing user profiles into Moodle.

We currently do not pass user assessment data back to the central server, but we may do in the future. Furthermore we would like to link closer with user assessment records held on the central server.

Course roles are synced with Moodle course site roles

The nightly sync manages course site roles and enrolments.  We decided not to use IMS-Enrolment standards to manage unenrolment, which specified that an unenrolled user would be of a specified status. It was easier to use a “snapshot unenrol” method which looked at all current members of site and compare that with the incoming membership.

Within the membership possibilities we have added a Colleague role to Moodle. This role permits read only access to a user.  Some departments have selected to give all faculty members a Colleague role on each others’ Moodle sites.

A development for the Spring term is to make it possible to sync a course’s teaching groups with a Moodle site. This will be a manual process.  For more information, see the Teaching groups imported into Moodle blog post.

Off-the-shelf Moodle has no way of giving course sites a visual identity.  This means that list of sites such as a user would come to when they first login are text-based names.

At Sussex we felt it was important that editors had their ability to give their sites a visual identity, which would be displayed at the top of the page, in all course site lists and in search results. Visual identifiers can help a lot if your trying to scan through a long list of text. It can be quicker for users to instantly spot a familiar image, than a word.

Using the current functionality for adding images to user profiles and course groups we added the functionality for editors to upload images from either the settings page of a site, or the custom built quick editor toolbar (See the Quick editor tool bar post).

Since we put this live in January 2011 62 of the Spring term course sites (approximately 10% of Spring courses with a Moodle site) and a further 29 other sites have added a site image, and we are seeing bold and imaginative choices shown by editors in site images.

We think course images look quite nice, and adds character to sites. Sometimes, even in a VLE, a little bit eye-candy can be a good thing.

When a user in moodle chooses to view a single section of a site, they are shown the section as expected.

Moodle stores which section you are viewing, so that when you go to a resource or activity and then return to the site, you are still viewing the section you last looked at.

This can be useful for users within the context of a single session. However, we found that even if a user logs out, changes computer, or returns to a site after several days they are still shown the section they last looked at.

Imagine if once you loged in sites like amazon, ebay, facebook or youtube and went into a view, it showed you the content you last looked at. This never happens. So the fact that it happens in moodle is perhaps understandably confusing for our users.

Some of our students report they are unable to see resources tutors inform them have been added, beacause moodle is only showing them a single section of a site when they login in. Other report no longer being able to see resources they have previously accessed, simply because moodle is showing them only one section – the section in the course moodle remembers in the db from when they last visited the course.

Our solution :

The behaviour users expect is when they visit a site, to be shown the landing page of a course/site. We need to clear moodle’s ‘extended memory’ to achieve this.

Clearing this memory when a user logs out would seem to be the natural approach. Realistically most users do not press the logout button, but simply shut down or close the browser. Triggering events on browser close isn’t an easy task.

So we approached it by clearing this data on login, which achieves the same effect.

There are two separate places where moodle looks to see which section the user was previously viewing in a site.

• In the database – table called prefix_course_display
• In the $user->display cookie array, keyed by course id

Both of these needed to be cleared to give moodle a more standard web pattern of behaviour.

Our code :

In login/index.php

Moodle1.9

// clear data on users last section visited in sites / courses
if (record_exists('course_display', 'userid', $user->id) ) {
delete_records('course_display', 'userid', $user->id);
foreach($user->display as $key => $value) {
$user->display[$key] = '';
}
}


Moodle2

if ($DB->record_exists('course_display', array('userid'=> $user->id) ) ) {
$DB->delete_records('course_display', array('userid' => $user->id) );
foreach($user->display as $key => $value) {
$user->display[$key] = '';
}
}


This might not be the best or only solution, so we would be grateful to hear from others who found the same problem, and how they dealt with it.

Again – the very helpful DB layer 2.0 pages in moodle helped us upgrade our 1.9 code to moodle2.

We implemented this fix in Jan 2010, and so far have seen a complete drop in the number of users contacting support about not being able to see a resource or section.

In order to help out our staff and tutors we added a quick editor toobar which has the common settings that Moodle editors often need to change in their sites.  The toolbar is displayed to editors at the top of the page when editing is on.

The bar allows editors to quickly :

• Make site available to students / make site unavailable to students
• Increase the number of course sections
• Add a course site image (local customisation)

Anecdotal evidence suggests the editor bar has been warmly welcomed by academics.

One of the great things about Moodle (and other virtual learning environments) is that they record which pages on a site students have visited and when they visited them. In the context of the Me2U project, this means we can get some idea of how students on the course are accessing the materials.

We have started looking at the usage statistics for some of the screencasts and thinking about the meaningful data we can extract (given the plethora of data that VLE reports produce, it’s tempting to analyse everything).

So far, we have looked at:

• the proportion of students on the course who have viewed each screencast;
• how these figures compare to other resources available on the course site (for example, PowerPoint slides, lecture notes);
• the degree of overlap between those who have viewed screencasts and a similar resource that is available in another format (e.g. preparation material for practical ) – this could give us an insight into whether there are some students who prefer a more visual format;
• the kinds of screencasts appear to be most popular with students.

We’ve only just started looking at these data on a small number of courses, so drawing any firm conclusions at this stage is tricky. However, usage stats show that students are looking at the screencasts, even when they are available in alternative formats. Also – and perhaps no great surprise – the screencasts that get the most views tend to be those that offer guidance and support on the assessment, e.g. advice on essays writing, pointers for mock tests.

So – we know students are looking at these resources – now we need to ascertain how useful they feel they are. I think screencasting offers real potential in terms of helping students’ understanding of assessment expectations and we’ll hopefully be able look at this in more detail through our other forms of data collection.

For example Sussex 3rd year students have Moodle sites for all the course modules they have taken, through the academic years 10/11, 09/10 and 08/09. They can return to their first year, and indeed any sites they have been enrolled on during their time at Sussex.

This has implications pedagogically, socially and technically.

Pedagogical implications

There are advantages for the students because they can access their previous year’s sites so for example they can return to their original lecture notes, the discussions they had and the feedback they got from formative online assessments such as quizzes.

Social implications

Often student contributions to Moodle activities are chatty and temporal in nature and it is not always useful or desirable to have them inscribed permanently in the online learning space. Keeping sites for the entire length of a student’s degree ingrains the idea of permanency of student contributions and might deter students from contributing.

Technical implications

Whist we have tentatively explored hosting different Moodle installations for different years we currently keep all sites on one Moodle installation, having decided it is better to have one code source and database to maintain. This effects the method by which we roll sites forward to new academic years, navigate Moodle sites and server disc space.

Rolling sites forward

At the start of each academic year courses have new empty Moodle sites created for them.  Often the tutors want to import the data from the previous year’s site. There are two Moodle features which help tutors do this: “import” and “backup and restore”.  Because import is simpler we encourage tutors to use this method. To support this we added a plugin which meant the “import” process brought across the site section summaries if one didn’t exist.

Navigating Moodle sites

Because we keep Moodle sites for three years or longer we have many sites available to our users. If sites are sorted alphabetically users have to sift through many old sites which they no longer regularly access. In order to combat this we have added an academic year field to the database that allows us to sort sites chronologically.

Server disc space

In general sites within a 1.9 Moodle installation have separate file stores. This means that files used in more than one site are stored separately. Often tutors might use the same files from year to year. This means that we have different files containing the same data for each instance of a site (08/09, 09/10, 10/11).  As a result we currently have in excess of 400GB of data. This is an issue for our infrastructure team and it also means that there is too much data for us to have an exact development replica of the live system.

However many students and staff haven’t uploaded an avatar in Moodle. We have therefore initiated a Spring term project to import staff or student card photos from users web profiles, where they have permitted its use.

Current use of card photos

In Sussex’s Managed Learning Environment (MLE), Sussex Direct, you can select to show your staff or student card photo to everyone on the web. Staff can also upload an alternative photo. These options are respected within the MLE, the staff profile pages visible on the Sussex web pages, but they are not currently respected in our Moodle installation.

Development plan

In Moodle, Sussex’s Virtual Learning Environment (VLE), users can put up avatars of themselves. These avatars can be more casual than a card photo. We like this because it reflects the informal learning environment that the VLE can represent. However, where a staff or student hasn’t selected to put up an avatar we would like to use the card  photo where they have permitted everyone to see it.

A new picture_sussex database table

We created a new table in the Moodle database so

• We have a record of all photos copied
• If a copied photo is deleted in Moodle we don’t copy it again

Guest users are presented with sites – by academic year – to which the creators have allowed guest access.

When Moodle became our institutional VLE a minority of staff had issues with users having to sign in to access their learning materials, in particular those member of staff with web pages who were used to distributing their course material through their web pages. These staff did not like the fact that their materials would now be behind a central password protected portal, even if they had the option to provide “guest access”.

The problem with standard guest access

In a default Moodle installation you need to find the links to the course site categories, then look for a small non-standard icon by the course which indicates it allows guest to enter. It can be a lot of clicks, and very difficult to explain to users.

In a Moodle install with as many sites as Sussex, it becomes a thankless endeavour.

Our solution

We made all sites which allow guest access visible from the first page a guest comes to, so they don’t have to root around the site categories pages looking for sites which might be available to them!

The code :

$courses = get_records_select("course","guest=1 && visible=1" , $courses_sort_query);

Our $courses variable is loaded with all the visible courses, with guest access set, then sorted in the same $courses_sort_query order as our logged in users see.

By doing this, we try and give guest users the same experience as our authenticated users.

You can login as a guest to Study Direct here.

• seminars
• tutorials
• workshops
• laboratory classes

Each of these might split a module cohort into groups. We call these teaching groups.

Like our course modules at Sussex, Moodle has a notion of groups and teaching groups which they call ‘groupings’.

Using these groupings in a VLE can help tutors target resources and activities at the relevant groups of students and our tutors have sometimes requested to use these real world groupings in their online sites.

A Spring term development at Sussex will be to implement a method to import these teaching groups from our courses into our Moodle sites. Because of its overheads, rather than automatically running it for every site, we leave it as a manual process which the tutor can perform on demand.

Whilst developing the teaching group import we also looked at and made some refinements to the Moodle group interface to help make it easier for our staff to use, and the language of groups and groupings clearer.

Simplified groups & supergroups interface

There are three use cases for a tutor using groups & supergroups.

1. No groups or supergroups exist

If no groups are set up tutor is taken to page which says so, clearly explaining how groups can be used and benefit the site, and tells user what to do next if they want to use groups.

2. Import/Create groups and supergroups

A Tutor has the ability to import teaching groups if they exist, create groups, auto-create groups and create groupings which we have called “supergroups”. The interface is improved and options are accompanied with a brief none-technical description.

3. Managing groups and supergroups

If groups are already set up user is taken to overview page where management of groups is possible.  The management options are dependent on whether the grouping (supergroup) has been imported from a teaching group or created manually.

Reduced complexity

By knowing the current site groups ’state’ (e.g. groups exists, groups don’t exist) we are able to show the user the appropriate information without them having to search the different tabs/options. Almost all tasks can be carried out in one place without having to switch between different tabs.

Clarity

After interviews with staff, re-labelling groupings as supergroup was suggested as a way of re-enforcing the hierarchy which exists between groups and groupings. The notion of groups and supergoups is not a simple one for most users to understand. By clearly showing the structure/hierarchy (Supergroup > groups > user) on one main landing page we hope to make this more obvious to our tutors.

Integration into Moodle 2

This development has been developed and tested in Moodle 1.9, but our evaluation of Moodle 2 show that the interface pattern could equally benefit tutors using groups in Moodle 2.

This is another step in bringing moodle into line with other content management systems, and we like it.

The section name text box isn’t WYSIWYG – so it’s less confusing and will inherit any stylesheet – also its just the right size to encourage users to enter a short, descriptive and meaningful name as a navigation element.

So, why is this important?

At Sussex we encourage our content creators to build a rich user experience for their students. We encourage teachers to add contextual information (using labels) videos and images to each section. Each section,week or topic in moodle becomes more than just a list of links.

Interviews with students and statistical data on site use, seems to support the theory that students find this enjoyable and engaging, and our tutors often take a pride in the experience they can create online for students.

With tutors spending time creating supportive text, images and contextualising the resources/activities in a section it’s important students see this, and don’t just go straight to a resource/activity without seeing the context.

For our VLE in Sussex enabling navigation to resources/activities without any contextual information the tutor intended when designing the course could be considered detrimental to the learning environment. Tutors and users rely on navigating to sections, rather than a list of uncontextualised links.

For our VLE it’s really important for us to create navigation which allows a user to visit site sections, as the course designer intended. By default moodle (1.9 or 2) does not support this kind of navigation with links to sections (moodle2), or meaningful section titles for users (moodle 1.9 section links block).

The new field - section name – could easily enable tutors to create meaningful navigation to sections in their site.

Mock section names for a site/course – moodle1.9

Within our current install (moodle1.9) users are able to navigate to any section in a site (in Sussex each moodle course is called a site).We use the the YUI menu block to generate a site menu. This is generally displayed in every site, as the first block on the left hand side.

The block itself grabs the first 19 characters from the section summary, and uses that text (stripping any HTML) as the section names. Users can configure the amount of characters to use from the summary for longer titles, but unfortunately that is a complex idea for a user to understand, and can lead to section names not being as useful as they might be.

When used well – it’s a powerful and essential usability navigation element, but (due to its complexity for the user) in the majority of cases its not deployed in an optimal way.

Getting the section names for a site/course in moodle2

Moodle2’s addition of a Section name gets rid of the need for the complexity to the user of the YUI menu block. Instead users have a very clear, simple field which will be their section name, and we like this.

We plunged straight into writing our first block in moodle2.0 by trying to create a site navigation menu – using the section names.


$course_sections = $DB->get_records("course_sections", array('course' => $COURSE->id));
foreach ($course_sections as $section) {
$section_name = $section->name;
$visible = $section->visible;
if(!$section_name) {
$section_name = "section ".$section->section;
}
$section_link = $CFG->wwwroot/course/view.php?id=$COURSE->id&$course_format=$section->section;

You’ll notice the new $DB layer format for get_record, and the new array key => value query, but apart from that the code should be pretty familiar to most moodle developers, and if you need a hand the DB layer 2.0 docs are a good starting point.

Here as a screenshot of our UX Nav block in action on a moodle2 site – with some Section names added, and others using the default name.

There are currently no plans to release this as a moodle2 block, but hopefully the code above can help you make your own quite quickly if its something you think user experience on  your moodle2 install will be improved by.

The project aimed to recruit ten lecturers to participate in the project and we decided to enlist three participants for the first phase (October – December) – the rationale being that any teething problems with the technology would be likely to occur in this phase and we may want to refine our evaluation methods in light of our initial findings.

Two of our the three participants were from the School of Psychology with a third from School of Global Studies (Department of Geography) and they have used PCAP in a number of exciting ways.

• One of the Psychology lecturers used it to help student to prepare for a computer lab class by recording a walk-through of the web-based resources that student would need to access during the lab.
• The other Psychology tutor used PCAP to record student presentations – giving  students the ability to review their presentations alongside the feedback received from the tutor. The students agreed to be recorded using PCAP on the condition that the tutor recorded the series of lectures (pretty canny students if you ask me)
• The lecturer in Geography used it to both provide resources that complemented his lectures (see screenshot, below) and to give some pointers to a mid-term test  and  some feedback to the cohort on the test.

We have been evaluating the students’ experiences through questionnaires and we are in the process of analysing these data. At first glance, student experiences have been very positive. I guess this isn’t so surprising – we know that students like resources to support their learning – so we are now running focus groups with students to  try and unpick why they feel that this medium could be a valuable tool for learning. We are also interviewing the staff to evaluate the extent to which they feel the recordings are a useful learning tool and to gauge how long it takes to make a recording.

We’ll be writing about these findings and our next phase of the project soon.

We already talked in a previous blogpost about the ability in moodle2 themes to include and exclude css & javascript from a themes parent. We appreciate this inheritance model which makes it simpler to have a base css, and vastly change the appearance of your whole site with  relatively few, clear lines of css.

It took us about 5mins to implement a ‘nude’ Sussex style-sheet in moodle2.

The process

Following the guidlines for moodle2 themes we created a sussex theme folder, edited the config file, imported the layout files from base, and set our parent theme to base.

Like many of the themes already created we included Paul Irish’s html5boilerplate css – which includes Eric Meyer’s reset realoded and a gives us a nice basic usability baseline.

In the sussex theme folder we created 2 stylesheets – layout and text.


/*LAYOUT CSS */
html,body {
background-color:#E1E8EB;
}
#page-wrapper {
width:990px;
background-color:white;
-moz-border-radius: 1em;
border-radius: 1em;
margin:1em auto;
padding:1em;
}



/* TEXT CSS */
html, body, select, input, textarea {
font-family: Geneva,Verdana,Tahoma,sans-serif;
color:#555555;
}
body, div, span, blockquote, p, li, pre,
abbr, address, cite, code,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section, summary,time, mark, audio, video {
font-size:14px;
line-height:1.5em;
}
h1,h2,h3,h4,h5,h6 {
font-family:Georgia,serif;
font-weight:400;
}
/*LINKS */
a, a:link, a:visited {
color: #11718F;
text-decoration: none;
}
a:hover {
color:#224857;
text-decoration:underline;
}


Here a screenshot of the results :

As you can see, it’s a ridiculously small amount of css to produce something remarkably similar to our current moodle style (which uses far more css).

Bonus fun

Again, limited CSS for a SWISS style ultra thin Helvetica theme, with bold underlines and lots of white space :

Using a almost the same CSS to try a quick Eric Gill ‘nude’ theme using Gill Sans and Perpetua :

Obviously, the sussex style sheet isn’t yet complete – but from an initial perspective moodle2’s new ways of creating themes seem a big win.

Using tools including:

• Firebug for Firefox,
• Yahoo’s Yslow,
• Google’s Page Speed,

allowed us to analyses what was slowing pages down, and how to improve this.

1. Minify and compress

Moodle2 comes with built in minify and gzipping for css and javascript!

2. Load things in the right place

Moodle2 theme config.php allows us to load javascript in the footer of the page instead of the header :
$THEME->javascripts_footer = array();

3. Don’t load things you don’t need

Moodle2 allows us to exclude parent theme css and javascript :

$THEME->parents_exclude_javascripts = array();
$THEME->parents_exclude_sheets = array();


Minifying javascript can create some interesting results, so the fact that the moodle2 team thought about and managed to do this is very much appreciated.

For anyone interested in speeding up their site – the best practice guidelines by yahoo & google (along with the tools above) can be an interesting insight into improving things for your users, and making your code better.

So far, we are just evaluating a test install of moodle2, but will be updating the blog with further findings.

In August 2010, a proposal submitted by a team from the University of Sussex, UK was awarded funding as part of the Echo360 grants programme. The project, called ‘Me2U’ (on reflection, a title perhaps too close to the  Chuckle Brothers catchphrase), has set out to investigate the ways in which the personal capture version of Echo360 (PCAP) can be used to support student learning. Echo360 PCAP can be installed on a laptop and will record what is displayed on the screen, an audio track and a video feed from a webcam. It then produces the recording in three files formats – flash, m4v and mp3.

One of the advantages that we see with Echo360 PCAP is that its interface is very simple and it does not require any specialist knowledge about converting a recording into an appropriate file type. The process by which a recording is published is exactly the same as that used in the Echo360 lecture theatre set up. Users do not, therefore, require any further technical guidance, freeing them to focus on the pedagogic aspects of the recordings.

What we are really interested in finding out is how short recordings can, for example:

• help students know where they are going with the course, how it might relate to other courses and what the tutor expects;
• clarify questions raised by students on a particular topic or concept, or prepare students for their first piece of assessment;
• provide an end-of-course synopsis or help prepare for the end of year exams.

Our first phase is underway – we are supporting those involved in the creating recordings – both in how to use the software and discussing the kinds of recordings they could make.

We’ll be providing updates on how the project is progessing through the e-learning blog.

Even though I’m a pretty fast touch typist, I find that making hand-written notes feels more expressive.

• I like being able to annotate text I’ve already written.
• I like the ability to make doodling/ diagramming part of the thinking process
• I like using white space in my layout to help order and structure the text
• I like the informality and aesthetics of hand writing

BUT

• I end up carrying old notebooks around with me for ages because they still contain some material I need, even when I’ve moved onto a new notebook
• If I forget to carry my notebook with me, sometimes I can’t access important information
• It can take a long time to find a particular note that I need to access
• It’s not very easy to cross check notes to find all the instances where a particular issue has been discussed

So I was quite excited when our Teaching and Learning Development Unit offered me the opportunity to take a Pulse Livescribe pen with me to ALT-C 2010 earlier this month.

The Pulse Livescribe smart pen contains a miniature camera and a recording device. When you write with it on special “dot” paper, it is able to track the coordinates of all of your pen strokes and record exactly what you’ve written and where you’ve written it.

Then when you dock the pen with your PC or Mac, it can upload all of your notes.

It then indexes them.

Oh, and it lets you make an audio recording. These recordings are synchronised with the stream of pen strokes that the device captures. This also allows you to use your written notes as an index into the recordings you’ve made.

So what was it like using the Pulse livescribe pen at a conference?

First of all, I discovered that in order for the character recognition software to work, I was going to have to serious neaten up my hand writing. But for anyone who knows me and has tried to decipher post-it notes addressed to them – this is no bad thing.

Assuming I can actually write neat enough, getting all my notes searchable feels like a pretty powerful outcome.

Now I can do searches across all of my Alt-C notes for themes I was tracking at the conference. The image below shows the result set for a search of the term “feedback”:

I had a seriously excited moment when I thought that I might be able to index all notes I took in all meetings, and manage my entire working life using this little pen.

But when I downloaded the MyScript tool to do this (available for a trial license from the Livescribe website) I found out that this was a bit optimistic. My handwritten phrase “the science of learning” became “the silence of turning”. Maybe my life wasn’t going to be transformed.

Why then did the search function work so well? The software is indexing any single hand-written word against a number of possible text matches. So whether I searched my notes for “science” or for “silence”, I would find the same hand-written word being highlighted in my notes.

SO, did I keep using the Livescribe pen? I had to give it back for someone else to use and I didn’t really miss it.

I think if I used audio recordings more as a way of making notes, I would find it very beneficial for my notes to function as an index into the relevant part of the audio.

If I was able to write neatly enough for the MyScript tool to decode my notes, I would definitely use it.

For now though, I’ll wait and see ..

Anyone editing in moodle is used to two very familiar drop down menus as the main methods for adding content.

Add a resource

Add an activity

The problem

Examining the sites tutors built at Sussex showed us they tended used a limited set of these.

Bariers

Interviews with tutors brought up some interesting issues with these drop down menus and the language used, verses the aims of the tutors and the support they needed.

Time is always a premium to our tutors and so they simply didn’t have time to try adding things they didn’t understand or know if they would perform the task they wanted.

Our solution

We replaced the two dropdown menu with two buttons.

Clicking on the buttons brings up a model dialogue of the options.

The resources a user can add are shown in clear sections, based on tasks. e.g. The Create Pages section contains links to add a web page, text page or our custom youtube page.

Each resource has supporting text, detailing at a glance what the resource enables the user to do, and a link to help with the resource. This comes into its own with activites, where tutors may be unfamiliar with concepts such as a wiki, and if using an activity can help them achieve their learning aims for the site.

By removing some of the jargon labels, splitting resources and activities into task based sections, and adding brief inline descriptions we hope to help our tutors pick the right tools for the learning outcomes they want to achieve.

On a daily basis our tutors, academics and staff use our moodle install at Sussex to add pdfs, powerpoints, word docs and other teaching materials to their sites in order to make them available for students.

Students love the fact that this wealth of material is available to them. Tutors struggle with making it available to them.

Moodle does provides a fantastic framework for security, permissions and the backend of file management, but our content creators (lecturers and staff) often struggle with the front end interface – so we decided to improve it for them.

User interviews

How do our users use moodle?

We began by conducting a series of one to one sessions with some of our expert users – those tutors, lecturers and researchers who regularly create fantastic e-learning experiences for their students. In these sessions we visited theses expert users in their own environment, observing their daily use of moodle.  We also asked them how they would like it to work, and to show us other websites or applications they commonly use to do similar tasks.

How do other ‘products’ do file upload &  management?

We looked at some other web based CMS (content management systems), commonly used websites (facebook, twitter, google docs, dropbox etc) and applications our tutors use (word, powerpoint etc).

Initial findings

Our first finding was to do with the different ways users can add a file in moodle. There were two different methods – both with very different workflows – our expert users commonly used to add files.

1. Add a resource – Link to a File or Website

When editing is on users can select from the dropdown menu an option to upload a file called “Link to a File or Website”. From a developer perspective this seems perfectly legitimate – a link in html does not care if its to an asset on the same site, or another website.

From a language and user aim perspective our users had a great deal of difficulty with this concept and the labelling.

Users suggested ”Upload a file” would be a more appropriate label. It should be noted that these expert users use moodle every day, but unfortunately still find it a struggle to remember how to do some of the common, repeated activities. This would indicate a more intuitive process – based on the language and tasks the user needs to carry out – would be more appropriate for our interface we give to users.

Adding a resource form

The standard form for adding a file resource in moodle brought up some interesting usability challenges for our tutors.

Window & other form elements

The form itself has a large number of options for opening the resource in a frame, a pop-up window, showing navigation, menu bars, location bars, the size of the window etc..

Many of our users were unaware of the implications of these setting for the end user, the usability and accessibility problems associated with setting these options incorrectly, what the size in pixles of there resource – or indeed a page is, what a status bar is etc…

As developers we know most of these options can be ignored. We know that best practice tells us never to use frames and to open files such as pdfs and word documents with the appropriate application and not with a browser.  We know that images, movies and audio can be displayed in most browsers. This is a complex set of web content rules we learn, but we found most of our users had no conception of these rules or (understandably) any wish to learn them.

For users with limited time, trying to complete a relatively simple task which other systems allow them to easily, presenting this hi-level of control and complexity was unwelcome. This generally applied to all standard moodle elements of form.

Generally we found our users just wanted to add a file, and for it to work.

Choose or upload a file form / pop-up window

The Choose a file button opened a pop-up window (by default – blocked) presenting the moodle standard file interface. One user stated that to reach this page they had now clicked / requested to upload a file three times, and seemed no nearer their goal.

Many users spent a while on this page searching for the (bottom right) upload a new file button.

Comparing to other systems users found the lack of a progress indicator, and error messages if the file was large to be frustrating.

Once uploaded none of the 12 expert moodle users interviewed were immediately able to find the Action > Choose button immediately, with many clicking on the file name. Those users with a lot of files were often unable to spot if the upload had been successful or if the file was listed in their list of files.

It was interesting to see the number of users who did not seem to be using folders to organise their files online, but would do on their personal computer. When questioned further users tended to not look favourably on the  method of creating folders and moving files within moodle. Users were also unsure if link integrity would be maintained when files were renamed or moved.

Searching the moodle forums had shown that moodle developers were aware of the issues with this process and in the process re-working it for moodle2. Unfortunately on our large production site we cannot wait for moodle2 and need to address some of the issues to make life easier for our primary asset – our content creators.

2. Through the html/WYSIWYG editor

In our staff training courses at Sussex we encourage users to use the first method for adding files, but many found it more familiar to do so thought the WYSIWYG html editor in moodle. This seemed to be a workflow users were more familiar with, and enabled them to easily add contextual information relating to the resource.

Improvement requirements

From our initial investigation a clear set of requirements emerged.

Basics

• Clear and simple labelling for tasks
• Reduced complexity, jargon and options
• Better layout for primary actions
• A progress bar for uploads
• Clear indications of success / failure in a task
• Intuitive file selection (e.g. onclick)

Advanced

• Less clicks to perform a task
• Helpful and meaningful guidance text during task
• Improve ability to organise files online – e.g. rename, move, preview
• Intelligent best practice display of resources based on mimi type - e.g.  pdfs = download, audio = play in browser
• Helpful and meaningful error messages
• Avoid the use of pop-ups which modern browsers block

Additional requirements

During interviews users also mentioned uploading multiple files. This was not an issue when adding single resource, but in more general file management of site files. Many lecturers have a folder of lecture slides and would like to make them all available, but currently have to individually choose each one – a slow and painful process. Users are familiar with, but not competent, in zipping files. Users said  the ability to select more than one file to upload at once would improve their workflow considerably.

• Multiple file upload

Our solution

We demonstrated the new file management tools at the Study Direct user group meeting in June 2010.

Click here to view the embedded video.

Next time…

In the next of these post we talk about wireframeing, prototyping and testing improvements to file upload including technical details of our implementation in moodle 1.9.

Sites by year

At Sussex a site for each course is created each year, with Students and Tutors for the site pulled in from our central database. Students and Tutors can go back and look at previous years sites and find this very useful. It can however prove confusing in moodle where a user could have many sites with exactly the same name – from different years. Tutors, for example, can teach the same course each year and have sites for every year they have been teaching the course. To help us organise this we keep meta-data about the course year, study level and term (Spring, Autum etc..) in the moodle database and can use it to organise how we show sites to users.

The new ‘Your sites’ page takes full advantage of this – organising sites into :

Current sites - sites from the current academic year & sites which do not have any academic year but run continuously

and individual academic years - in the screen shot below 08-09, 07-08 and 05-06

We presented these initial ideas at a user group meeting for june 2010 – shown in the video below.

So far this seemed to be an approach users like, and after further consultation with users we started to implement it in moodle with some more features the users requested.

Displaying site metadata

In the screen shot below you can see Accuracy in Academic Communications is an Autumn 09-10 Undergraduate course. Colour coding is given to the term data - brown for autumn, green for spring and yellow for summer – as an added differentiator.

Sites which are in ‘draft’ – i.e. not published to Students – are shown to Tutors only with a message, and yellow background.

Site roles & clustering of colleague sites

The role a user has in each site is displayed clearly on the right hand side.

One of the problems some staff face is the sheer number of sites they have access to. Some Staff may have access to all the sites in their department or school. To ‘hide’ these sites they may not be directly responsible for, but need access to, a special list called Colleague sites was created. In the screen shot below you can see a link to the Colleague sites i have access to.

Encouraging interaction

It’s not always easy on moodle sites, without clicking into the individual site, to see if any activity such as forum discussions has occurred since your last visit, so we pull this data out and show it under each site. In the screen shot below Stuart’s site has a Forum Update, with the time since the post shown in a ‘twitter’ style – 4 seconds ago.

Other activities including for a site are accessible directly from  this page – e.g in the screen shot below afterSuss : Career Development Course shows Assignments and Quizzes. By clicking on these buttons details of the activity are displayed, including the number submitted, if it has been graded, due date and other relevant date the user is allowed to see.

Reducing ‘noise’

The screen-shot of the older Your Sites pages shows what a pretty typical user would see, and uses an off the shelf moodle style. User feedback suggested blocks on the page – although useful for admin users – were infact never clicked by most users. Information shown by default about each site e.g. user role, activities and updates –  was also mostly unread, possible due to the sheer amount of data and lack of differentiation in its display.

The page itself is called Your sites and has one primary task – to display the sites a user has access to. So why do we need all the other functionality of the page? By concentrating on doing the one simple primary task in the best way possible we hope to create a better user experience for all our visitors.

Styling the page

To help bring emphasis to forum posts users picture icons are shown, and as previously mentioned, the date since the update is shown in a ‘twitter’ style of seconds since, hours since and days since – we hope this will encourage user interaction/awareness of site forums.

We use the Sussex brand fonts – Georgia (headings) and Geneva(body) – and colour definition to highlight different types of metadata.

Javascript ‘facebook’ style show / hide buttons are used to allow users to choose which activities and updates they want to see, without overwhelming them with information. A 25% horizontal grid is used to space each ‘update’ in a more readable way.

John Davies made a video of the live implementation on Study Direct which you can watch below.

* Bonus ipod/ipad/iphone gesture fun!

Fun isn’t something generally associated with a VLE, but the ipod touch and ipad try and make all forms of user interaction fun. In the previous month Study Direct had over 2000 visits from users with on ipad/pod/phone. Touch screen users are used to swiping left, and swiping right to move from one page to the next. So on the Your sites page if your using an ipad/ipod touch or iphone you can simply swipe left and right to move through the lists of different academic year sites. You can try this yourself through guest access to study direct if your on an apple touch device, or on a normal computer try using the left and right arrow keys. Simple, and yes – fun!

New 2010 ‘Your sites’ page

Old ‘Your sites’ page

Code improvements

As with the landing page re-design we took the oportunity to have a dig under the hood and try and improve the php, database queries, html, css and Javascript used to display the page.

By reducing the amount of html, eliminating tables and reducing/simplifying code we improved the accessibility of the page, and got some major improvements in page load times too.

Some technical stats :

Even with the inclusion of user profile images for forum posts the new Your sites page loads in approx half the time of the previous standard moodle page.

So far the feedback from users has been good, but we are always looking for other ways to improve our users experience as a whole.

2009 login page

The 2009 login page contained a lot of information and images, which pushed the actual login box down quite far down the screen. We found for users with smaller screens they often had to scroll to enter their login details. For users with screen readers this was a particular problem, as the login box was the very last thing on the page. Although the page has very clear and detailed text everywhere – generally users found it rather over-busy with no clear focus on what the page was, or what they could do here.

2010 login page

The page now – hopefully – tells you where you are, and what you can do here – sign in.

We also took the time to add a ‘Forgot your username or password’ link and some nice HTML5 form features including :

• placeholder text – letting the user know what they should enter into a form field
• autofocus – so the primary form field gets automatic focus when a page is loaded.

Combining the new HTML5 attributes with cleaner CSS and HTML also allowed us to make improvements to the usability, which has a knock-on effect for the accessibility of the page. The sections below the US header now render much clearer with CSS disabled, the TABLES previously used for the form layout have been removed making tabbing faster for screen readers.

The page is also loading much quicker.

Behind the scenes the page doesn’t load all the CSS and JAVASCRIPT  libraries usually loaded on every Moodle page, as it does not need them. It just includes what’s actually necessary for the user to log in.

Some technical stats :

By reducing the number of http requests to load files we did not need, and reducing the size of the responses by only sending back data we needed we managed to more than half the average page load time.

So far user feedback on the new layout has been very positive, and we hope to be making further improvements to the accessibility as soon.