Updates from August, 2009

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

  • Plan & design

    May 2nd, 2008

    The discussion about the upcoming second prototype is heating up in the forums (alright alright, not that much yet :D). Otherwise, I have been contacting teachers, currently mostly from Haaga-Helia since they have been the most active, and trying to determine what to ask them once we get there next week.

    Yes, the first interviews have been scheduled plus a usability teacher from my university, Saila Ovaska, agreed to review my plans before that. Last week’s chat with Ivar Ekman, a fellow CS student at the uni, has proved fruitful, opening my eyes to a set of issues I will still need to address.

    I will probably post a new project plan at some point soon, too, taking into account that I have begun working on this already, contrary to the original plans.

    Somehow I wish the process was even more transparent than it is now. I am not sure how to do that. I was inspired by Nielsen’s Guerilla HCI. How low could we take the barrier to usability work?

    I feel that for me, learning about what to do in a project like this has been hard enough and I am still trying to learn more: having a concrete example about how a project like this should proceed, I dream, might help others to get a grip of practical open source usability. I would like to publish the interview material here, but the problem is that if my interviewees see the material beforehand, will it affect the actual interviews?

    UPDATE: I am excited about the other discussion I found just now that is gaining momentum in the forums! This will be good :).

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