<?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: Overcoming design laziness</title>
	<atom:link href="http://kuwamoto.org/2007/02/05/overcoming-design-laziness/feed/" rel="self" type="application/rss+xml" />
	<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/</link>
	<description>music, technology, interfaces, people</description>
	<lastBuildDate>Mon, 19 Oct 2009 16:37:14 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tom Bray</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-25176</link>
		<dc:creator>Tom Bray</dc:creator>
		<pubDate>Wed, 16 May 2007 22:45:59 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-25176</guid>
		<description>Here&#039;s a Flex/Apollo app that doesn&#039;t look lika a Flex app:  http://labs.searchcoders.com/dashboard/demo/

Before I designed this in PhotoShop, I expected the actual skinning process to be difficult.  I think that people see the Flex 2 Style Explorer and assume that&#039;s all they can do without getting their hands really dirty.  I originally assumed that you use CSS for the basic things and then you have to do something mysterious and difficult to make more significant changes.  Perhaps the Style Explorer should be updated to demonstrate choosing different skins for things.  For example, you could select the Button component and change the up/over/down skins and display the resulting CSS embeds.  

I&#039;ve been really pleased with how easy it was to skin this app.  I feel like I have complete control.  We just need to get the word out that it&#039;s not as hard as people think.

-Tom</description>
		<content:encoded><![CDATA[<p>Here&#8217;s a Flex/Apollo app that doesn&#8217;t look lika a Flex app:  <a href="http://labs.searchcoders.com/dashboard/demo/" rel="nofollow">http://labs.searchcoders.com/dashboard/demo/</a></p>
<p>Before I designed this in PhotoShop, I expected the actual skinning process to be difficult.  I think that people see the Flex 2 Style Explorer and assume that&#8217;s all they can do without getting their hands really dirty.  I originally assumed that you use CSS for the basic things and then you have to do something mysterious and difficult to make more significant changes.  Perhaps the Style Explorer should be updated to demonstrate choosing different skins for things.  For example, you could select the Button component and change the up/over/down skins and display the resulting CSS embeds.  </p>
<p>I&#8217;ve been really pleased with how easy it was to skin this app.  I feel like I have complete control.  We just need to get the word out that it&#8217;s not as hard as people think.</p>
<p>-Tom</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Moca</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-19062</link>
		<dc:creator>Moca</dc:creator>
		<pubDate>Wed, 11 Apr 2007 13:17:59 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-19062</guid>
		<description>I am a designer and last weekend decided to try to learn flex for a simple chart app. I started laying my panels and charts and of course before making the app work for real, I used dummy data and start to stylize. After my first 4 hours in Flex, I had my layout with different colors and css styles working.

Too bad my left side does not work..it took me all Sunday to try to bind some XML to my charts which I still did not work it out since my XML did not look like the samples I found.

It is hard to have a combination of design and development skills..

As a user, I would rather see the default Flex style than some horrible looking color combinations (My Space style) that some of my developer buddies can come up with :)</description>
		<content:encoded><![CDATA[<p>I am a designer and last weekend decided to try to learn flex for a simple chart app. I started laying my panels and charts and of course before making the app work for real, I used dummy data and start to stylize. After my first 4 hours in Flex, I had my layout with different colors and css styles working.</p>
<p>Too bad my left side does not work..it took me all Sunday to try to bind some XML to my charts which I still did not work it out since my XML did not look like the samples I found.</p>
<p>It is hard to have a combination of design and development skills..</p>
<p>As a user, I would rather see the default Flex style than some horrible looking color combinations (My Space style) that some of my developer buddies can come up with :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Perez</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-14622</link>
		<dc:creator>Jon Perez</dc:creator>
		<pubDate>Fri, 09 Mar 2007 21:33:10 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-14622</guid>
		<description>I look at the sample themes from http://www.scalenine.com/ and guess what, none of them look as good as the default Flex 2 theme either.  They&#039;re all pretty mediocre and uninspired (and garish).  For the ones which are somewhat ok, the only qualities making them so are the ones that they share with the original Flex 2 theme.</description>
		<content:encoded><![CDATA[<p>I look at the sample themes from <a href="http://www.scalenine.com/" rel="nofollow">http://www.scalenine.com/</a> and guess what, none of them look as good as the default Flex 2 theme either.  They&#8217;re all pretty mediocre and uninspired (and garish).  For the ones which are somewhat ok, the only qualities making them so are the ones that they share with the original Flex 2 theme.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Perez</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-14621</link>
		<dc:creator>Jon Perez</dc:creator>
		<pubDate>Fri, 09 Mar 2007 21:26:57 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-14621</guid>
		<description>The default Flex 2 look is nice and clean. There is absolutely nothing wrong with it.  It doesn&#039;t need to be changed.  If it ain&#039;t broke, don&#039;t fix it.

The default HTML look sucks.  The Napkin look also sucks.</description>
		<content:encoded><![CDATA[<p>The default Flex 2 look is nice and clean. There is absolutely nothing wrong with it.  It doesn&#8217;t need to be changed.  If it ain&#8217;t broke, don&#8217;t fix it.</p>
<p>The default HTML look sucks.  The Napkin look also sucks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phillip Kerman</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-11443</link>
		<dc:creator>Phillip Kerman</dc:creator>
		<pubDate>Fri, 09 Feb 2007 22:16:09 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-11443</guid>
		<description>Marcus pretty much sums up my feeling too.

I really want to get into Flex for custom apps, but as I explore my recent gripe (not much different than yours regarding design laziness) is &quot;stability laziness&quot;.

I can bugs in SO many public facing Flex apps.  Do these people not care? Do they not test stuff? I mean, my code is far from 100% bug free, but it&#039;s really bad in many examples I&#039;ve seen.  Often, too, the errors that I discover are in the framework itself and I hear developers say &quot;oh, that&#039;s in the Flex framework&quot; and that&#039;s it!  Do clients accept this? (I think I would like to trade some of my more picky clients for some like that.)

Seriously, though I think it&#039;s important to address buginess as well as generic designs early in Flex&#039;s success to ensure a few bad examples don&#039;t reflect poorly on the product.</description>
		<content:encoded><![CDATA[<p>Marcus pretty much sums up my feeling too.</p>
<p>I really want to get into Flex for custom apps, but as I explore my recent gripe (not much different than yours regarding design laziness) is &#8220;stability laziness&#8221;.</p>
<p>I can bugs in SO many public facing Flex apps.  Do these people not care? Do they not test stuff? I mean, my code is far from 100% bug free, but it&#8217;s really bad in many examples I&#8217;ve seen.  Often, too, the errors that I discover are in the framework itself and I hear developers say &#8220;oh, that&#8217;s in the Flex framework&#8221; and that&#8217;s it!  Do clients accept this? (I think I would like to trade some of my more picky clients for some like that.)</p>
<p>Seriously, though I think it&#8217;s important to address buginess as well as generic designs early in Flex&#8217;s success to ensure a few bad examples don&#8217;t reflect poorly on the product.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yet Another Blog from Luar &#187; Doubt on Flex as the best option (4): Dilemma on Follow HTML style</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-11367</link>
		<dc:creator>Yet Another Blog from Luar &#187; Doubt on Flex as the best option (4): Dilemma on Follow HTML style</dc:creator>
		<pubDate>Fri, 09 Feb 2007 07:10:46 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-11367</guid>
		<description>[...] Overcoming design laziness [...]</description>
		<content:encoded><![CDATA[<p>[...] Overcoming design laziness [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Adams</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-11030</link>
		<dc:creator>Aaron Adams</dc:creator>
		<pubDate>Tue, 06 Feb 2007 16:20:13 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-11030</guid>
		<description>There&#039;s absolutely no question that design needs to come first in the workflow. I don&#039;t think developer&#039;s are necessarily &quot;lazy&quot;, but I do think there is a reality where many projects do not budget for UI design. The creative quality of your application and its impact on the end user is a direct result of good work done by a variety of good people. Tools will not make up for any shortcomings here, and placing user experience expecations soley on the shoulders of the developer isn&#039;t ideal. Unfortunately -- even with a full deck of resources -- really good designers and developers are falling short these days because it’s hard to find traction with getting a kick-ass design implemented in Flex and other RIA technologies. Common scenario: Design team presents a pixel-perfect comp, there is much rejoicing, then development begins. A gradual decline in the client’s praises is followed by polite silence, then questions. You answer for a while under the guise of “it’s still in development”, but the project eventually ends in frustration as the final builds are not yet infused with the pixel-perfect sexiness promised by earlier comps. Been there? It’s not fun. I won&#039;t digress on these workflow issues further, but working in the trenches on UI design/implmentation for RIAs, it&#039;s been interesting to see these design issues unfold.

If you&#039;re one of those developers who are expected to deliver all aspects of the RIA alone, there is also hope here (and I think this is the point of blog post). Here&#039;s a few &quot;Design Eye for the Dev Guy&quot; pointers:

1. Have a purpose for your design. First seperate the look/feel ideas from what should be an initial understanding of what a user needs to accomplish in your app. Assume the persona of a real user as best you can. I recommend sketching this out with known Flex components/containers in mind.

2. Comp your app in something other than Flex Builder. Skinning is easily done in Flex right? :) It actually is, so don&#039;t worry about coding for this yet, just get the pixels to look good as it pertains to your defined user flow and other criteria (brand, etc.). As a developer, Fireworks is probably going to be your quickest &quot;I get it&quot; application for UI design, but feel free to use Flash or Photoshop... whatever fits and whatever allows you to work the quickest. 

3. Start with something familiar. Download the Flex skin templates from Narciso Jaramillo&#039;s blog at Adobe. Use these as a starting point for laying out containers and components in your comp. Later on, you can either use the CSS values you defined, or use the assets themselves for graphic skinning.

http://www.adobe.com/devnet/flex/articles/flex_skins.html 

4. Give elements room to breathe. Don&#039;t try an intricate/compact UI design until you get more experience. As a general rule, give elements consistent padding and alignment.

5. Elminate lines. Then eliminate more lines. The better you can kill extra and unecessary visual shapes and lines, the cleaner your UI will look. This might be something as simple as removing the appearance of a nested container (turn the borders off in CSS).

6. Color Theory 101: Learn from others. If you don&#039;t typically have a &quot;gut feeling&quot; for color then learn from what others have shared. Recently, Adobe&#039;s Kuler app has been a great place to see some examples.

http://labs.adobe.com/technologies/kuler/

A safe place to start for UI design is to keep a mix of neutral colors as the basis for most backgrounds, components and containers. Save the brigher/purer colors for highlighting imporant elements in the UI. You can also use contrast to achieve the same visual focus.

7. Get someone else&#039;s opinion. :)

8. Iterate in the &quot;pixel-perfect&quot; comps, then iterate more once you&#039;ve skinned for Flex. Good design is good iteration.</description>
		<content:encoded><![CDATA[<p>There&#8217;s absolutely no question that design needs to come first in the workflow. I don&#8217;t think developer&#8217;s are necessarily &#8220;lazy&#8221;, but I do think there is a reality where many projects do not budget for UI design. The creative quality of your application and its impact on the end user is a direct result of good work done by a variety of good people. Tools will not make up for any shortcomings here, and placing user experience expecations soley on the shoulders of the developer isn&#8217;t ideal. Unfortunately &#8212; even with a full deck of resources &#8212; really good designers and developers are falling short these days because it’s hard to find traction with getting a kick-ass design implemented in Flex and other RIA technologies. Common scenario: Design team presents a pixel-perfect comp, there is much rejoicing, then development begins. A gradual decline in the client’s praises is followed by polite silence, then questions. You answer for a while under the guise of “it’s still in development”, but the project eventually ends in frustration as the final builds are not yet infused with the pixel-perfect sexiness promised by earlier comps. Been there? It’s not fun. I won&#8217;t digress on these workflow issues further, but working in the trenches on UI design/implmentation for RIAs, it&#8217;s been interesting to see these design issues unfold.</p>
<p>If you&#8217;re one of those developers who are expected to deliver all aspects of the RIA alone, there is also hope here (and I think this is the point of blog post). Here&#8217;s a few &#8220;Design Eye for the Dev Guy&#8221; pointers:</p>
<p>1. Have a purpose for your design. First seperate the look/feel ideas from what should be an initial understanding of what a user needs to accomplish in your app. Assume the persona of a real user as best you can. I recommend sketching this out with known Flex components/containers in mind.</p>
<p>2. Comp your app in something other than Flex Builder. Skinning is easily done in Flex right? :) It actually is, so don&#8217;t worry about coding for this yet, just get the pixels to look good as it pertains to your defined user flow and other criteria (brand, etc.). As a developer, Fireworks is probably going to be your quickest &#8220;I get it&#8221; application for UI design, but feel free to use Flash or Photoshop&#8230; whatever fits and whatever allows you to work the quickest. </p>
<p>3. Start with something familiar. Download the Flex skin templates from Narciso Jaramillo&#8217;s blog at Adobe. Use these as a starting point for laying out containers and components in your comp. Later on, you can either use the CSS values you defined, or use the assets themselves for graphic skinning.</p>
<p><a href="http://www.adobe.com/devnet/flex/articles/flex_skins.html" rel="nofollow">http://www.adobe.com/devnet/flex/articles/flex_skins.html</a> </p>
<p>4. Give elements room to breathe. Don&#8217;t try an intricate/compact UI design until you get more experience. As a general rule, give elements consistent padding and alignment.</p>
<p>5. Elminate lines. Then eliminate more lines. The better you can kill extra and unecessary visual shapes and lines, the cleaner your UI will look. This might be something as simple as removing the appearance of a nested container (turn the borders off in CSS).</p>
<p>6. Color Theory 101: Learn from others. If you don&#8217;t typically have a &#8220;gut feeling&#8221; for color then learn from what others have shared. Recently, Adobe&#8217;s Kuler app has been a great place to see some examples.</p>
<p><a href="http://labs.adobe.com/technologies/kuler/" rel="nofollow">http://labs.adobe.com/technologies/kuler/</a></p>
<p>A safe place to start for UI design is to keep a mix of neutral colors as the basis for most backgrounds, components and containers. Save the brigher/purer colors for highlighting imporant elements in the UI. You can also use contrast to achieve the same visual focus.</p>
<p>7. Get someone else&#8217;s opinion. :)</p>
<p>8. Iterate in the &#8220;pixel-perfect&#8221; comps, then iterate more once you&#8217;ve skinned for Flex. Good design is good iteration.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Begley</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-10973</link>
		<dc:creator>Aaron Begley</dc:creator>
		<pubDate>Tue, 06 Feb 2007 05:37:53 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-10973</guid>
		<description>I think it&#039;ll take time for UI designers to realize the performance benefits of Player9.  Let&#039;s face it, the really good experience design being done for the web is being done in Flash Authoring, and those designers are still targeting Player8. But give it time.  The platform is capable of delivering some really cool interfaces. 

Here&#039;s a simple graphical effect I built in Flex to test the performance of the player, and I was really impressed with the frame rates. 

http://www.doodios.com/flare/

(and a blog about it&#039;s construction...  
http://blog.wheelerstreet.com/?p=121
)

While this demo doesn&#039;t point to any usability feature (no, I don&#039;t a good UI should shine a light in your face! :) ) It does point to capabilities of the player. 

This is good news for the creative UI designer. (The bad news comes when they have to migrate from AS2 to AS3!)

Aaron</description>
		<content:encoded><![CDATA[<p>I think it&#8217;ll take time for UI designers to realize the performance benefits of Player9.  Let&#8217;s face it, the really good experience design being done for the web is being done in Flash Authoring, and those designers are still targeting Player8. But give it time.  The platform is capable of delivering some really cool interfaces. </p>
<p>Here&#8217;s a simple graphical effect I built in Flex to test the performance of the player, and I was really impressed with the frame rates. </p>
<p><a href="http://www.doodios.com/flare/" rel="nofollow">http://www.doodios.com/flare/</a></p>
<p>(and a blog about it&#8217;s construction&#8230;<br />
<a href="http://blog.wheelerstreet.com/?p=121" rel="nofollow">http://blog.wheelerstreet.com/?p=121</a><br />
)</p>
<p>While this demo doesn&#8217;t point to any usability feature (no, I don&#8217;t a good UI should shine a light in your face! :) ) It does point to capabilities of the player. </p>
<p>This is good news for the creative UI designer. (The bad news comes when they have to migrate from AS2 to AS3!)</p>
<p>Aaron</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sho</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-10959</link>
		<dc:creator>sho</dc:creator>
		<pubDate>Tue, 06 Feb 2007 02:30:18 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-10959</guid>
		<description>Great comments, all. I agree with Marcus on the bigger projects. Design has to come first! Even for my own projects, I often start UI design by drawing first. However, for smaller personal projects, you know that developers are not going to work with designers, but it would be nice if people spent a bit of time making their applications not look 100% generic. :-)</description>
		<content:encoded><![CDATA[<p>Great comments, all. I agree with Marcus on the bigger projects. Design has to come first! Even for my own projects, I often start UI design by drawing first. However, for smaller personal projects, you know that developers are not going to work with designers, but it would be nice if people spent a bit of time making their applications not look 100% generic. :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marcus</title>
		<link>http://kuwamoto.org/2007/02/05/overcoming-design-laziness/comment-page-1/#comment-10945</link>
		<dc:creator>Marcus</dc:creator>
		<pubDate>Tue, 06 Feb 2007 00:50:54 +0000</pubDate>
		<guid isPermaLink="false">http://kuwamoto.org/2007/02/05/overcoming-design-laziness/#comment-10945</guid>
		<description>Hi.
I&#039;m also a &#039;developer&#039;, so I fully understand the pressures you&#039;re on about, but I&#039;m sorry guys, I have to disagree with you. You can&#039;t produce quality work by &#039;making it work first&#039; and then applying some make-up &#039;if you have time&#039; later on. If you follow that work flow, it doesn&#039;t really matter what you do design-wise, you&#039;ll always end up with a generic look and feel. 
Start with the UI design (if you&#039;re lucky, you&#039;ll have someone talented on board to do this part). Get it right, make it look and feel good and be appropriate to the problem at hand. Then, figure out how you&#039;re going to make it work. But never sacrifice any of that initial good design for the sake of making implementing the functionality a bit easier on yourself. There is always a way to make it happen ... even if does go against the &#039;OO, fits a design pattern well&#039; grain.
If you can do that, then the functionality becomes part of the design and you&#039;ll end up with some quality applications. 
Sho. Timely post. This is part of a problem that&#039;s been running around my head lately.  Its nice to know its not just me. Keep up the great posting.

Marcus.</description>
		<content:encoded><![CDATA[<p>Hi.<br />
I&#8217;m also a &#8216;developer&#8217;, so I fully understand the pressures you&#8217;re on about, but I&#8217;m sorry guys, I have to disagree with you. You can&#8217;t produce quality work by &#8216;making it work first&#8217; and then applying some make-up &#8216;if you have time&#8217; later on. If you follow that work flow, it doesn&#8217;t really matter what you do design-wise, you&#8217;ll always end up with a generic look and feel.<br />
Start with the UI design (if you&#8217;re lucky, you&#8217;ll have someone talented on board to do this part). Get it right, make it look and feel good and be appropriate to the problem at hand. Then, figure out how you&#8217;re going to make it work. But never sacrifice any of that initial good design for the sake of making implementing the functionality a bit easier on yourself. There is always a way to make it happen &#8230; even if does go against the &#8216;OO, fits a design pattern well&#8217; grain.<br />
If you can do that, then the functionality becomes part of the design and you&#8217;ll end up with some quality applications.<br />
Sho. Timely post. This is part of a problem that&#8217;s been running around my head lately.  Its nice to know its not just me. Keep up the great posting.</p>
<p>Marcus.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
