Latest Updates: Media RSS

  • Project Accepted: Moodle User Experience consistency

    April 22nd, 2009

    Yay! I am happy to announce that I will continue to work on what I love to, Moodle usability, during Summer 2009 (in Google Summer of Code this time). The goals of this Summer include getting the community more engaged thinking about the user’s experience (ideas welcome) while developing, creating UI guidelines for that, and of course, evaluating and fixing consistency problems in Moodle. See also: Project documentation.

    This blog will be used to report the progress of the work during the Summer and for general thoughts about usability in open source – which is the subject I am currently also writing my Master’s thesis on.

    Next: Adding this to Planet SoC.

  • Fixes and Openmind

    October 4th, 2008

    A month has passed in Metz, France. I have had progress with the Quiz UI also, lots of discussion has taken place and I have many ideas for the forthcoming thesis. Some serious bugs have been fixed and what is left – in addition to integrating everything in Moodle 2.0 – has been gathered into one development document in the docs.

    Openmind is approaching and I will take part via a Youtube video, since it is hard to participate otherwise from another country. I will post the link to the video here as soon as it is public.

  • Video posting... Call for help: In pursuit of scenarios

    June 16th, 2008

    Published this on Saturday in the Quiz forum.

    For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task independent of how they would complete it within the application.

  • Scenarios, Use Cases, Jazz

    June 9th, 2008

    Yesterday, I started to grasp more comprehensively the relationship between personas, use cases and scenarios.

    While trying to piece this together, I drew what used to be a simple diagram. But then it got a bit out of hand:

    The reality and the dynamics a UI designer observes and manipulates

    Download diagram: PDF, Openoffice ODG

    First off, there’s reality. That is to say, this is not scientific research. In a small scale guerilla usability project, we do not pretend it is, much. Still, we observe reality and gather knowledge about the users. Iteration in testing and also in interviews must serve as our backup against which we check that our conclusions are hitting their target: we take the knowledge we find to the user interface and to our generalized conclusions, and then verify with our users.

    Use cases

    In a sense, modeling use cases equals doing actual UI design: the main difference is in the abstraction level. Use cases will be the actual hard ground when drawing prototypes, representing the idea or ideal about what the UI should be like. That is, what should be possible to accomplish with it, and how.

    When designing the actual user interface, the designer takes all the use cases (=the goals), and merges them using his/her creativity and experience. As the use cases may conflict, the resulting user interface is usually some sort of a compromise between the different use cases. Also platform restrictions pose threats to the ideals: technology requirements (no dependency on Javascript in this case) and needing to conform to existing UI conventions would be examples of this.

    In the case of this project, I have so far been thinking about the word “use cases” mainly from the point of view of the old user interface – I have understood it roughly as the functionality of the UI, which is to be transferred to the new UI, just better enabling the users’ scenarios (better enabling users to do their tasks). However, this is actually an overly computer-centric approach to use cases, and basically incorrect. More importantly, as is obvious in terms of the definition, use cases take the functionality of the program and model the user in interaction with that functionality.

    There are several ways to see use cases. First, when we look at the current UI, you can see three different sets of use cases, from ideals to reality:

    • ideal use cases: how the software developers think the software should be interacted with
    • observed use cases: gathered by seeing real users (UI testing or otherwise) use the current UI. This is a subset of the next one:
    • the real-world use cases of the interaction that is taking place with real users and the current UI


    When we just have the use cases of existing software, we do not get very far. At best, with testing, we see the problems users are having with the current software. What we do not see, is whether or not we are even trying to solve the right problems.

    Enter scenarios. That is: independent of the application and its UI, what is it that the user aims to achieve, and what is the way s/he does it best?

    How do we find out? Talk to the users. It may be scary at first. They are people, after all! But go ahead and try – turns out that people are actually glad if someone wants to learn about what they need to make their lives easier.

    Whenever you talk with actual users about their actual tasks and goals, you are in the sphere of scenarios. But the hard part is taking the scenarios and making them somehow digestible pieces. That is: you look at what the users tell you, and tear it in pieces until they are atomary, that is, single actions (you might want to observe this in terms of GTD’s Next Actions: visible, physical actions). It is not just the tasks you need to find out about, but what affects accomplishing those tasks: patterns, goals, skills, attitudes, and environment (as stated in Cooper’s article about personas, link below).

    Getting somewhere

    So now we have a set of use cases from the old software. Then we have a set of scenarios describing the actual environment, tasks and goals of the user. Now, we try to match them: scenario 1a fits with use case 1c, and actually, also with use case 1d (that is, the user can do the same thing in more than one way in the application). But then with scenario 1b, the user has to do a task in an unnatural order of subtasks or can’t do it at all because it is too hard for him/her or because it cannot be done at all.

    And once we get that far, we can take those differences, and start writing new use cases. That is, designing the interaction that the application should facilitate. Once sufficient iteration has been achieved or the deadlines are too close, we can state: We know – well enough – the interaction and whatever affects what that interaction should be like – now let’s get to business, the actual UI.

    Oh yeah, almost forgot – something brilliant: Perfecting Your Personas

  • Scenarios documenting

    June 7th, 2008

    This week, I have been working on the scenarios. Today, added a new project page to Docs and created new pages there for each of the major scenarios, filling in details of the scenarios according to the different personas. The pages are still far from complete but can soon serve as basis for hopefully rich community discussion.

  • Meeting the Finnish Moodle users

    April 9th, 2008

    On Monday, April 7th I was in the Spring meeting of Moodle käyttäjärinki, which consists of Finnish Moodle users and administrations from universities around the country. I presented the project briefly (without having told them anything about myself before the meeting) and requested contacts so that I could have real users to talk with, and usability testing subjects once I have a working prototype. Three people contacted me immediately and I got a recommendation to ask the ITPEDA network/list, as well.

    There was plenty of discussion about other Moodle topics, such as administration and localization. I think I will post about those to the Moodle forums at some point – I’ll notify about this here.

    Also, added some of the project introductory text as pages on this site, see under “Pages” on the right ->.

    Also, I’ve started to get a grip of Getting Things Done using ThinkingRock, which, erm, rocks. What this means for the project? A more organized project leader is more probable to stay sane ;).

  • Media visibility

    April 5th, 2008

    The COSS Summer coders were yesterday visible in the Finnish web media:

    Also, I added links to the blogs of the other kesäkoders on the right-hand sidebar, as well as plenty of links to other places related to the project.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top