<?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>REBECCA E SPITZER &#187; MouseHaus</title>
	<atom:link href="http://www.rebecca-e-spitzer.com/blog/tag/mousehaus/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rebecca-e-spitzer.com/blog</link>
	<description>combining design, journalism, and technology. when i feel like it, anyways.</description>
	<lastBuildDate>Tue, 09 Mar 2010 23:18:45 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Evaluating the MouseHaus TUI</title>
		<link>http://www.rebecca-e-spitzer.com/blog/2009/10/evaluating-the-mousehaus-tui/</link>
		<comments>http://www.rebecca-e-spitzer.com/blog/2009/10/evaluating-the-mousehaus-tui/#comments</comments>
		<pubDate>Fri, 09 Oct 2009 02:11:14 +0000</pubDate>
		<dc:creator>Rebecca</dc:creator>
				<category><![CDATA[TUI]]></category>
		<category><![CDATA[conceptual frameworks]]></category>
		<category><![CDATA[MouseHaus]]></category>

		<guid isPermaLink="false">http://www.rebecca-e-spitzer.com/blog/?p=123</guid>
		<description><![CDATA[MouseHaus is a tangible user interface designed for collaborative urban planning. MouseHaus is more spontaneous than URP (it offers the opportunity to create new urban elements on the fly), but it is also more limited (it only projects traffic patterns, not light or wind patterns).]]></description>
			<content:encoded><![CDATA[<p><span class="drop">M</span>ouseHaus is a tangible user interface designed for collaborative urban planning. MouseHaus is more spontaneous than <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.4525">URP</a> (it offers the opportunity to create new urban elements on the fly), but it is also more limited (it only projects traffic patterns, not light or wind patterns).</p>
<p>In the terms of <a href="www.cs.tufts.edu/~jacob/papers/chi08.pdf ">Reality-Based Interaction: A Framework for Post-WIMP Interfaces</a>, MouseHaus primarily utilizes interaction techniques already familiar to the user: the knowledge of <strong>naive physics and physical space</strong>. To add a building, park, or street to the workspace, a user only has to cut a shape out out of paper in the size of their new element&#8217;s footprint and place it on the table; they can then observe the effect their element has on traffic patterns. All of these interactions are actions familiar to users who understand relative scale, velocity, persistence of objects, etc.  Furthermore, users utilize their <strong>body awareness and skills</strong> to navigate around the table, viewing their urban scenario from many angles. <strong>Social interaction skills</strong> are also used when users collaborate around the MouseHaus interface; many users can interact and discuss possible plans, leading to a stronger and more collaborative final decision.</p>
<p>Tradeoffs were also made in the development of MouseHaus. In using paper cutouts as urban elements, MouseHaus&#8217;s developers traded <strong>expressive power</strong> for <strong>efficiency </strong>and<strong> practicality</strong>. Though their cutouts are not complex to realistically model lighting or wind, they are quick to create, easy to change, and very inexpensive.</p>
<p>In the terms of <a href="www.cs.tufts.edu/~jacob/papers/pucj.pdf">The TAC Paradigm: Specifying Tangible User Interfaces</a>, the MouseHaus TUI is made up of a number of tokens and constraints. The urban elements, made of paper cutouts, are the most obvious tokens. Physically, these pyfos are combined with variables to metaphorically represent buildings, parks, and streets within the simulated environment. The material of the elements also operate as constraints; the chosen paper color and size of each cutout (that is, the main variables) represent its behavior and attributes. The table itself is also a constraint, for it limits the physical interaction space of the tokens. Again, the physical interaction space of the tokens is also limited by the tokens themselves: elements cannot be overlapped.</p>
<p>The prevalent TOC relationship within MouseHaus is that of the urban elements to the table surface; the placement of elements (tokens) on the table (constraint) creates the TUI environment by associating the tokens with their constraints. Within this relationship, the tokens themselves also operate as constraints on themselves and the other tokens around them. Depending on how you view the situation, the relative definition of each element can change significantly.</p>
<p>Within this TOC relationship, the urban elements have computational interpretation as they are manipulated. New elements may be added to the table (discrete manipulation) or existing elements may be shifted around on the table (continuous manipulation); both of these changes manipulate the state of the application and change the displayed traffic patterns.</p>
<p>Both Reality-Based Interaction and the TOC Paradigm create conceptual frameworks through which we can view the MouseHaus TUI. With theis analysis , we can better understand the role of this interface&#8217;s elements and better compare this interface to other projects.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.rebecca-e-spitzer.com/blog/2009/10/evaluating-the-mousehaus-tui/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
