Latest Updates: Moodle RSS

  • 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!

     
  • Making UI conclusions from user data

    May 29th, 2009

    This spring, I got interested in another Google Summer of Code project on Moodle: Mihai Şucan’s painting tool. It is interesting also because Mihai understands usability, too, and I have been happy to push him a bit towards doing a bit of user research. Today I commented on the answers he got (if you don’t have a Moodle.org username, click ‘Login as guest’) when he asked teachers in the community about their potential uses for a painting tool.

    And I am enjoying every bit of it since it also helps me think through user-centric design processes in my mind.

     
  • Dimensions of the Consistent UI Guidelines project

    May 27th, 2009

    After having had a chat with Helen yesterday, I recalled the importance of simple writing. I have a rather complex message which I want to make a lot of people understand: I am not just making usability recommendations to specific parts of Moodle, but trying to see patterns in the way UI’s are made and to make recommendations about those patterns.

    Later in the evening I got the idea that even though the job itself is quite well narrowed down at the moment, it still happens on quite a few dimensions, and keeping track of the different things happening on different dimensions might be the real challenge here.

    I have prioritised the dimensions (goals) here (the first the in list has the hightest priority), to give a rough idea of what will be given less attention to, in case my head starts feeling like it’s gonna blow up. (The links are to appropriate phases in the project schedule)

    1. Engaging the community. Giving them something to play with. Finding common ground. Providing services to different UI design projects within Moodle. Community discussion
    2. Writing for lightness. Making the guidelines clear, light, usable: fit for their purpose. This is critical for building engagement. Catalogue (but writing really happens throughout the project)
    3. Planning. Project management, project documentation – kind of a prerequisite for my sanity and thus, for everything else. Planning
    4. Exploring Moodle‘s functionality. There is a lot of work here for me, in both learning the UI and narrowing down what is relevant for this first round of HIG creating. Examine, Catalogue
    5. Usability tests (design, organizing to get some people to test with, usability testing) Planning usability testing, Usability testing
    6. Creating tickets for changes in tracker, implementation of  changes. Implement

    Also, I am kind of wondering about the name for the guidelines themselves. How does Consistent UI Guidelines sound to you? Seems more comprehensible to me than HIG, which is comprehensible mostly just to usability folks.

     
  • Project schedule, summer 2009

    May 26th, 2009

    As a part of the Moodle usability effort of summer 2009, I have now published a detailed project plan for the project in the Moodle Docs wiki. Comments welcome. It feels good to be in control.

    Also amused myself on Sunday (my day off) by creating this little ad, which will probably never appear anywhere else but here, now (since it is too distractive to be even here). It is the first APNG animation I ever created and should work on any decent new browser – and show just the first frame on older ones. I created the file with APNG Editor, a Firefox extension. (More …)

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel