<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Wireframes Magazine &#187; events</title>
	<atom:link href="http://wireframes.linowski.ca/tag/events/feed/" rel="self" type="application/rss+xml" />
	<link>http://wireframes.linowski.ca</link>
	<description>Because every IA has something funky up their sleeve</description>
	<lastBuildDate>Mon, 26 Jul 2010 16:40:03 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>State Level Wireflows and Transitions</title>
		<link>http://wireframes.linowski.ca/2009/02/state-level-wireflows-and-transitions/</link>
		<comments>http://wireframes.linowski.ca/2009/02/state-level-wireflows-and-transitions/#comments</comments>
		<pubDate>Wed, 04 Feb 2009 22:21:56 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Samples]]></category>
		<category><![CDATA[activity]]></category>
		<category><![CDATA[events]]></category>
		<category><![CDATA[jakubs]]></category>
		<category><![CDATA[states]]></category>
		<category><![CDATA[user flow]]></category>

		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=248</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Wireflows" href="http://wireframes.linowski.ca/wp-content/themes/darwin/images/full21.jpg" rel="shadowbox"><img src="http://wireframes.linowski.ca/wp-content/themes/darwin/images/thumb21.jpg" alt="" /></a><br />
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. </p>
<p>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, <a href="http://www.amazon.com/gp/product/0123740371?ie=UTF8&#038;tag=wirefrmagazi-20&#038;linkCode=as2&#038;camp=1789&#038;creative=9325&#038;creativeASIN=0123740371">Sketching User Experiences</a>, 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 <a href="http://docs.jquery.com/Events">jQuery</a>. 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&#8217;t hesitate to submit. </p>
<p>A word of caution. This one can be considered a form of a detailing technique where it&#8217;s really up to your best judgement when to perform. I definitely don&#8217;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. </p>
<p>Here is also an <a href="http://www.uxmatters.com/mt/archives/2007/12/documenting-the-design-of-rich-internet-applications-a-visual-language-for-state.php">interesting article</a> on the same technique.</p>
<p><em>Credits: <a href="http://www.linowski.ca">Jakub Linowski</a></em></p>
]]></content:encoded>
			<wfw:commentRss>http://wireframes.linowski.ca/2009/02/state-level-wireflows-and-transitions/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Error Handling in Wireframes</title>
		<link>http://wireframes.linowski.ca/2009/01/error-handling-in-wireframes/</link>
		<comments>http://wireframes.linowski.ca/2009/01/error-handling-in-wireframes/#comments</comments>
		<pubDate>Mon, 19 Jan 2009 18:11:19 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Samples]]></category>
		<category><![CDATA[errors]]></category>
		<category><![CDATA[events]]></category>
		<category><![CDATA[states]]></category>
		<category><![CDATA[user flow]]></category>
		<category><![CDATA[wireframe]]></category>

		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=144</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Error Handling in Wireframes" href="http://wireframes.linowski.ca/wp-content/themes/darwin/images/full13.jpg" rel="shadowbox"><img src="http://wireframes.linowski.ca/wp-content/themes/darwin/images/thumb13.jpg" alt="" /></a><br />
As we begin to think about, sketch and specify <a href="http://gettingreal.37signals.com/ch09_Three_State_Solution.php">multiple interface states</a>, 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. </p>
<p>The technique is quite simple. Similarly as in the previously described <a href="/?p=38">In Page Events</a> 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.</p>
<p><em>Credits: <a href="http://www.moochida.com/yc/">Minoru Uchida</a> &#038; Mark Hines</em></p>
]]></content:encoded>
			<wfw:commentRss>http://wireframes.linowski.ca/2009/01/error-handling-in-wireframes/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Push &amp; Shove Rules</title>
		<link>http://wireframes.linowski.ca/2009/01/push-shove-rules/</link>
		<comments>http://wireframes.linowski.ca/2009/01/push-shove-rules/#comments</comments>
		<pubDate>Thu, 15 Jan 2009 17:28:46 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Samples]]></category>
		<category><![CDATA[draggable]]></category>
		<category><![CDATA[events]]></category>
		<category><![CDATA[states]]></category>

		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=115</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Push Shove Rules" href="http://wireframes.linowski.ca/wp-content/themes/darwin/images/full11.jpg" rel="shadowbox"><img src="http://wireframes.linowski.ca/wp-content/themes/darwin/images/thumb11.jpg" alt="" /></a><br />
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.</p>
<p>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. </p>
<p>I found this example on Bill Scott&#8217;s superb <a href="http://flickr.com/photos/designingwebinterfaces/">companion flickr page</a> for his upcoming<br />
<a href="http://www.amazon.com/gp/product/0596516258?ie=UTF8&#038;tag=wirefrmagazi-20&#038;linkCode=as2&#038;camp=1789&#038;creative=9325&#038;creativeASIN=0596516258">Designing Web Interfaces</a><img src="http://www.assoc-amazon.com/e/ir?t=wirefrmagazi-20&#038;l=as2&#038;o=1&#038;a=0596516258" width="1" height="1" border="0" alt="" /> book. </p>
<p><em>Credits: <a href="http://www.billwscott.com">Bill Scott</a></em></p>
]]></content:encoded>
			<wfw:commentRss>http://wireframes.linowski.ca/2009/01/push-shove-rules/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>In Page Events</title>
		<link>http://wireframes.linowski.ca/2009/01/in-page-events/</link>
		<comments>http://wireframes.linowski.ca/2009/01/in-page-events/#comments</comments>
		<pubDate>Mon, 05 Jan 2009 18:01:35 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Samples]]></category>
		<category><![CDATA[events]]></category>
		<category><![CDATA[states]]></category>
		<category><![CDATA[wireframe]]></category>

		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=38</guid>
		<description><![CDATA[Events such as mouse clicks, mouse overs, key presses, and focuses according to John Resig are the &#8220;glue which holds all user interaction&#8221;. Traditionally IA&#8217;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 [...]]]></description>
			<content:encoded><![CDATA[<p><a title="In Page Events" href="/wp-content/themes/darwin/images/full04.jpg" rel="shadowbox"><img src="/wp-content/themes/darwin/images/thumb04.jpg" alt="" /></a><br />
Events such as mouse clicks, mouse overs, key presses, and focuses according to <a href="http://ejohn.org/">John Resig</a> are the &#8220;glue which holds all user interaction&#8221;. Traditionally IA&#8217;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&#8217;s just a red arrow within the page suggesting a cause and effect. Perhaps it&#8217;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.<br />
<em>Credits: Vivi Zhang</em></p>
]]></content:encoded>
			<wfw:commentRss>http://wireframes.linowski.ca/2009/01/in-page-events/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>
