They’ve also used the example of the Quiz Add question dialog (tracker item) we did with Tim for allowing people to add activity modules on the course front page. Originally I actually found this UI pattern in QuestionMark during the user research sessions done for the Quiz UI redesign project – great to see it being put to good use.

This should make adding activities more straightforward. Yay!

(Thanks to Helen Foster for the screenshot and to Mary Cooch for the screencast)

If you have a different point of view or know scientific articles or textbooks that further discuss this, I would love to hear about it!

A Dictionary of Computing:

dialog management   The methods and procedures governing the way that information is exchanged between the user and the computer system. It involves the consistent formatting of prompts, check boxes, lists of options, sliders, messages, and other constructs. There are modal dialogs, where the user can do nothing else until the action required to satisfy the dialog has been taken; this can be as simple as acknowledging a message. Conversely, a modeless dialog is one that may be returned to after attending to other matters. See also dialog box. (Ed John Daintith and Edmund Wright. Oxford University Press, 2008. Oxford Reference Online. Oxford University Press.  Tampere University.  Looked up on 14 November 2011  <http://www.oxfordreference.com/views/ENTRY.html?subview=Main&entry=t11.e6022>)

 

http://www.usabilityfirst.com/glossary/modal/

modal

a type of interface where the user moves between different states, or modes. In each mode, input from the user is interpreted in a different way. When a user is in a given mode, it’s a good idea to provide an extremely salient indicator of which mode is currently active, e.g. by providing a large icon or shifting the color of the screen.

Modes are usually good to avoid because users are restricted in their available actions and they may be confused that the meaning of their actions changes as they change contexts. However, modes can sometimes be helpful to control and guide input (providing security and preventing accidental errors), and modes may be appropriate when they are short and actively maintained by a user (e.g. the fact that keys refer to capital letters only when the Shift key is held down) and when they follow well-understood conventions, such as painting tools.

Examples of modes include:

• Choosing a painting tool in a paint program. When the Line tool is selected, for instance, all mouse clicks create lines. When a brush tool is selected, the user is in a different mode because all mouse clicks are then interpreted as painting.
• Old text processors, such as ‘vi’ in UNIX, often used a command mode and an edit mode. In a command mode, keystrokes issued commands. In an edit mode, keystrokes were entered into a text document.
• Moving between pages on a website. Each page is a mode which limits the kinds of actions a user can take (where they can go).
• Modal dialog boxes are ones that force a user to respond to them before the user can go back to using other aspects of the application.

http://catb.org/~esr/writings/taouu/html/ch01s03.html

Rule of Modelessness: The interface’s response to user actions should be consistent and never depend on hidden state.

This rule could be taken as a consequence of the Rule of Transparency, but violations are so common and such an important cause of interface problems that we have chosen to foreground it by making it a separate rule.

An interface with “modes” responds to the same input gesture in different ways depending either on hidden state not visible to the user, or on where you are within the interface. Since the early days of the Macintosh, which eliminated mode dependencies almost completely, it has been widely understood that modes are a bad idea.

The classic bad example in Unix-land is vi(1), a commonly-used editor in which typed characters are either inserted before the cursor or interpreted as editor commands, depending on whether or not you are in insert mode. This is a well-known cause of confusion to novices, and even experts at this editor occasionally trash portions of their documents through having lost track of what mode they are in or inadvertently switched modes. Modern versions of vi(1), partly mitigate this design flaw by providing a visible mode indicator. We know this is not a complete solution, because even expert users can overlook the state of the mode indicator and find themselves in trouble.

We’ll see in the Wetware chapter that modes interfere with the process of habituation by which users become expert with interfaces; indeed, they turn habituation into a trap. A computing system ideally designed for human use would have one single set of gestures and commands that are unformly applicable and have consistent meanings across its entire scope.

http://catb.org/~esr/writings/taouu/html/ch04s04.html

Raskin makes the empirical point that human beings cannot be prevented from forming habits about routine tasks, and elegantly defines good interfaces as those which encourage benevolent habituation. We can go a bit further and observe that “benevolent habituation” – the ability to do the right thing by unconscious or half-conscious reflex – is precisely what we normally mean by expertise.

Thus, our Rule of Modelessness. Users will form gestural habits, and it is a bad thing when gestural habits they form in one part of the system become inappropriate or even destructive in another part. When this leads to problems, the fault lies not with the user’s habits but with system designers’ failure to maintain consistency.

Also some of Nielsen’s heuristics seem relevant:

http://www.useit.com/papers/heuristic/heuristic_list.html

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

I interviewed a Finnish polytechnic teacher back in July, and presented discoveries from that interview/brainstorming session in part 1. She uses Blackboard for her courses but is considering moving to Moodle. She is a bit confused when people around her are thinking of Moodle as more of a document repository than a learning platform. She acknowledges that there is probably more to it. Still, she thinks Blackboard better guides teachers who do not have a strong idea of their pedagogical approach, than Moodle.

How does Moodle encourage interaction? Currently a Moodle course UI front page, however well designed, implies staticness, a predefined list of stuff that students simply come to and start chewing over. The first impression of a course is that it is all predefined and coming from above. However interactive the modules behind the links are, you do not perceive that when you see a course front page, which can be overwhelming enough to stop you from exploring any further.

The challenge of Moodle course front pages comes in two parts. First, teachers need to perceive that a Moodle course is not just a list of documents, but something that can empower them to communicate with their students in a rich way. Then, I believe, there needs to be more vividness in a Moodle course also for students. To start with the former, I designed the below prototype for constructing courses (a “teacher” task).

Course design is a teacher’s core professional skill. But implementing the high level design of that course, once the teacher has their vision, is not in itself a very complex task. It involves adding items, and organizing them. In many cases it also involves setting some of the modules’ options, though most of the time the defaults could suffice if chosen well.

Currently the basic workflow is an obstacle. The teacher may need to go into the deeper configuration at will. By default they should not be continuously disoriented from their current task by forcing them through module configuration each time they want to add something to their course.

When I ask people What is a Moodle course, the first idea that pops into most people’s minds is: A big list of documents. Moodle UX should actively demonstrate that this idea does not represent reality, that it is not what Moodle is about. At all.

A major obstacle in the current design are the elements themselves for adding content: the drop down menus for adding “resources” and “activities”. First off, you have to click the menu to see your choices at all. Even then the short phrases in the list do not really give an idea about what the activity in question is good for. When you give it a try, you find yourself not learning the idea of the module, but staring at a long configuration form. The design I propose relies on making choosing an activity more pronounced, and on getting immediate results in the same view – direct manipulation.

A core goal of this design is to make the interaction more direct than it currently is. Long configuration forms may still be required for deviating from the default settings, but in order to allow the teacher keep their sense of context, to “keep them in the flow” so to say, we need to allow the teacher to complete a whole process of high level course design on the course front page, from start to finish. That is why the mockup suggests that simple module configuration (such as creating the question and the answers of a Choice) need to be dialogs on the course editing page, not separate forms. (Only when you want to tweak something, will you go on the actual configuration page.)

This is heavily about emotional design. Instead of making the building of courses – the core value provided by Moodle – a mundane and troublesome “editing” task, bring the affordances of Moodle readily available, and make them exciting. Moodle is all about empowering students through first empowering teachers. Currently Moodle makes that job too much like a “hard technology task” than it really is. It has to be obvious, low-fi design, like what the social web is all about, in the spirit of Everybody is a content creator, and there are no barriers.

Disclaimer: after having finished my Moodle master’s thesis this Autumn, I have been relatively inactive in the community, so many of the above ideas might have already come up. :)

