INFORMATION APOCALYPSE

Patterns of Flow and Responsive UI Design

		 	  <p>Was lucky enough today to attend a talk by <a href="http://www.google.co.nz/url?sa=U&amp;start=1&amp;q=http://www.cs.umd.edu/~bederson/&amp;e=747">Ben 
    Bederson</a>, who presented his work on <a href="http://www.acm.org/ubiquity/views/v5i27_bederson.html">Interfaces 
    for Staying in the Flow</a>, and examples of software that he has developed 
    in response to common usability problems. The concept of flow is familiar 
    enough to anyone who has ever started working on something, gotten underway, 
    and then looked up seemingly 5 minutes later, only to realise that 5 hours 
    had passed, absorbed in productivity. In relation to HCI, flow is a major 
    factor in the whether a user interface becomes a reliable (and fun) tool, 
    or a frustrating and unwieldy distraction. From my experience, I have 
    to say that the majority of software falls into the later category, which 
    makes research and development in this area quite useful to take in.</p>
  <p>One of the most difficult challenges in designing an interface that encourages 
    flow is to provide for the varying levels of skill and understanding of 
    users - encouraging beginners to explore and learn to use the tool, but 
    without alienating the more advanced users. Key requirements are that 
    the interface must keep users focused on the content or task domain itself, 
    and to try and avoid imposing situations that require short term memory 
    to resolve (humans are not good at this!). While the general common sense 
    and ubiquity of these ideas should be self-evident to everyone who has 
    spent time working with computers, it's very hard to uncover any concrete, 
    tangible elements that can lead to achieving this balance. Even the <a href="http://web.mit.edu/ist/usability/usability-guidelines.html">MIT 
    Usability Guidelines</a> simply state - <em>"Site accommodates novice 
    to expert users"</em> without any real qualification of how to understand 
    or evaluate this distinction.</p>
  <p>Of course, this led me to wonder about UI design patterns - do they exist? 
    Or, are they completely context dependent, as many programmers and designers 
    believe. I think the evolution of information architecture has shown that 
    there are certain emerging patterns in web design that provide a core 
    model for interaction with content based resources, but how far can this 
    be applied to more dynamic or transactional interfaces? While a huge body 
    of research and shared knowledge exists in the field of object oriented 
    design patterns (the code level), I've been finding it hard to comprehend 
    the scarcity of research that relates specifically to UI patterns (some 
    good examples being Sari Laakso's <a href="http://www.cs.helsinki.fi/u/salaakso/patterns/">User 
    Interface Design Patterns</a>, Jennifer Tidwell's <a href="http://time-tripper.com/uipatterns/index.php">UI 
    Patterns and Techniques</a> - and not forgetting Apple's <a href="http://developer.apple.com/documentation/UserExperience/UserExperience-date.html">Human 
    Interface Guidelines</a> of course). </p>
  <p>At a deeper level, I am starting to believe that the most significant 
    disruption to flow might actually be the graphical OS metaphor itself, 
    and its working mode of spawning a maze of windows and separated applications. 
    I can definitely recognize the success and value of having multiple specialized 
    applications (tools) that each perform one task very well - but I tend 
    to view the success of specialization as mainly derived from command line 
    applications - it's getting to the point where contemporary GUI applications 
    don't seem to contribute much more than just adding layers of bloat upon 
    bloat upon bloat. Perhaps customization is the best way to solve this 
    problem. But besides the desktop background, how many people actually 
    take the time to configure and customize their operating environment - 
    from setting icons to rearranging the application menu? The overhead involved 
    in this kind of tinkering is really beyond what most average users have 
    the time or skills to accomplish, and with almost all desktop/application 
    environments there is no straightforward path to move from default preferences 
    to a totally customized interface.</p>
  <p> I want to see integrated tools that do evolve and grow with the habits 
    and preferences of their users - tools where the advanced possibilities 
    are opened up through exploration and learning that begins at the most 
    simple level of usage. I don't want the developers of the application 
    to impose their definition of which options I use the most - I want the 
    application itself to respond to the way it gets used (as was pointed 
    out today - the worst offender in this area is the indomitable <a href="http://office.microsoft.com/en-us/FX010857991033.aspx">Word</a>).</p>
  <p>This approach opens up fascinating ideas for web applications, especially 
    with the rise of distributed computing. The interface could be concieved 
    as no longer tied to a particular software installation or machine, but 
    simply a collected set of properties and objects that have evolved with 
    the history of users interaction with the system, and accessible from 
    any compatible device with network access. With the emergence of the <a href="http://desktop.google.com/about.html">Desktop 
    Search</a>, Google is fast becoming the lowest common dominator (no, thats 
    not a typo) in this space, which starts to blur the boundaries between 
    an interface, a filesystem, and a distributed collection of resources. 
    Which leads me back to seriously re-considering flow based operating system 
    metaphors I previously assumed were far too wacky to really work, such 
    as David Gelernter's <a href="http://www.cs.yale.edu/homes/freeman/lifestreams.html">Lifestreams</a>.</p>
  <p>The possibilities it seems, are wide open.</p>			

About This Book

This is archived content. Probably useless now.