<?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: Trying Something New: Going from Idea to Web Site Reality</title>
	<atom:link href="http://webiscope.com/2008/01/trying-something-new-going-from-idea-to-web-site-reality/feed/" rel="self" type="application/rss+xml" />
	<link>http://webiscope.com/2008/01/trying-something-new-going-from-idea-to-web-site-reality/</link>
	<description>Internet Healthcare Collaboration</description>
	<lastBuildDate>Thu, 01 Jul 2010 01:56:19 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Capn</title>
		<link>http://webiscope.com/2008/01/trying-something-new-going-from-idea-to-web-site-reality/comment-page-1/#comment-264</link>
		<dc:creator>Capn</dc:creator>
		<pubDate>Wed, 23 Jan 2008 18:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://webiscope.com/2008/01/trying-something-new-going-from-idea-to-web-site-reality/#comment-264</guid>
		<description>I&#039;m sure we&#039;ve all experienced the deadline-creep that happens when a large project is entered into without any agreed-upon goals.  This applies to functionality as much as it applies to look &amp; feel (&quot;who authorized that teal background and blinking marquee text?!&quot;)  I&#039;ve found the most difficult part is in selling the &quot;assess, collect, coalate, design, then build&quot; approach to launching a new website.  A lot of time &amp; money gets spent up front and the appearance is that &quot;nothing is being done&quot;, because it&#039;s almost all vapor until the final (build) stages.  But when I taught web design &amp; development in college, I used the following analogy &amp; example:

I&#039;d tell the students, I want you build a deck for the back of my house.  The back of the house is 45&#039; wide.  Go.  The questions would start in earnest at that point.  We&#039;d cover all sorts of stuff, and after about 15 minutes I&#039;d say so what do we have?  A lot of great ideas milling around (and a couple thinking about hammers instead of HTML), but no defined expectations or constraints.  This was an exercise to get them to realize that the best way for me as the client to get what I wanted, was to define my expectations; and the best way for them to begin formalizing their grandoise ideas was to pin down my expectations as well as my limitations.  

Judy, you are following the formula that I prescribed to my students, same as the one I try to follow for any project that lands on my desk.  Bridging the gap from strategic to tactile takes the most work - but doing that work up front consistently nets the best results, and usually in the expected time frame and sometimes budget.  But the intangible benefit is that everyone involved is on the same page once the building gets underway.

I predict, by the end of your project, you&#039;ll be amazed at how first assessing everyone&#039;s requirements and expectations, then collecting all the data and constraints, then assembling that into an agreed-upon hierarchy will facilitate the build process.  Especially in terms of final design: you&#039;ll see how taking a content inventory, then creating a content hierarchy from that drives your navigation and layouts, which drives your wireframes, which is the framework for your site&#039;s &quot;storyboard&quot; ... then a dash of color, stir in the content, bake @ 350º and voila.  Let them eat cake!

Please keep us posted as your project progresses!

And no, I won&#039;t build you a deck (but I could PM it for you!)

ps. thanks for the kudos too!  (aw shucks)</description>
		<content:encoded><![CDATA[<p>I&#8217;m sure we&#8217;ve all experienced the deadline-creep that happens when a large project is entered into without any agreed-upon goals.  This applies to functionality as much as it applies to look &#038; feel (&#8220;who authorized that teal background and blinking marquee text?!&#8221;)  I&#8217;ve found the most difficult part is in selling the &#8220;assess, collect, coalate, design, then build&#8221; approach to launching a new website.  A lot of time &#038; money gets spent up front and the appearance is that &#8220;nothing is being done&#8221;, because it&#8217;s almost all vapor until the final (build) stages.  But when I taught web design &#038; development in college, I used the following analogy &#038; example:</p>
<p>I&#8217;d tell the students, I want you build a deck for the back of my house.  The back of the house is 45&#8242; wide.  Go.  The questions would start in earnest at that point.  We&#8217;d cover all sorts of stuff, and after about 15 minutes I&#8217;d say so what do we have?  A lot of great ideas milling around (and a couple thinking about hammers instead of HTML), but no defined expectations or constraints.  This was an exercise to get them to realize that the best way for me as the client to get what I wanted, was to define my expectations; and the best way for them to begin formalizing their grandoise ideas was to pin down my expectations as well as my limitations.  </p>
<p>Judy, you are following the formula that I prescribed to my students, same as the one I try to follow for any project that lands on my desk.  Bridging the gap from strategic to tactile takes the most work &#8211; but doing that work up front consistently nets the best results, and usually in the expected time frame and sometimes budget.  But the intangible benefit is that everyone involved is on the same page once the building gets underway.</p>
<p>I predict, by the end of your project, you&#8217;ll be amazed at how first assessing everyone&#8217;s requirements and expectations, then collecting all the data and constraints, then assembling that into an agreed-upon hierarchy will facilitate the build process.  Especially in terms of final design: you&#8217;ll see how taking a content inventory, then creating a content hierarchy from that drives your navigation and layouts, which drives your wireframes, which is the framework for your site&#8217;s &#8220;storyboard&#8221; &#8230; then a dash of color, stir in the content, bake @ 350º and voila.  Let them eat cake!</p>
<p>Please keep us posted as your project progresses!</p>
<p>And no, I won&#8217;t build you a deck (but I could PM it for you!)</p>
<p>ps. thanks for the kudos too!  (aw shucks)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