Further details

I believe the challenge of getting teachers to experiment with courses and tools that Moodle provides for them is that we need to make it obvious, but it needs to remain a creative task. For creative tasks, a Wizard (often proposed as a solution for this challenge), easily gets too restrictive.

(Of course, once we get the actual standard UI for doing this right, something to hand-hold total novices will not hurt – if we still think there is a need for that after we get the standard UI right.)

Encouraging teacher creativity – that is, giving teachers a feeling of being empowered – is the reason I think a course should perhaps by default be a blank slate. It may be convenient that the sections are already there, but them already being there also may put teachers in a mindset that they are creating something that must obey Moodle restrictions, that this is a Moodle course and not theirs. If there are sections there already, the implication in the user’s mind can be that those sections are there for a reason, that at least technology novices should not remove them, even though their professional pedagogical vision would contradict that.

Still, it may make sense to have a restriction that course content must exist within sections. It seems banal, but it might make sense to have the first thing a teacher must always do is to add a section to the course. If it is an AJAX functionality (no page load waiting), adding that one mandatory section is not much trouble, and it serves as a first easy task for novices to get a feel that they master the UI and it is not hard. To get them going. In a similar sense, the current default “Weekly outline” should be instant and easy to take into use.

I would like to get to know teachers’ work more by doing a bit of informal contextual inquiry, watching them use different LMS’s in the phase where a course is created, for example, to learn more about the constraints and context of how teachers see course making in reality.

