Latest Updates: Strategy 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.)

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

     
  • Status

    September 1st, 2008

    August has passed, but work continues. I am leaving for Metz, France tomorrow to live there for 9 to 10 months, and the Kesäkoodi final report for the project will have to wait at least for some days – we will see about how easy it will be to get an Internet connection. At least there’s wifi on the campus, I hear.

    The usability report of Moodle Quiz UI’s direction in the future has not gotten any discussion. I only mentioned it in one forum posting though so that is understandable. I will have to promote it further once I have time again, to really get the community thinking about the issues that came up in the usability testing, which were, after all, rather primitive.

    This software did benefit from this summer’s work, but it is far from good in terms of usability yet.

     
  • Status update

    August 4th, 2008

    As a result of a change of plans, I started to implement the reordering tab last week. That is: I decided to implement all the functionality before doing usability testing with the actual application. This was due to the fact that it was not easy enough to get teachers as usability test subjects during July. Instead of hunting, I decided to put my energy into implementation.

    Thus, the question ordering/paging tab is well underway and will, if all goes well, be finished by next week.

    The feedback from the Moodle community about the demo published last week has been very positive, though I have gotten some very interesting development ideas, too. So that is something to be glad about! :)

     
  • Coding and management

    July 2nd, 2008

    It is somehow frustrating to use precious coding time in project management, but today I did and I am glad. Found many gems from my notes that I would have been sorry if I had found out them too late when actual development would have been done too far.

    Last Saturday, I published the final spec with screenshots of the tested UI. Though everybody seems to be on holiday, I got some comments about it, too. Implementation is going on in the tracker, which is the main means of following development at this point, as well as the development section of the project portal for the bleeding edge developments.

    Also the prototype testing report and details have been online for about a week now.

     
  • Prototypicalifragiolistic

    June 19th, 2008

    The discussion about scenarios has gotten into a nice-ish start. I also published some details about how the scenarios interviews were done. Although I will try to take into account all the feedback from that background data, it does seem quite far from concrete use cases or the UI. The work I am doing just on two – although quite complex – screens, still mostly seems too simple to be affected much by the high-level differences between the personas, though some changes have been made based on them, too.

    Nevertheless, I have been working on the prototype again, for the most part making fixes based on the usability tests done on May 28th and 29th. I will probably do some rather quick&spontaneous prototype testing with basically anybody I can get my hands on, not to prove anymore the UI suits the tasks of teachers, but more trying to make sure the functionality is understandable, in accordance with the ideas presented about discount usability testing in Don’t make me think by Steve Krug. After that I will publish the final OOo Impress prototype.

    The different areas of focus in the actual implementation and coding work are envisioned to be as follows. Note that most functionality is already present in the current Quiz – this is UI work, after all.

    (What was here was moved to the Implementation plan page.)

     
  • Progress! Ah, progress!

    June 10th, 2008

    Still working on the scenarios. I would not have thought it can be such a handful.

    However: slowly, but surely, I am starting to get them pretty simple and easy-to-read. Maybe someone else will bother to read them and perhaps, just perhaps even understand them enough to discuss them in the Moodle forums!

    From the interviews, I have at least some data about the entire quiz creating process. However, I am going to try to just concentrate on the parts of Quiz that are relevant to creating quizzes, and then move on. That is the focus of this project, after all, plus extracting data into scenarios is a lot of work, and time is sparse.

     
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