Updates from August, 2011

  • Dangers of modal user interfaces

    August 27th, 2011

    This was Republished and updated at Medium

    Modes can be dangerous in a user interface, especially if the UI does not make the modes and their states clearly visible. This is often heard advice about UI design. I collected snippets of this advice/heuristics here.

    If you have a different point of view or know scientific articles or textbooks that further discuss this, I would love to hear about it!

    (More …)

     
  • What is a course & the tools for having a great one (Part 2)

    November 25th, 2010

    Moodle 2.0 was released yesterday (Yay! Super-Yay!) so a small discussion starter into what I think Moodle might look like in the future is appropriate. Actually, the discussion continues from a couple of months ago, when discussed quite a bit in MoodleNews and on Twitter. (See also previous course editing prototype.)

    I interviewed a Finnish polytechnic teacher back in July, and presented discoveries from that interview/brainstorming session in part 1. She uses Blackboard for her courses but is considering moving to Moodle. She is a bit confused when people around her are thinking of Moodle as more of a document repository than a learning platform. She acknowledges that there is probably more to it. Still, she thinks Blackboard better guides teachers who do not have a strong idea of their pedagogical approach, than Moodle.

    (More …)

     
  • The temptation to avoid usability work

    November 19th, 2010

    I am currently working on a private software project in a startup. I am involved not only in the design of the overall user experience, but also in implementation, since we are not many. The temptation to skip usability work is great for our team of two, and I too have to keep convincing myself why usability work is absolutely crucial to product success. Trying to find a succint enough way to express the basic needs for the work…

    Software engineers often question the value of usability work. It may be that a good designer could design a UI that does not create major confusion for most – if those designers already have lots of experience from usability testing in other projects. However, in any application that is done without explicit user research and usability testing targeted for the specific UI, you tend to have dozens of small confusing moments that make up the overall user experience and lead to a general ‘yuk’ reaction. Not to mention that if you don’t intimately know your users’ goals, you are likely to be designing the wrong overall application.

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

     
  • Making UI conclusions from user data

    May 29th, 2009

    This spring, I got interested in another Google Summer of Code project on Moodle: Mihai Şucan’s painting tool. It is interesting also because Mihai understands usability, too, and I have been happy to push him a bit towards doing a bit of user research. Today I commented on the answers he got (if you don’t have a Moodle.org username, click ‘Login as guest’) when he asked teachers in the community about their potential uses for a painting tool.

    And I am enjoying every bit of it since it also helps me think through user-centric design processes in my mind.

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

     
  • Having Openoffice.org Impress not change slides when clicked

    May 27th, 2008

    I am currently designing semifunctional prototypes using OOo Impress, and found myself in with the challenge that while in full screen (in a slide show), I need Impress to react to only mouse clicks that hit a button or some other element.

    The normal behaviour, which is taken for granted of course is that when you click on a slide you go to the next one. There is no setting for this that I could find, but it is possible. I am using Impress 2.4:

    1. Draw a rectangle around the slide, covering all of the slide
    2. Right-click the rectangle, select Arrange => Send to back
    3. Right-click the rectangle, select Interaction…
    4. Select Action at mouse click: “Run program” and type /bin/ls for example, though this might only work on Linux “Go to page or object”  (no, “No action” won’t work), Select the current slide from the list (Update 2008-06-02: Having here something that can be the same for every slide allows you to paste the magic rectangle on all of the slides without having to change the action of the slide.)
    5. Type the name of something that will run but will not show or use much processor power, such as /bin/ls on linux.
    6. Click OK
    7. Set the background fill for the rectangle to “invisible”
    8. Done!

    I do admit this is an overkill, and OOo really should have the feature to just disable advancing the slide show for the entire show at once. However, it works. Do report to me if it doesn’t work for you, please. :)

    P.S. Once I get the prototype tested, I will publish it here next week, along with the test questions. It is, however, in Finnish (since my test persons are Finnish).

     
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