eNrzzU/OLi0o9vIMcqzxzc9PyUnVyy9KrzE0MjYzMTOzMACBGucaXUMALMENBA==

Software engineers often question the value of usability work. It may be that a good designer could design a UI that does not create major confusion for most – if those designers already have lots of experience from usability testing in other projects. However, in any application that is done without explicit user research and usability testing targeted for the specific UI, you tend to have dozens of small confusing moments that make up the overall user experience and lead to a general ‘yuk’ reaction. Not to mention that if you don’t intimately know your users’ goals, you are likely to be designing the wrong overall application.

I owe a big thanks to many, many members of the Moodle community. I am truly grateful to the two professors, Eleni Berki (home) and Saila Ovaska (home), under whose very generous guidance the work took place. Especially Saila seemed to invest a near-infinite number of hours in my work, for which I am still amazed. Their final statement for the work is presented below.

The grade Eximia Cum Laude Approbatur equals 6 on a scale (in Finnish) of 1-7, where 1 is weak and 7 is the highest grade. I have been asked to write an article based on the work, but that will probably have to wait for now.

Update: I have sent a copy of the thesis also to Moodle HQ, as well as to Tim Hunt and to Silvia Calvet, who have supported Moodle usability efforts and my work. Further printed copies are available, tell me if you’re interested.

Update 2: I have been glad to see this has raised plenty interest in Twitter. Thanks everybody for the retweets and the congratulations! You rock! Feedback is very welcome.

Update 3, Nov. 18 2011: This thesis won an honorary mention in the thesis competition (link in Finnish) of the Finnish chapter of SIGCHI ! Yay! Their statement of the thesis: “The jury thought this as a new type of thesis work, which successfully captures the phases and challenges in a multi-phased process of redesigning a Moodle community application. Open source communities have been little investigated from the HCI point of view, and the author successfully opens interesting new viewpoints with the thesis. The constructive Pro Gradu thesis has also resulted a tangible contribution.”

Statement on Olli Savolainen’s thesis for M.Sc. in Interactive Technology titled User experience design in open source development: Approaches to usability work in the Moodle community, 82 pages, 5 appendices

Free/Libre Open Source Software (FLOSS) development has become an important way of producing software in the modern society. In principle, the source code produced as OSS is openly designed, developed and distributed, and developers take part in the process voluntarily. The resulting code is freely or with little cost available to end-users. Often the software developers and users are from all over the globe, with the OSS community applying virtual forums for questions and user feedback and support.

Taking part in OSS projects often poses challenges and obstacles to the usability practitioner whose main interest is to design the user interface so that it better fits the user needs. This is the topic Olli Savolainen deals with in his thesis. He reports on his personal motivation and continuous interest in improving the quality and, in particular, usability of Moodle Quiz. He also refers to his efforts and perseverance in gaining acceptance in the community before the changes he suggested after several iterations finally got accepted into the code base of Moodle 2.0. The description of the project is given on two levels. While reporting on the actual user centered design work done in the various phases of the project, another, more personal account of the challenges encountered on the way and reactions to them is unfolded. This kind of reflection is very valuable for understanding the norms, values and ways of working in FLOSS communities. These are important for gaining acceptance and recognition as an active FLOSS participant.

