Updates from June, 2009

  • Usability discussions

    June 30th, 2009

    There was a bit of discussion related to Tim Hunt’s last week post about what really matters in Moodle development. The answer is, the users’ educational needs matter. I was excited to see these thoughts. It seems to indicate that the overall user experience is starting to get taken into account the Moodle community.

    Then, someone raised the question in the developer forums: “Why open source software usability tends to suck” – how do we work around this? That thread includes my reply to both Tim’s post and the questions raised by Matt Gibson.

    As a sidenote: For a moment, I have switched over to the “dark side” – I am trying out MS Word 2007, and I still can’t help admiring the UI. Even the colour theme adds up to create a peaceful writing environment where I can concentrate on what’s important – my writing – arguably better than in any other word processor. If only I could stop drooling at the UI and start writing… ;)

    I noticed that this thing incorporates a complete blogging client, too, neatly integrated into the UI without adding any clutter – a feat requiring sophisticated understanding of the users’ needs in itself. Maybe Microsoft is learning something…? It didn’t even add any garbage “msHTML” in the postings. It seems to have added line breaks in the final post though they are not visible in Word.

  • Pattern literature

    June 25th, 2009

    Yesterday, I read A Pattern Language for Pattern Writing, which Tim Hunt recommended earlier. It was really good, and though it was at first dry, the need I had – producing Moodle user interface guidelines – kept me motivated. The book itself uses the patterns it presents – this was confusing at start. But as I read on, it seemed to work and both the form of the book and the content contributed to help understand the same substance. Although the patterns of the book are for creating software (programming) patterns, it seems to me that mostly they may be good for also UI guidelines. Other HIGs seem to have way less form and more prose, though.

    Too bad it was written in book style as a single web page. As it still had the website’s navigation, I had to copy just the text content to a word processor, format the text, add a table of contents and print it to read it. Hm, maybe I should make the guidelines I am making easily printable as one document? Not the first priority though. It makes me wonder if the guidelines themselves are appropriate for the web if they were designed for print. I am planning to think about the form of the guidelines for the rest of the week and then present examples and my core ideas to the community on Monday.

    Also found Lazarus while searching for a solution to the frustration caused by various web forms losing my data. Either this sort of functionality should be integrated to all browsers, or most web apps should be WAY more careful not to lose user data. I am writing a guideline for Moodle for various Moodle scenario specific ways to avoid users getting any more paranoid about their data than they are already.

  • Inline help

    June 18th, 2009

    I could not find a ready-made implementation of YUI javascript inline help online, so I created one.

    Moodle uses just popups for the integrated help. They are relatively easy to find since those question mark icons are all over the UI. But they still take the user somewhat out of the context of the application. Less experienced users are typically confused with new windows opening. It is also incredibly slow to open a new window in many browsers.

    So I am thinking of proposing inline help as a part of the guidelines produced this summer. Mainly to entertain myself and to see how many interaction details there are to take into account, I made a demo that uses the YUI javascript library to achieve this. Actually, the second example is not inline help at all, but a YUI Panel which sits on top of the content.

    I believe popups are still required in Moodle when it comes to more lengthy help texts. The inline help can not replace a popup window when there is no space in the UI for it, but an YUI panel perhaps could.

  • Finding main scenarios, wondering about Roles

    June 16th, 2009

    Got plenty of feedback on the prototype guideline I posted two weeks ago, and things are advancing on that front. I am about to create a template guideline that explains the format of a guideline so it will be easier to comment on without getting tangled up in the actual content.

    Much of this week will still be going through the different parts of Moodle, reading books, and prioritizing different interaction styles. Also, I need to be moving towards figuring out a format for guidelines that can then be finally commented by the community. I am also reading Using Moodle and gathering usage scenarios from there.

    As I was reading through the Roles system part, I got a bit of an inspiration.  Not really grasping the UI issue with roles has been bugging me for months, so it was enjoyable to finally see on some level what the problems are about. Essentially it seems communicating the system effectively requires a richer tool in terms of interaction, using which users can graphically put in place the permissions they want.

    An initial reaction was that my suggestion is too radical for now. In a sense, I am glad that the implementation challenges are aknowledged. On the other hand, from the point of view of the role I assume in Moodle, I want to look at the overall issues there are in the interaction model: What is it that we are supposed to communicate between the system and the user, and how did we do: does the user understand the communication, how much time does learning to understand the communication take?

    For me, one great challenge of the OSS developer community is that thoughts about design are deeply intertwined with thoughts about implementation. Of course we need to be realistic, but we need to do that also in terms of how well actual users will understand what we create. The ultimate hard reality we face is not the technology constraints, since technology is just a means – reality hits us in the face when we see users struggle with the product of our own ingeniosity.

    In open source, there is the risk of hurrying to code away after a need has been recognized – design is done, but it has to do only with software architecture and requirements. The intermediate thinking about what the experience of using the software should look like seems to often stay shallow. I would love to see, in the long run, that design move to early in the development process, like any HCI professional in the industry will require: this is the only way to create really satisfying user experiences.

    With roles, the conceptual system is solid, meaning that the different use cases have been recognized and likely much that users need can be done using the system. But as the complexity of the system is significant, the difficulty of using the UI approaches using a programming language: users have to translate what they need into the language of the computer system they are using.

    Software developers are happy with complex systems, which they need to learn to be capable of using their power. With the roles system, it seems to have been assumed that since that conceptual system is what is required to express fulfilling the requirements systematically, we just need to design an UI on top of that system. Users then need to grasp that conceptual system to get the power they want. The concrete use cases and the language involved are abstracted away in the process (unlike in Moodle pre-1.7, though the old presets are still available), and so a new language for the users to learn is created. The interaction design is derived from that language, glued on top of it, resulting in a user interface that is essentially alien to users, requiring quite a bit of commitment.

    The question that forms in my head is very similar to the one that initiated Quiz UI redesign: how to let users get from their needs, expressed in their own concepts, to meeting those needs with Moodle, as painlessly as possible, minimising extra burden from the system’s intricacies?

    My proposition for a solution, so far is in the Moodle Docs. In addition, really bringing the most probable use cases back to the UI as something like presets would be ideal. Of course there is no concrete UI design yet, but seeing the complexity of the logic of the software and the variety of needs it tries to serve is a good start.

  • Progressive disclosure

    June 2nd, 2009

    To have some feedback about my current ideas of how to document guidelines, I created a page about Progressive disclosure on the Moodle Docs wiki. Please comment!

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