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!