<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Back to the Future Part II</title>
	<link>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/</link>
	<description>on programming, usability, and design; by Patrick Dubroy</description>
	<pubDate>Wed, 19 Nov 2008 21:57:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Zusch Login &#187; Blog Archive &#187; Delivery Spectrum</title>
		<link>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-490</link>
		<pubDate>Sat, 05 May 2007 15:46:54 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-490</guid>
					<description>&lt;p&gt;[...] However, realizing this potential is not easy even with the human capacity for language. If the user needs to slow down to  try to remember the command, then the speed advantage of Command is likely counteracted. If the user fails to correctly recall the command, resulting in an input error, the speed advantage is certainly blown away. Ironically, while such a Command interface can be slower than the classic GUI, it may seem faster to the users because they are constantly thinking and interacting. It is daunting to make an expressive but easy to remember language where on average each induction component is expressed with six characters. Too easily the language can degenerate into a large vocabulary of arbitrary codes, which, while theoretically faster than other styles, fails to perform in practice due to the memory burden. [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[&#8230;] However, realizing this potential is not easy even with the human capacity for language. If the user needs to slow down to  try to remember the command, then the speed advantage of Command is likely counteracted. If the user fails to correctly recall the command, resulting in an input error, the speed advantage is certainly blown away. Ironically, while such a Command interface can be slower than the classic GUI, it may seem faster to the users because they are constantly thinking and interacting. It is daunting to make an expressive but easy to remember language where on average each induction component is expressed with six characters. Too easily the language can degenerate into a large vocabulary of arbitrary codes, which, while theoretically faster than other styles, fails to perform in practice due to the memory burden. [&#8230;]</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Patrick</title>
		<link>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-76</link>
		<pubDate>Fri, 09 Feb 2007 00:34:31 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-76</guid>
					<description>&lt;p&gt;Yeah, I've always dreamed of this notion of "semantic computing", where all of the entities that we deal with (files, applications, windows, buttons, commands, etc.) are well-defined objects, that you can refer to by name, and manipulate to your heart's content. Like OLE on steroids, all these objects could be linked and embedded in various ways.&lt;/p&gt;

&lt;p&gt;As an example, think if a command was a first-class object in the system. If you forgot the name of a command, you could just do a search, which would find that object for you (based on its documentation), and then you could execute it.&lt;/p&gt;

&lt;p&gt;Wow, it sounds like I've been out drinking with Alan Kay...&lt;/p&gt;

&lt;p&gt;But one of the key things to me is that you be able to refer to EVERYTHING by name. Like Plan 9 I guess.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Yeah, I&#8217;ve always dreamed of this notion of &#8220;semantic computing&#8221;, where all of the entities that we deal with (files, applications, windows, buttons, commands, etc.) are well-defined objects, that you can refer to by name, and manipulate to your heart&#8217;s content. Like OLE on steroids, all these objects could be linked and embedded in various ways.</p>
<p>As an example, think if a command was a first-class object in the system. If you forgot the name of a command, you could just do a search, which would find that object for you (based on its documentation), and then you could execute it.</p>
<p>Wow, it sounds like I&#8217;ve been out drinking with Alan Kay&#8230;</p>
<p>But one of the key things to me is that you be able to refer to EVERYTHING by name. Like Plan 9 I guess.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: e</title>
		<link>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-75</link>
		<pubDate>Thu, 08 Feb 2007 22:28:15 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-75</guid>
					<description>&lt;p&gt;We've kinda, sorta, almost managed to separate content from markup with HTML. That allows appearance of content to be modified &lt;a href="http://youtube.com/watch?v=6gmP4nk0EOE" rel="nofollow"&gt;without mangling the content itself&lt;/a&gt;. It's a pity that we haven't seen fit to do that with our commands or actions. &lt;/p&gt;

&lt;p&gt;It really should be up to the user how they interact with their computing environment. Tying actions to a specific kind of UI (CLI, GUI) means that we can't reuse code easily, and we can't explore novel interfaces (commands via speech, visual overlays, tactile representations, active surfaces, etc). Ideally, code would be divorced from the UI to the point where users could cobble together their own UIs.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>We&#8217;ve kinda, sorta, almost managed to separate content from markup with HTML. That allows appearance of content to be modified <a href="http://youtube.com/watch?v=6gmP4nk0EOE" rel="nofollow">without mangling the content itself</a>. It&#8217;s a pity that we haven&#8217;t seen fit to do that with our commands or actions. </p>
<p>It really should be up to the user how they interact with their computing environment. Tying actions to a specific kind of UI (CLI, GUI) means that we can&#8217;t reuse code easily, and we can&#8217;t explore novel interfaces (commands via speech, visual overlays, tactile representations, active surfaces, etc). Ideally, code would be divorced from the UI to the point where users could cobble together their own UIs.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Chris</title>
		<link>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-73</link>
		<pubDate>Thu, 08 Feb 2007 13:52:52 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/02/07/back-to-the-future-part-ii/#comment-73</guid>
					<description>&lt;p&gt;Well, it really ties in with the issue of finding my information - especially with regards to search boxes.&lt;/p&gt;

&lt;p&gt;If I want essentially anything on my Mac, I just type it into the search box, and it is nearly always the first hit.  Whether that is a photo or an application.  It seems a lot faster than actually spending a great deal of time organizing all my information to be easily accessible later.&lt;/p&gt;

&lt;p&gt;Same thing with the beast that is Google.  Bookmarks become a hassle to organize and access, so more than half the time I just type a keyword into Google for a site that I access frequently.  Go go 'I Feel Lucky'.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Well, it really ties in with the issue of finding my information - especially with regards to search boxes.</p>
<p>If I want essentially anything on my Mac, I just type it into the search box, and it is nearly always the first hit.  Whether that is a photo or an application.  It seems a lot faster than actually spending a great deal of time organizing all my information to be easily accessible later.</p>
<p>Same thing with the beast that is Google.  Bookmarks become a hassle to organize and access, so more than half the time I just type a keyword into Google for a site that I access frequently.  Go go &#8216;I Feel Lucky&#8217;.</p>
]]></content:encoded>
				</item>
</channel>
</rss>
