Latest Updates: UIpattern RSS

  • Course editing

    July 18th, 2009

    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).

    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.

     
  • Progressive disclosure

    June 2nd, 2009

    To have some feedback about my current ideas of how to document guidelines, I created a page about Progressive disclosure on the Moodle Docs wiki. Please comment!

     
  • UI details: two-part drop down menus

    April 23rd, 2009

    “Dual” drop down menus are menus that perform a default action when the menu title is clicked, and only show the actual menu when the down arrow on the right side of the element is clicked. Usually such menus do not communicate clearly that clicking the left side of the element performs the default action, instead of showing the menu. (The expected behaviour is that of traditional drop down menus, which always show the menu whereever one clicks).

    Of course this never constitutes a fatal usability problem, if the default action is reasonable and provides the choices the menu would have on the target page. It only potentially slows down users by one page load. However, when a truly fluid user experience is the aim, details easily become a differentiating factor compared to other similar products. Today I noticed a solution for “dual” drop down menus that is aesthetically subtle and still seems to efficiently communicate the functionality available.

    screenshot 1: menu bar in default state

    Delicious has what looks like a pretty standard (and plain) menu bar.

    screenshot 2: mouse on the main link

    However, when you hover the mouse over either the menu title or the down arrow (of the ‘People’ menu in this case), the corresponding side of the element is highlit.

    screenshot 3: mouse on the menu arrow

    This effect would not be achieved if either side were highlit already. The point is that the UI gives a subtle hint to the user as a reaction to their action. The user understands almost seamlessly the fact that the element that seemed to be just one menu actually behaves differently depending on where on it you click. (This was my experience, anyway.)

     
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