Latest Updates: UIpattern RSS

  • Simplifying Moodle forms and adding activities to courses

    December 20th, 2011

    At LUNS Limited they’ve collapsed the Moodle form fieldsets that only contain optional items, in Moodle forms. Without having seen any usability test results or knowing whether they exist, it does seem like an elegant solution at first glance! (Discussion)

    They’ve also used the example of the Quiz Add question dialog (tracker item) we did with Tim for allowing people to add activity modules on the course front page. Originally I actually found this UI pattern in QuestionMark during the user research sessions done for the Quiz UI redesign project – great to see it being put to good use.

    This should make adding activities more straightforward. Yay!

    (Thanks to Helen Foster for the screenshot and to Mary Cooch for the screencast)

    Note to self 2021-06: This could perhaps easily be extended to a variation of command palette.

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

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

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