<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Chapter 1 Response</title>
	<atom:link href="http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/feed/" rel="self" type="application/rss+xml" />
	<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/</link>
	<description>the I300 course blog for Group A</description>
	<lastBuildDate>Wed, 11 Feb 2009 23:42:32 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: hcid1</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-131</link>
		<dc:creator>hcid1</dc:creator>
		<pubDate>Thu, 15 May 2008 01:55:43 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-131</guid>
		<description>Thanks Shaun,

Excellent comments. I think you have a strong point about planning. My only addition to that (which I don&#039;t feel that you were suggesting in your comment, but just wanted to point it out) was that you do not want to be so rigid in your response that you don&#039;t allow your users or the project to develop naturally. But good planning and thoughtful preparation can have a significant impact as you explained with the usability example.</description>
		<content:encoded><![CDATA[<p>Thanks Shaun,</p>
<p>Excellent comments. I think you have a strong point about planning. My only addition to that (which I don&#8217;t feel that you were suggesting in your comment, but just wanted to point it out) was that you do not want to be so rigid in your response that you don&#8217;t allow your users or the project to develop naturally. But good planning and thoughtful preparation can have a significant impact as you explained with the usability example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shaquinl</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-130</link>
		<dc:creator>shaquinl</dc:creator>
		<pubDate>Wed, 14 May 2008 19:04:46 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-130</guid>
		<description>What I think really ties it all together in chapter one is proper planning in your design practices. Having a game plan before you start the process, research area where designs like this has been used before and know what the end goal is (although this may change during the process).

I think this really ties all design together as it sets the staging ground for the whole process. Having a good head start even before you bring anything to the table will only help in the long run and makes sure you do not skip anything along the way. I think this is why the authors are putting these core ideas at the beginning of the book.

For example, we now know that the design process in mutli-disciplinary teams. If you were trying to design a product that isn&#039;t in a huge orginzation then finding some of these team members that could help you would take time/effort to find. If you properly plan before the design stage then you could find these people before hand.
Also the testing phase of the design is also very important in this process and planning before hand can only make the test better and will produce more reliable and accurate data to the testers. 

I can draw from personally experiance on this when I had to do an usability test for a website. When learning about this test from the book, &quot;Don&#039;t make me think&quot; by Krugg it said to let the user think out loud to see what was/was not working on the website. With this in mind I did not come into the test with set aside questions just in case and my first user wouldn&#039;t think out loud for the life of himself. So I regrouped, planned out some questions just in case the user became stumped during the test and it provied me with alot more information when they would stop talking out loud because I could ask something like, &quot;If you came to this site and wanted to figure out who designed it, where would you click?&quot;

Peronally I think of proper planning as like a check list of ideas/things to do before going into the design phase. Although this list would change/grow as time went on it gives a proper foot hold going into the design.

&quot;bejellio, why potentially good products just turn sour in the end&quot;

I think this could be a multitude of things in the end. From not testing enough (I&#039;m really big on the testing process if you could not tell), to the consumer/user just not accepting it to fill a niche in what they need. Not doing good testing could result in something in the design process that just goes wrong after it has been released. One example of this is when Xbox 360 first came out. Their power supplies would burn out or even catch fire if left on to long with out enough proper cooling. If this was caught in the design process Microsoft could of done something to fix this by adding extra cooling.</description>
		<content:encoded><![CDATA[<p>What I think really ties it all together in chapter one is proper planning in your design practices. Having a game plan before you start the process, research area where designs like this has been used before and know what the end goal is (although this may change during the process).</p>
<p>I think this really ties all design together as it sets the staging ground for the whole process. Having a good head start even before you bring anything to the table will only help in the long run and makes sure you do not skip anything along the way. I think this is why the authors are putting these core ideas at the beginning of the book.</p>
<p>For example, we now know that the design process in mutli-disciplinary teams. If you were trying to design a product that isn&#8217;t in a huge orginzation then finding some of these team members that could help you would take time/effort to find. If you properly plan before the design stage then you could find these people before hand.<br />
Also the testing phase of the design is also very important in this process and planning before hand can only make the test better and will produce more reliable and accurate data to the testers. </p>
<p>I can draw from personally experiance on this when I had to do an usability test for a website. When learning about this test from the book, &#8220;Don&#8217;t make me think&#8221; by Krugg it said to let the user think out loud to see what was/was not working on the website. With this in mind I did not come into the test with set aside questions just in case and my first user wouldn&#8217;t think out loud for the life of himself. So I regrouped, planned out some questions just in case the user became stumped during the test and it provied me with alot more information when they would stop talking out loud because I could ask something like, &#8220;If you came to this site and wanted to figure out who designed it, where would you click?&#8221;</p>
<p>Peronally I think of proper planning as like a check list of ideas/things to do before going into the design phase. Although this list would change/grow as time went on it gives a proper foot hold going into the design.</p>
<p>&#8220;bejellio, why potentially good products just turn sour in the end&#8221;</p>
<p>I think this could be a multitude of things in the end. From not testing enough (I&#8217;m really big on the testing process if you could not tell), to the consumer/user just not accepting it to fill a niche in what they need. Not doing good testing could result in something in the design process that just goes wrong after it has been released. One example of this is when Xbox 360 first came out. Their power supplies would burn out or even catch fire if left on to long with out enough proper cooling. If this was caught in the design process Microsoft could of done something to fix this by adding extra cooling.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hcid1</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-128</link>
		<dc:creator>hcid1</dc:creator>
		<pubDate>Sun, 11 May 2008 19:40:39 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-128</guid>
		<description>Ben,

That is a highly contextual question. Sometimes good design processes fail as well. You could also ask a question like why do good designs succeed, like Marie points out with Tivo. This is why it is hard for people to come out with a book that says, &quot;Listen, here are the steps that you need to take to design successfully.&quot; This is also why people come out with Design Principles and Design Patterns that are abstract and will not by themselves lead to good designs, but my lead to good enough practices that can increase the likelihood of good designs.

I&#039;m sure that you can come up with a list of pitfall that lead to failure: not involving users, projects that go way over cost, projects that rely on technological innovation to carry poor design, projects that don&#039;t evaluate their design after its too early to iterate on them, projects that don&#039;t really have a target audience, etc. etc. Nonetheless, projects can still succeed in certain situations despite this. It depends on the individual project.</description>
		<content:encoded><![CDATA[<p>Ben,</p>
<p>That is a highly contextual question. Sometimes good design processes fail as well. You could also ask a question like why do good designs succeed, like Marie points out with Tivo. This is why it is hard for people to come out with a book that says, &#8220;Listen, here are the steps that you need to take to design successfully.&#8221; This is also why people come out with Design Principles and Design Patterns that are abstract and will not by themselves lead to good designs, but my lead to good enough practices that can increase the likelihood of good designs.</p>
<p>I&#8217;m sure that you can come up with a list of pitfall that lead to failure: not involving users, projects that go way over cost, projects that rely on technological innovation to carry poor design, projects that don&#8217;t evaluate their design after its too early to iterate on them, projects that don&#8217;t really have a target audience, etc. etc. Nonetheless, projects can still succeed in certain situations despite this. It depends on the individual project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hcid1</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-127</link>
		<dc:creator>hcid1</dc:creator>
		<pubDate>Sun, 11 May 2008 19:32:38 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-127</guid>
		<description>I think you put a thorough and thoughtful summary up there, Shaun. I was wondering if you had any thoughts (or anyone else for that matter) for what ties this chapter together. Shaun, you wrote that it was describing &quot;core elements of becoming a successful designer.&quot; This is true, but why the three components that you described in those paragraphs?

The multidisciplinary teams are extremely important to HCI design. We are going to talk a little bit about this Tuesday, and then again the following Tuesday, when I talk about innovation in design. Have multiple designers coming from different backgrounds with different experiences who have different ideas about how a design should go provides a much better chance of designing something truly original, than a group that comes from the exact same background with the exact same experiences. A little bit of conflict is a resource for us!</description>
		<content:encoded><![CDATA[<p>I think you put a thorough and thoughtful summary up there, Shaun. I was wondering if you had any thoughts (or anyone else for that matter) for what ties this chapter together. Shaun, you wrote that it was describing &#8220;core elements of becoming a successful designer.&#8221; This is true, but why the three components that you described in those paragraphs?</p>
<p>The multidisciplinary teams are extremely important to HCI design. We are going to talk a little bit about this Tuesday, and then again the following Tuesday, when I talk about innovation in design. Have multiple designers coming from different backgrounds with different experiences who have different ideas about how a design should go provides a much better chance of designing something truly original, than a group that comes from the exact same background with the exact same experiences. A little bit of conflict is a resource for us!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mbautist</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-124</link>
		<dc:creator>mbautist</dc:creator>
		<pubDate>Fri, 09 May 2008 19:46:08 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-124</guid>
		<description>Good job of summarizing the chapter.  I thought that this chapter was a very interesting read.  As stated above, the chapter dealt with the principles of good and bad design, and how the users of each product react to these designs (also known as the user experience).  I thought that the examples used in the text were very helpful in getting the author&#039;s points across. 

 I especially liked the example of good and bad design dealing with the remote controls, and how TiVo was ahead of the game in designing controls.  Their design, focusing on the user, had larger clearly labeled buttons that were easy to find for the user, as opposed to other controls that had many small buttons whose functions were unknown.  It just proves to show that considering your user when designing a product is an absolute must.</description>
		<content:encoded><![CDATA[<p>Good job of summarizing the chapter.  I thought that this chapter was a very interesting read.  As stated above, the chapter dealt with the principles of good and bad design, and how the users of each product react to these designs (also known as the user experience).  I thought that the examples used in the text were very helpful in getting the author&#8217;s points across. </p>
<p> I especially liked the example of good and bad design dealing with the remote controls, and how TiVo was ahead of the game in designing controls.  Their design, focusing on the user, had larger clearly labeled buttons that were easy to find for the user, as opposed to other controls that had many small buttons whose functions were unknown.  It just proves to show that considering your user when designing a product is an absolute must.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bejellio</title>
		<link>http://iuhci300a.wordpress.com/2008/05/09/chapter-1-response/#comment-123</link>
		<dc:creator>bejellio</dc:creator>
		<pubDate>Fri, 09 May 2008 19:35:53 +0000</pubDate>
		<guid isPermaLink="false">http://iuhci300a.wordpress.com/?p=81#comment-123</guid>
		<description>Good summary of the chapter. One of the things that I have been thinking of after reading this chapter is why potentially good products just turn sour in the end. I am sure the designer wasn&#039;t saying to himself, &quot;How can I create something that looks useful but actually add frustration and anxiety to the situation?&quot;  

My hypothesis is that too much time was in the physical creation of the product and not enough time in the conceptual arena.

Any thoughts?</description>
		<content:encoded><![CDATA[<p>Good summary of the chapter. One of the things that I have been thinking of after reading this chapter is why potentially good products just turn sour in the end. I am sure the designer wasn&#8217;t saying to himself, &#8220;How can I create something that looks useful but actually add frustration and anxiety to the situation?&#8221;  </p>
<p>My hypothesis is that too much time was in the physical creation of the product and not enough time in the conceptual arena.</p>
<p>Any thoughts?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
