Latest Updates: modelling RSS

  • Master's thesis about Moodle and open source usability work

    September 30th, 2010

    A couple of weeks ago, my master’s thesis was approved, titled User experience design in open source development: Approaches to usability work in the Moodle community (PDF). The work documents usability work that happened for Moodle 2.0, so it was published just in time before that will finally get out. :)

    Summary of reactions: >60 Twitter tweets total including all links, grade Eximia Cum Laude Approbatur, honorary mention in the thesis competition (link in Finnish) of ACM SIGCHI Finland. The work continues!

    Update (Nov. 18 2011): This thesis won an honorary mention in the thesis competition (links 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


    (More …)

  • What is a course & the tools for having a great one (Part 1)

    May 11th, 2010

    See also: Part 2 – a design proposition for Moodle course front page

    (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.

    (More …)

  • Social usability

    February 13th, 2010

    After the last iMoot session I had, I was chatting with Silvia Calvet about usability and its social nature.1

    During the iMoot conference I also got a couple of precious chances to hear about different community members’ usability efforts within their organisations. Turns out there are a bunch of people already doing usability related to Moodle, mostly inside their organizations. Even more people are interested, but the environment to discuss usability in the context of Moodle does not exist.

    We need an environment where community members can make their usability efforts visible to the rest of the community:

    • A place where people are encouraged to brag about what they have done for usability in their organisation, and to share what has been learned (usability test tasks, results, …).
    • A site that could propose you directions to take with usability: give instructions interactively for usability testing, for instance.
    • A corner in the community to chat in about usability, where you could share your frustrations with Moodle, and with doing usability work, and with usability issues in general.

    Another aspect of this effort would be to visualize actual concrete usability data about Moodle.

    • Have a hierarchy on the site for the high level to low level goals, and for red routes of the Moodle UI (of course, these need to be defined first).
    • Allow people to link user interfaces (cvs/git), tracker issues and usability tests (containing test tasks and results) into these goals, although keeping the user goals as the starting point for everything.

    The slogan? How about… We are all about the goals of the learners!

    The magic I want to make happen: make usability visible socially since it is, at its foundation, a phenomenon of social artifacts. Engineers are creating artifacts to users, when they would be better off with other kinds of artifacts. If we can make this disrepancy obvious in the community’s social sphere, there would perhaps no longer be a need to try to convince software engineers of the concrete need for the work. As it is currently, it seems many perceive usability as something too abstract and distant for them to actually do something about it.

    Before any of this though, I believe the first milestone is to do usability testing to determine the current level of usability. This is to set measurable goals for Moodle usability, and to prioritize the things a given part of Moodle is primarily intended for. The fun thing about the above vision is that it is easy to start small: first start filling in data for one activity module while it is usability tested, and then build on the vision I am proposing here, as we go. Even if we end up just creating a site for documenting Moodle’s current level of usability (as a side effect of doing usability testing), it is still worth it.

    1. Silvia is someone who has since summer encouraged me in work with Moodle in a great deal. She is working for CVA, a Moodle partner, herself and we also met in EuroIA09 in Copenhagen to discuss where to take Moodle’s usability efforts. []
  • Modelling concepts

    September 8th, 2009

    I am currently starting out on a course of conceptual modelling. One interesting phrase from the lecturer’s mouth caught my attention, while he was presenting an old diagram of  the concepts of a particular target domain to us. The idea was roughly this:

    Once the concepts have been defined like this, the rest is implementation.

    Software engineers are indeed aware of the fact that we must understand what are the concepts of the target domain, and their relationships. (They may express this understanding in different terms, though.) When we do, we can turn them into programming constructs, be they classes and objects, or procedural code (in Moodle, PHP pages and functions).

    What is missing from this image? The people using the system: the actual dynamics of what happens, the characteristics and the goals of the users (?), and the circumstances of the users. All of these are more abstract than implementation details and can not be described using programming code, yet taking or not taking them into account can dramatically affect whether software meets the actual needs of the people it is supposed to serve.

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