Inspired by the High Level Layout Aternatives sample, when I was sketching some ideas for fluidIA the other week, drawings such as this emerged. Even though the use of letters as a way to distinguish alternatives was borrowed, the intention wasn’t really about exploring layout. Instead the focus was more about exploring a number of various interaction alternatives where screen or state changes are interlinked with some form of action (mostly key presses in this case). The sample also makes use of a simple title suggesting a unifying idea for all alternatives. Just thought it would be worthy to share.

Credits: Jakub Linowski

Here is an interesting way of approaching state changes using UML notation, and more specifically state charting. Perhaps the learning curve of documenting such technical interactions is not the lowest. However, once the team agrees on using such an advanced notation system, the represented interactions and state changes can be explored with greater accuracy and detail. Some interesting symbols include: loops which imply refreshes; brackets which suggest conditionals; forward slashes which suggest system actions; and larger rounded area containers representing nested states which are always accessible.

Yohan also sent me two interesting UML references. One simpler PDF reference explains very well the notation used in the above example, and a second extended reference explains additional UML diagramming notations.

Credits: Yohan Creemers

Here is a sample revisiting the problem of exploring multiple element changes all over the screen as a result of an interaction. Traditionally a full wireframe would have to be redrawn in order to document such subtle and multiple changes. Here is a quick solution that avoids having to wireframe the full page and thus decreases effort and increases document flexibility. Fabian has achieved this by combining state based wireflows with miniframes which act as references for the elements which do change. Overall, this document reminds us of an important consideration relevant in wireframing richer interactions. This being that one interaction can have multiple element reactions. Just to recap, Bill Scott has used an alternative method of documenting a similar case with a multiple elements & state conditions matrix.

Credits: Fabian Nöthe

How do we document states changes when the page gives way to richer interaction? Here is one sample of my own work where I began to document state changes in a separate document away from the wireframes. Having access to detailed visual samples I cropped parts of the interface and layered flow arrows to represent these interactions. Typically however, these would not be so stylistically detailed and would probably be more wireframe like, or even sketched if speed mattered more.

Now to the meat of this sample. There are at least two things that I find useful which come to mind when documenting such interactivity in detail. First of all, transitions matter. Bill Buxton recently mentioned in his latest book, Sketching User Experiences, that interaction designers have too much focused on the states and not enough about what is in the space between them. To fill the states gap I personally find it interesting to seek inspiration about transition possibilities from JavaScript events such as the ones provided by jQuery. There are quite a bit of these events available and they range from key presses to double clicks, to mouse scrolls. Secondly, I sometimes complement events with conditions. Conditions are basically some form of written logic which applies to the event. For example: sometimes a state does not change on a mouse click alone, the mouse click has to be held down for more than 3 seconds and only then the new state kicks in. To represent these conditions, I put them right under the events in a smaller font. This is just one way of doing it. If you have other ways, please don’t hesitate to submit.

A word of caution. This one can be considered a form of a detailing technique where it’s really up to your best judgement when to perform. I definitely don’t do this for all parts of an interface. As others have mentioned in the past, sometimes things like this are best resolved through dialogue with the developers while the prototype is being built. Sometimes however, when the user experience can really be affected by how these states transition, it really helps to put it on paper.

Here is also an interesting article on the same technique.

Credits: Jakub Linowski

Tara has been designing the Mozilla Community Store and did a couple of wireflows at the page level. Having shrunk down the wireframes to thumbnails, this diagram provides a very nice overview of page-to-page link relationships that the user might take. nform Trading Cards however warn us that these documents could be very labour intensive if the design changes (which I also experienced). Now what if this view was automatically generated with our favourite design tools?

Credits: Tara Shahian

As we begin to think about, sketch and specify multiple interface states, it quickly becomes apparent that error handling is one potential candidate which is rich in state complexity. Looking around for an example of how to document errors I found a very interesting sample of such an error wireframing technique. Minoru Uchida has agreed to showcase and share it here.

The technique is quite simple. Similarly as in the previously described In Page Events example, coloured lines are used to denote user actions. If however there is a conditional error, a red arrow is used to guide the reader to a new page section with the error message in red. The nice thing about this technique is that the page can be further divided horizontally and only a few elements which change are duplicated. The remaining elements such as the header and footer are shared across the full page.

Credits: Minoru Uchida & Mark Hines

Ben pointed me to an interesting set of HTML wireframes which use Polypage. Polypage expands HTML wireframes or mock-ups and allows for the creation of page states. Furthermore, the various states are independent of each other and can be toggled on a small top menu to affect the page view. Say for example you want to show your wireframes to your client in the “logged out” and “first time visit” states. Polypage allows you to click through all your wireframes to demonstrate such a case. Later on when you decide to demonstrate the “logged in” state, all you do is toggle it in the top menu and continue your presentation.

The technique was initially developed at Clearleft, and Richard Rutter explains how to use it better. Here are two more sets of wireframes using this technique which contain more page states to explore.

As a side note, here is also an interesting debate as to whether these things are wireframes or prototypes.

Credits: Ben Sauer

Changing elements on a page can be forceful. Traditionally, the popup or the dialogue box is an example of a rather unforceful behaviour where the overlaying element does not affect the underlying interface. It appears on top and nothing underneath changes other than a drop shadow or a grey out. This does not have to be the case however. One example of such more forceful push and shove behaviours can be seen during dragging operations. Bill documented this nicely in such a diagram. As an item is dragged and its position changes, the surrounding items are affected as they are pushed around. Using key frames, one can imagine the underlying rules during such an operation.

Finally, these push and shove rules do not have to be limited to dragging alone. As RIA elements become more flexible to resizing, dragging, animating or any other positional and size changes, such behaviours could be considered.

I found this example on Bill Scott’s superb companion flickr page for his upcoming
Designing Web Interfaces book.

Credits: Bill Scott

Events such as mouse clicks, mouse overs, key presses, and focuses according to John Resig are the “glue which holds all user interaction”. Traditionally IA’s have documented these interactions with numbered annotations referenced on the side margin. However finding and reading such text based annotations can be a relatively slower process compared to the immediacy of contextualized visual symbols. Here I found a nice example on documenting an event within the page, which challenges the numbered annotation technique. Simply put, it’s just a red arrow within the page suggesting a cause and effect. Perhaps it’s not completely clear whether it is a mouse click or mouse over, but still it makes me wonder what if a new visual language emerged for more diverse in page interactions.
Credits: Vivi Zhang

When an interface element changes position or size over time during an animation, the path it takes can vary. Onion skinning can help indicate the various paths of an animation.

Credits: Michel Vuijlsteke