Updates from July, 2009

  • Course editing

    July 18th, 2009

    Note: this thinking continues from another angle in What is a course & the tools for having a great one (Part 2).

    Addition May 2010: Note that the solution presented here is problematic with touch screens where there is no mouse hover so the UI can not be activated.

    Wondering about various switch controls and how to give guidelines for their use, I ended up designing an alternative UI for editing the course page (discussion and related cross post). Addition Jan 30 2011: the screenshot image is so hard to view in a useful size in the new version of Moodle Tracker that I am posting this here – also the shoes version seems to have broken over time.

    Click to enlarge
    Prototype for course editing

    As the plans to usability test a part of Moodle as a part of this project have not become reality as easily as I hoped, I was wondering if testing this idea would take on. So I needed a prototype, and then I remembered Shoes, which I had hoped to try out. It seemed like a toolkit to build something pretty quickly.

    I needed something to tinker with in midst of my flu since I could not do anything very intensive, so I started playing. And now I have something of a prototype. And it works out of the box in Windows, Linux and OS X. \o/ Plus, I have learned a bit of Ruby, though umh, in a somewhat unorthodox manner. Including tweaking, all this took me a couple hours of coding during three days, plus a fourth day to start learning the thing.

    I am not sure how to combine object-oriented programming with Shoes’ way of outputting things, to iterate over the code, so I only have one ‘resource’ so far. I will have to figure out how to fix that.  An upside is that he code is so ugly and unmaintainable that hopefully no one would ever consider growing production software out of a quick prototype built with that…

    I am so exhausted. Next: staring at the ceiling for about 36 hours.

     
  • The power of simply having data

    July 6th, 2009

    From Contextual Design by Hugh Beyer and Karen Holtzblatt:

    […] Any change is a struggle. Engineers used to making what they are interested in feel constrained by having to think about what is useful and can sell. We all have to hold back the voice that tells us that producing code is progress – even if we cancel the project, even if it is the wrong code, even if we don’t know what would be useful to code. How does understanding work produce code? It is a struggle of personalities as we try to work in cross-functional teams to produce a shared direction. It is hard to remember that one smart guy working alone probably doesn’t have the whole answer. We simply have to realize that design is about people working together, and that’s what makes it hard.

    I remember the first design team I worked with. I barely knew what a computer was, but I jumped in to help a team designing a very large and expensive computer. They were stuck, not on the guts of the engine, but on the control panel! So I listened to six engineers arguing about how to lay out the switches: “Won’t we crash the system by accident if the remote selection is on the same switch as off?” “Oh, they’ll only do that once.” And whether or not there should be a key on the switch: “Security is important.” “No, it isn’t.” “Yes, it is.”

    As I listened, I realized that the team simply had no ground for their decisions. There was no way that reasoning and argument would get them to an answer. So I collected some data on how the panel was used: “Are you kidding? We won’t touch the remote. Someone might crash it.” “We turn the knob very, very slowly.” “Someone crashed it once, and the whole business stopped. No one touches that knob now.” And on security: “The computer is in a locked room; we don’t need it locked.” “Locking is a pain. We keep losing the key.” “We keep the key taped to the computer so we can find it.” “I catch my clothes on that lock; it sticks out.” The design was done in a day. We had a new switch for on and of and stopped agonizing about the key. I recently ran into a member of that team. He said he still talks about what happened 10 years later. The power of simply having data.

    Emphases and paragraph division (partially) mine.

     
  • Paintweb + comment gathering

    July 3rd, 2009

    On Monday, I published the current form of the guidelines and asked for comments. Otherwise, this week was spent working on my master’s thesis (about Moodle & open source usability). It is going forward surprisingly well. Fitzgerald in The Transformation of Open Source Software (PDF, 268 KB) talks about OSS 2.0. I thought that the fact that Moodle is a vertical domain application and shares also other properties of OSS 2.0 seems to explain why usability work with Moodle is quite different from usability work with more traditional F/OSS applications.

    Today, I also made some mockups to suggest some new designs to Mihai’s Paintweb, the upcoming drawing tool for Moodle 2.0 I am very excited about.

     
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