<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: User Interfaces – A Developers Responsibility</title>
	<atom:link href="http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/</link>
	<description>Software Development, Linux, Mobile Computing and More!</description>
	<lastBuildDate>Wed, 29 Dec 2010 14:40:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
	<item>
		<title>By: Pharmacy technician certification exam</title>
		<link>http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/comment-page-1/#comment-13</link>
		<dc:creator>Pharmacy technician certification exam</dc:creator>
		<pubDate>Thu, 22 Apr 2010 01:13:00 +0000</pubDate>
		<guid isPermaLink="false">http://jeffmagder.com/blog/?p=284#comment-13</guid>
		<description>Terrific work! This is the type of information that should be shared around the web. Shame on the search engines for not positioning this post higher!</description>
		<content:encoded><![CDATA[<p>Terrific work! This is the type of information that should be shared around the web. Shame on the search engines for not positioning this post higher!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Fenton</title>
		<link>http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/comment-page-1/#comment-12</link>
		<dc:creator>Greg Fenton</dc:creator>
		<pubDate>Tue, 30 Mar 2010 19:42:54 +0000</pubDate>
		<guid isPermaLink="false">http://jeffmagder.com/blog/?p=284#comment-12</guid>
		<description>The problem with the iEverything philosophy is that the devices are extremely limited in their focus and abilities.  Maybe this is the design principle you aim to tout...but it leads to simplistic solutions which often do not fit &quot;real world&quot; software situations.

Apple does a great job at creating simple, single end-user applications.  They do a not-so-good job at complex and/or multi-user applications.  iTunes (the app) is terrible as soon as you get above a small list of songs.  It is terrible when you are using it on a multi-user workstation.  It is terrible when you have data coming from multiple streams (podcasts, purchased, rips, downloads, other iPods, etc...)

I love the cleanliness and simplicity of my iPod.  However, iPod design will never, EVER be able to handle enterprise-scale applications.  Would I wish that a simplistic design could work for a knowledge worker (sorry for the buzzwords)?  Absolutely.  However, the reality is that the use cases for a knowledge worker often go excessively beyond a single button, a simple screen, a list and detail pane.  They often have multiple requirements, volumes of data, only partially-related workflows, etc...</description>
		<content:encoded><![CDATA[<p>The problem with the iEverything philosophy is that the devices are extremely limited in their focus and abilities.  Maybe this is the design principle you aim to tout&#8230;but it leads to simplistic solutions which often do not fit &#8220;real world&#8221; software situations.</p>
<p>Apple does a great job at creating simple, single end-user applications.  They do a not-so-good job at complex and/or multi-user applications.  iTunes (the app) is terrible as soon as you get above a small list of songs.  It is terrible when you are using it on a multi-user workstation.  It is terrible when you have data coming from multiple streams (podcasts, purchased, rips, downloads, other iPods, etc&#8230;)</p>
<p>I love the cleanliness and simplicity of my iPod.  However, iPod design will never, EVER be able to handle enterprise-scale applications.  Would I wish that a simplistic design could work for a knowledge worker (sorry for the buzzwords)?  Absolutely.  However, the reality is that the use cases for a knowledge worker often go excessively beyond a single button, a simple screen, a list and detail pane.  They often have multiple requirements, volumes of data, only partially-related workflows, etc&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeffrey Magder</title>
		<link>http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/comment-page-1/#comment-11</link>
		<dc:creator>Jeffrey Magder</dc:creator>
		<pubDate>Tue, 30 Mar 2010 14:28:32 +0000</pubDate>
		<guid isPermaLink="false">http://jeffmagder.com/blog/?p=284#comment-11</guid>
		<description>Interesting points Greg!   You&#039;re right that a good UI is *hard* to do.  Just look at the HCI archetypal example, &quot;the door&quot;.  They&#039;ve been around forever yet so many still have handles to pull when you should push, or bars across the whole door to push when you can only push from the side opposite the hinge, etc.  I see people using a door the wrong way all the time and we deal with them our whole lives.  

It is true that it has been hard to justify to execs the importance of the UI in the past.  But I think that we now have the monumental success of the iEverything as a great basis for a case study. 

I took a HCI course in University and they introduced some mathematical ways of analyzing many aspects of user interface usability.  But still not as convincing to some as an algorithmic proof.</description>
		<content:encoded><![CDATA[<p>Interesting points Greg!   You&#8217;re right that a good UI is *hard* to do.  Just look at the HCI archetypal example, &#8220;the door&#8221;.  They&#8217;ve been around forever yet so many still have handles to pull when you should push, or bars across the whole door to push when you can only push from the side opposite the hinge, etc.  I see people using a door the wrong way all the time and we deal with them our whole lives.  </p>
<p>It is true that it has been hard to justify to execs the importance of the UI in the past.  But I think that we now have the monumental success of the iEverything as a great basis for a case study. </p>
<p>I took a HCI course in University and they introduced some mathematical ways of analyzing many aspects of user interface usability.  But still not as convincing to some as an algorithmic proof.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Fenton</title>
		<link>http://jeffmagder.com/2010/03/23/user-interfaces-%e2%80%93-a-developers-responsibility/comment-page-1/#comment-10</link>
		<dc:creator>Greg Fenton</dc:creator>
		<pubDate>Tue, 30 Mar 2010 13:56:47 +0000</pubDate>
		<guid isPermaLink="false">http://jeffmagder.com/blog/?p=284#comment-10</guid>
		<description>How can you perplexed that many software developers do not belong to group #3?  Good UI is *hard* to do.  Good UI is hard to justify w.r.t. being a functional requirement.

I used to work for a company that made (makes?) Unix utilities for MS-Windows.  When discussing the issue of adding some simple, GUI-based tools (e.g. menu bar to the VI editor) and color syntax on tool output with execs, the CTO said &quot;prove to me that adding that stuff will sell more product&quot;.  How does one rebut that argument?

The difference between group #3 and the other two is that group #3 requires an amount of faith and/or believe in social sciences.  Group #1 and #2 are straight forward, coming directly out of mathematics, engineering and computer science courses. HCI doesn&#039;t have much in the way of algorithmic proofs.</description>
		<content:encoded><![CDATA[<p>How can you perplexed that many software developers do not belong to group #3?  Good UI is *hard* to do.  Good UI is hard to justify w.r.t. being a functional requirement.</p>
<p>I used to work for a company that made (makes?) Unix utilities for MS-Windows.  When discussing the issue of adding some simple, GUI-based tools (e.g. menu bar to the VI editor) and color syntax on tool output with execs, the CTO said &#8220;prove to me that adding that stuff will sell more product&#8221;.  How does one rebut that argument?</p>
<p>The difference between group #3 and the other two is that group #3 requires an amount of faith and/or believe in social sciences.  Group #1 and #2 are straight forward, coming directly out of mathematics, engineering and computer science courses. HCI doesn&#8217;t have much in the way of algorithmic proofs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