The thesis is a well balanced and reflective document of things learned and practiced in the Quiz UI project as well as thinking about them in the larger framework of OSS development projects as described in literature. The background literature cited is extensive, ranging from books and journal & conference papers to blog and discussion forum entries and documentation. Furthermore, it is well utilized throughout the thesis.

The vocabulary in the thesis is versatile and the language in general grammatically correct, though professional proof reading and language checking might still improve it. A minor drawback in the thesis is the structure that promotes the feeling of repetition, since some issues are first introduced in Chapter 2, but discussed in more detail in Chapters 7 and 8 with many cross-references between the sections. However, this is only a mark of thoroughness and consistency in reporting.

Olli Savolainen has been involved with Moodle and the Quiz UI for more than three years, and his skills and expertise are apparent in the thesis. The main findings are based on personal work experience, and they smooth the usability practitioners’ path into OSS communities. The thesis work is relevant to future OSS development practitioners. It unites the fields of software engineering and usability engineering, bridging the gap still observed in computer science education.

The work carried out by Olli Savolainen clearly fulfills the standards set for a thesis in Interactive Technology. We propose that the thesis is accepted with the grade eximia cum laude approbatur.

At the department of Computer Sciences, September 9, 2010
Saila Ovaska
Eleni Berki

Grieved over what Navigation 2.0 does to the Quiz editing UI I designed and usability tested in summer 2008 (discussion, tracker item), throwing away much of the tested design without testing the changes (update, later the same day: this is still being discussed; see the tracker item). How I wish I could be there when core moodlers design and decide about big UI-related changes like this Navigation 2.0! (spec for the Quiz change)

• Worked with Eloy, Sam and others to get Moodle’s first proper Wizard in. Yay!  Sam did a great job of reacting to my feedback quite late in the process, though apparently he did not know of the specifications I had made for the wizard last autumn.
• Discussed Database module exporting UI
• Discussed Forum search UI with Anthony
• Commented on The database module’s UI on Anthony’s request – hope to have a chance to do some research and help in redesigning the Database module UI at some point
• Added MediaWiki categories to Moodle UI guidelines for faster browsing, cleaned up the guidelines so unfinished things are less in the way of usage
• In the Moodle sprint, took a look at the toolbar of the rich text editor; reviewed all the comments the question had received since last summer, and created a new patch. Petr told me it is okay to assign the bug to him, as he will be working on the editor before Moodle 2.0 release.
• Commented on issues, such as MDL-6820 MDL-20461,  found on the CANnect Accessibility report by Randall Hansen (MDL-20409)
• Commented on the new Moodle 2.0 Dock navigation’s interactive behaviours: MDL-21529

Also, jotted some usability related bugs down:

• MDL-22393: password recoverz functionality tweak
• MDL-22249: wrong mime type for an image file

Part II to What is a course & the tools for having a great one, with exciting new UI design for an old challenge is coming out at the beginning of June as soon as I can find any free time. Stay tuned!

(Update July 5th: Working on the follow-up article is taking longer than I expected. Bear with me, it is on its way! :)

Inspired by Tomaz’ blog post, I did an informal interview with a business and marketing teacher I know. There are two separate points I want to make about the interview, so this article starts a series of two articles.

I wanted to go thinking on a very general level of what are the tools that can be used for helping individuals learn on a given theme. I will here call the place to do such learning, a course.

The questions I presented:

What constitutes a course?
What are the defining factors; what do you do on a course, how, and why? In other words, we playfully tried to generate a definition of a course.

What kinds of tools can be used in order to facilitate learning of individuals on a course?
Then I asked the interviewee to list the tools that can be used for learning in each aspect of the course’s definition. “Tools” are defined very widely here, as anything that can facilitate learning on the theme. They may sometimes have natural hierarchy, but here I want to perceive them such that each we can each still see the relations differently.

