Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (Minor) There was a small bug where we didn't have the correct information in the header bar (i.e. a section was blank)
    • We already fixed this with a quick patch.
  • (Major) Users were much slower on the mobile version. This is a concern, especially since the primary goals of the mobile interface were convenience and efficiency.
    • We should label assignments with both the color and name of the class.
    • Really old assignments could be moved to the bottom of the list in order to show more recent ones.
  • (Minor) "Shared" may be confusing without the prompting of the usability test.
    • We could replace the "Shared" check-box with a radio button between "Private" and "Public."
  • (Cosmetic) The colors chosen are sometimes too similar.
    • One approach would be to allow users to choose their own colors.
    • We could also create a more sophisticated algorithm for choosing distinct colors.

Reflection

During our the iterative design and implementation process, we arrived came to some conclusions tht that can be generalized and may be generalized useful for future projects.

First, although obvious in retrospect, users do not always use the interface as originally intended. We observed this during paper prototyping, as when users repeatedly clicked would click on a class name whenever when we asked them to add create an assignment. We decided to embrace it, and this shortcut was implemented in our final design.

Second, before adding UI niceties that may require deviating effects that are not included with the used framework, or that deviate from conventional web applications, it is worth assessing their real needevaluating how much value they really add to the interface. In the time we spent to implement implementing live validation, it would be possible to implement several other features.

Third, it is worth mentioning that most problems identified during heuristic evaluation were actually implementation faults; this is an indication that most major design problems were probably filtered out during in earlier paper prototyping sessions - which is good, since as we have seen they tend to be much cheaperare faster and cheaper.

Finally, we observed that users have come to expect that they can experiment with the interface without having irreversible consequences. We frequently saw users clicking everywhere when they were stuck with the task at hand, and they really got angry when it lead to some consequence that could not be easily reversed.