<?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>Jakub&#039;s Thoughts &#187; Experiments</title>
	<atom:link href="http://linowski.ca/thoughts/category/experiments/feed/" rel="self" type="application/rss+xml" />
	<link>http://linowski.ca/thoughts</link>
	<description></description>
	<lastBuildDate>Tue, 24 Apr 2012 13:21:34 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Sticky Floating Navigation</title>
		<link>http://linowski.ca/thoughts/2010/06/sticky-floating-navigation/</link>
		<comments>http://linowski.ca/thoughts/2010/06/sticky-floating-navigation/#comments</comments>
		<pubDate>Tue, 29 Jun 2010 04:13:28 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Experiments]]></category>

		<guid isPermaLink="false">http://linowski.ca/thoughts/?p=250</guid>
		<description><![CDATA[Positioning fixed elements in a user interface is a common practice for such cases when we need to have something visible at all times. Without fixed positioning these elements disappear as a user scrolls. But what about a case when such floating boxes begin to get in the way (of a top navigation or some [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://linowski.ca/experiments/03_sticky_floating_nav/"><img class="size-full" title="exp_floatcursaffordance1" src="http://linowski.ca/thoughts/wp-content/uploads/2010/06/exp_onStickyNav1.png" alt="exp_floatcursaffordance1" width="100" height="100" /></a></p>
<p>Positioning fixed elements in a user interface is a common practice for such cases when we need to have something visible at all times. Without fixed positioning these elements disappear as a user scrolls. </p>
<p>But what about a case when such floating boxes begin to get in the way (of a top navigation or some copyright text at the bottom). Here is a quick and dirty Javascript &#038; CSS experiment which explores a possible solution. This example shows a semi fixed state of sorts for two particular elements. These two elements (the help and footer box) are fixed for the most part, but are then also switched to absolute positioning above a certain scroll threshold to move out of the way as a user scrolls. In a way then, this behaviour allows such navigation elements to be sticky to the edges of smaller container. The best of two worlds perhaps?</p>
<p>Give it a try and let me know what you think.</p>
<p>&gt;&gt; <a href="http://linowski.ca/experiments/03_sticky_floating_nav/">http://linowski.ca/experiments/03_sticky_floating_nav/</a></p>
]]></content:encoded>
			<wfw:commentRss>http://linowski.ca/thoughts/2010/06/sticky-floating-navigation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>onProximity Behaviour with Regeneration</title>
		<link>http://linowski.ca/thoughts/2009/02/onproximity-with-regeneration/</link>
		<comments>http://linowski.ca/thoughts/2009/02/onproximity-with-regeneration/#comments</comments>
		<pubDate>Sun, 01 Feb 2009 12:02:03 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Experiments]]></category>

		<guid isPermaLink="false">http://linowski.ca/thoughts/?p=99</guid>
		<description><![CDATA[Thinking of how to hide the user interface when not needed, I came up with this little rough experiment. This idea explores two combined interactions. First, a ranged interaction onProximity rule has been written which increases the opacity or transparency of an element the closer the cursor is to it. It also hides the element [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://linowski.ca/experiments/02_onProximity/"><img class="alignleft size-full" title="exp_onproximity" src="http://linowski.ca/thoughts/wp-content/uploads/2009/02/exp_onproximity.png" alt="exp_onproximity" width="100" height="100" /></a> Thinking of how to hide the user interface when not needed, I came up with this little rough experiment. This idea explores two combined interactions. First, a ranged interaction onProximity rule has been written which increases the opacity or transparency of an element the closer the cursor is to it. It also hides the element if the cursor if further away. The assumption here is that if the user is working (moving the mouse) in the central space, he or she does not need items cluttering the interface on the sides at that particular moment.</p>
<p>In order to increase the item&#8217;s discoverability, a second rule has been put in place, which after some inactivity of the mouse regenerates the hidden element. This way, the user is reminded subtly that the interface element is available if needed.</p>
<p>&gt;&gt; <a href="http://linowski.ca/experiments/02_onProximity/">http://linowski.ca/experiments/02_onProximity/</a></p>
]]></content:encoded>
			<wfw:commentRss>http://linowski.ca/thoughts/2009/02/onproximity-with-regeneration/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cursor Affordances</title>
		<link>http://linowski.ca/thoughts/2008/12/floating-cursor-affordances/</link>
		<comments>http://linowski.ca/thoughts/2008/12/floating-cursor-affordances/#comments</comments>
		<pubDate>Thu, 11 Dec 2008 20:50:19 +0000</pubDate>
		<dc:creator>Jakub</dc:creator>
				<category><![CDATA[Experiments]]></category>

		<guid isPermaLink="false">http://linowski.ca/thoughts/?p=7</guid>
		<description><![CDATA[Advanced interactions such as double left clicks, right clicks, mouse scrolling, and dragging (not visible here) are increasingly useful for enabling richer ways of providing input. These interaction posibilities, as useful as they are, however are often invisible to the user. More so, often multiple interactions (such as a left click and right click) are [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://linowski.ca/experiments/01_cursor_affordances/"><img class="size-full" title="exp_floatcursaffordance1" src="http://linowski.ca/thoughts/wp-content/uploads/2008/12/exp_floatcursaffordance1.png" alt="exp_floatcursaffordance1" width="100" height="100" /></a></p>
<p>Advanced interactions such as double left clicks, right clicks, mouse scrolling, and dragging (not visible here) are increasingly useful for enabling richer ways of providing input. These interaction posibilities, as useful as they are, however are often invisible to the user. More so, often multiple interactions (such as a left click and right click) are possible at the same time in a particular place. That&#8217;s where traditional cursors break down. This simple experiment, with the help of some CSS and Javascript, aims to provide clearer visual indicators and combat the problems with floating multi layered cursor affordances.</p>
<p>&gt;&gt; <a href="http://linowski.ca/experiments/01_cursor_affordances/">http://linowski.ca/experiments/01_cursor_affordances/</a></p>
]]></content:encoded>
			<wfw:commentRss>http://linowski.ca/thoughts/2008/12/floating-cursor-affordances/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>