The definition here is of necessity more narrow than that discussed by Tomaz – I believe that restriction helps when thinking about the design of a platform for courses.

The main bullets of the list below are what defines a course. The sub-bullets are tools for reaching the goal/factor of definition in question. Text in italics is my reflection on what a given point could mean to Moodle.

A course (instance) is defined by:

• The defined content learning process of the course – (however loosely “content” is defined); taking into account the gradual learning of an individual in the course. She described one such process she uses to me (below)
  • Schedule (how much more emphasized could it be in the course frontpage UI for a student that there is an explicit schedule for a course?)
  • Teacher/facilitator as the one who defines or facilitates definition of the process and content
  • Learning theory being used
  • “Traditional” teaching methods: lecture, guidance counseling, …
  • Theme discussions
  • Study circle (a specific kind of forum)
  • Course community itself (as a tool for learning)
  • Private discussions for gaining trust between teacher and participant
  • Deadline for returning assignment (as deadlines are seen as something that is defines the course, should they be associated to the course on the UI level so teacher can see all deadlines she has defined at once, in addition to being defined in the module itself?)
  • Student awareness of eventual evaluation
• Community
  • Teacher as facilitator of building common trust
  • Introductory forum, sharing what expertise participant can bring into the community
• Evaluation
  • Guiding/counceling discussion (chat; private messages?)
  • Calculator - could calculator or excel be used as a stronger metaphor in the UI whenever Moodle assists the teacher by calculating grades or when the db module estimates the reliability of a student grade?
  • Exam
  • Peer review (apparently Blackboard does not allow anonymous peer review?)
    
• Learning goals of course: generic learning goals, specific learning goals
• Content - a clearly defined theme
• The external representation of the course: the criteria a student uses for determining if they want to take part on the course
• The intended position of the course in the curriculum: If the course is given as a part of a curriculum, including the prerequisite courses/understanding of student
• In the personal learning process of the student, where does the course fit; i.e. how what is learned in the context of the course fits in the mental model of the student

(I exhausted both myself and the interviewee before getting to the tools for the last parts of the definition.)

The point here is when designing a learning management system, we need to give teachers tools that are needed, in the context of their goals, taking into account their perception/definition of what is a course. The reason for defining a tool so broadly, allowing both very abstract to very concrete tools, is that whatever a teacher uses, is an expression of the teacher’s need in reaching a goal. So anytime a teacher states to use a tool, it is something we can consider as a potential need Moodle can fulfill, one way or another.

She also outlined a content learning process on an online course she has:

1. Before course: Reading assignment of book(s) chosen by participants on the topic, two-page reflection writing assignment
2. Making sure communication channels are open (valid e-mail addresses), clarifying the rules of the course
3. Introduction: members present themselves and the existing knowledge they bring into the community (forum)
4. Questions assignment: Think of two or three questions one should be able to answer after reading the books you read for the first assignment (forum)
5. Based on questions assignment, teacher defines themes that are central to the participants. Participants are asked to give feedback if themes they think are central are missing
6. Teacher creates forums for each theme selected. Teacher asks students to discuss the themes. Teacher may participate herself.
7. Teacher asks students to summarize the discussion in one of the forums with a theme.
8. Assigment to apply the gained learning in a real enterprise
9. Learning diary
10. Feedback form on the course

Here, the principal lesson to learn is that the modules that the teacher requires are not that many, but each time the teacher uses a module they do so in a specific context. It is these contexts Moodle needs to understand if it wants to be distinguished as

• a tool that really supports learning and those facilitating that learning, or
• a pile of tools you can use, if you learn a sufficient number of combinations of arcane settings by heart.

Presets of module settings, intended for a given purpose, labeled according to the pedagogical purpose, is the main means to get there. Instead of/in addition to just allowing the teacher to label a forum according to the pedagogical purpose they want to use it for (“Introductions”), have a Moodle preset module that is exact fit for that user goal.

Of course, knowing what the presets teachers actually need so we can serve, say, 80% of teachers, requires both interviews and ethnographies to really know what most teachers think is meaningful.