Latest Updates: Background ideas RSS

  • Social usability

    February 13th, 2010

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

    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.

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

     
  • Usability and Users' experiences in Moodleland @ iMoot 2010

    February 7th, 2010

    Preparing for presenting in iMoot, an online conference about online learning and Moodle, was an intensive process for me, but it paid off –  both in terms of learning while designing it, and because many of the presentations were really inspiring.

    Martin’s keynote also inspired me to create a small bug report in the tracker, my first one in months.

    #imoot2010 Twitter channel

    If you are interested, you can still register now for access to ALL the conference presentations, and today you can still join the discussions for a couple of hours.

    Usability and Users’ Experiences in Moodleland

    Quotations in the presentation:

     
  • The fruits of the summer

    August 17th, 2009

    Summary of the Summer of Code

    Related forum thread

    For me, this summer has been full of small and bigger openings. I have gotten overwhelmed, figured out why, and organized my thoughts about Moodle development and usability time and time again. I have found a lot of new, relevant questions and understand much more about the challenge that is Moodle usability, and more broadly, Moodle user experience.

    The main outcome of the project, Moodle User Interface Guidelines, got off to a good start, and I believe it will serve as a useful reference in the development of current and future user interfaces.

    At the end of the project, I did some brief usability testing (contrary to what I believed in the previous post) which shed light on the Login/Forgotten password form and on the File picker for the rich text editor (see below). I will write more about these very guerilla-style usability tests later. The code produced is in the linked tracker items of MDL-19586.

    notet
    tärkeät parannusta kaipaavat alueet

    I have interacted with the community a lot in the forums, on Jabber channels and in the tracker (see below). Still, the actual guidelines never got as much attention from the community as I planned, so this work continues. Time did not seem ripe for many of the guidelines I planned for. And honestly, I did not spend as much time writing some guidelines I perhaps could have. In the end, I decided to concentrate on what was important at a given time. Sometimes it was a specific UI that needed a gentle touch, or an UI element, and sometimes broader issues were discussed.

    Tim Hunt, who has acted as my mentor just like last summer, has been available to comment on anything I needed to discuss.  This summer he has given me some great advice especially about interacting with the community. Some of it seemed, ehm, too good since it made me feel pretty humble.

    Opening my eyes

    The issue seemed to be that there were not many elements in Moodle that could directly be made into guidelines. In the last post, I outlined various ways that a guideline can get born. With Moodle at the moment, way too many of those were just things there was a need with but nothing tangible existed. As there was nothing implemented that could be written about, often the first step was to talk about a given subject in the forum, to get people to think about whether this thing X, that could later become a real guideline, should be taken into account (keeping user data safe, wizards).

    On the other hand, I also felt the profile for usability in Moodle needed to improve. So I offered design services to some current development efforts taking place (course backuphelp tooltipspaint tool, file picker/uploader for TinyMCE). My hope was that I could show developers what kind of a contribution a usability practitioner could give into the software development, and make developers start to expect someone to be available for the kinds of questions UI/UX design raises.

    With the current understanding of the status of Moodle’s usability and how things are developed in the community, the next logical step seems to be comprehensive usability testing of the overall UI model of Moodle. Only after this we will understand just what exactly is in need of the most work. This requires first determining what use each part of Moodle is intended for – some sort of use cases and usage scenarios – in order to create test tasks. I know this sort of understanding exists in the community: the applications are created with the users’ needs in mind, to a degree.

    But the knowledge needs to be extracted and documented. If I have to squeeze it out of certain Mr. Dougiamas’ head… well, just kidding. We need to listen to everybody in the community, but we (I?) also need to understand better just where the understanding about users comes from, and how it is being used. It seems to me that at the moment, much of this is never explicitly discussed in the community.

    Based on testing and user research, creating a strong UI style/language for Moodle will later also help further develop the UI guidelines, since there will then be something substantial to document.

    I have also gathered a list of Major Usability Issues in Moodle that can be addressed in future projects. This is just a start, but it seems to me that bigger usability challenges need to be tracked, documented and discussed, than what can be done in tracker tickets about individual issues.  I am not sure about the tracker’s suitability for this.

    Efforts initiated

    The efforts I participated in

    Discussions we had

    Forum threads I found valuable to Moodle usability:

    (More …)

     
  • The flow of life for a user interface guideline

    August 4th, 2009

    The flu that started somewhere around July 14th got several diagnoses and finally seems to have gone away pretty much completely. There are two weeks left of GSoC. This week, I will go through the notes I have gathered during UI inspection. I will create some further UI guidelines and bug reports of all the individual issues I have found. Next week, I will implement some of the changes I am suggesting as patches to Moodle 2.0. Before catching my flu I was thinking about the exact process of determining an interaction style for an application such as Moodle. This starts from the assumption UI elements (and interaction style)s of the application have been discovered and documented, like I have done this summer.
    Workflow diagram about the phases of creating an UI guideline
    For each UI element discovered, there are three options: If the element is determined good, keep it and document it as a guideline. In some cases there are two elements for the same purpose and the better one of these can be used and the other one replaced. Otherwise, the element in question may have to be changed, or replaced with a new element. The issues involved must be carefully considered.

    • It may be discovered here that issues are so serious or such big changes are required, that they require a project of their own to be solved (consisting of further research, design, and testing).
    • In other cases, it may be possible to  make enhancements or replace the element in question with a proven solution, which means only shorter period research, discussion and finally usability testing is required.

    In the current project, I intended to do even usability testing with the elements that I discover. However, I have ended up mainly doing research of what there is and determining what should be the next step in developing each element. To understand why usability testing was not the Thing to Do™ at this point, stay tuned!

     
  • 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 …)

     
  • UI details: two-part drop down menus

    April 23rd, 2009

    “Dual” drop down menus are menus that perform a default action when the menu title is clicked, and only show the actual menu when the down arrow on the right side of the element is clicked. Usually such menus do not communicate clearly that clicking the left side of the element performs the default action, instead of showing the menu. (The expected behaviour is that of traditional drop down menus, which always show the menu whereever one clicks).

    Of course this never constitutes a fatal usability problem, if the default action is reasonable and provides the choices the menu would have on the target page. It only potentially slows down users by one page load. However, when a truly fluid user experience is the aim, details easily become a differentiating factor compared to other similar products. Today I noticed a solution for “dual” drop down menus that is aesthetically subtle and still seems to efficiently communicate the functionality available.

    screenshot 1: menu bar in default state

    Delicious has what looks like a pretty standard (and plain) menu bar.

    screenshot 2: mouse on the main link

    However, when you hover the mouse over either the menu title or the down arrow (of the ‘People’ menu in this case), the corresponding side of the element is highlit.

    screenshot 3: mouse on the menu arrow

    This effect would not be achieved if either side were highlit already. The point is that the UI gives a subtle hint to the user as a reaction to their action. The user understands almost seamlessly the fact that the element that seemed to be just one menu actually behaves differently depending on where on it you click. (This was my experience, anyway.)

     
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