<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Comments on The Content Conundrum</title>
    <link>http://www.boxesandarrows.com/view/the-content</link>
    <pubDate>Thu, 06 Aug 2009 20:15:02 GMT</pubDate>
    <description>Designers often dismiss deep consideration of content. Chris Detzi shows how this affects project implementation and helps us&lt;br /&gt; create experiences that hold&lt;br /&gt; content more effectively.</description>
    <item>
      <description>&lt;p&gt;Really useful article, thank you! It&amp;#8217;s helped me rethink how and when we collaborate with our clients when they produce content themselves.&lt;/p&gt;

	&lt;p&gt;In my experience, many small charities and businesses see content as an aspect of the project that they can do in-house to keep costs down (and who can blame them?). This means it is often produced by people who hold extensive knowledge on the subject of the website, or who may be excellent report or press release writers, but who do not have web writing expertise.&lt;/p&gt;

	&lt;p&gt;We usually write some of the content for our clients anyway as part of the wireframes exercise and this will be signed off by the client before the designer begins making them look pretty. We always write or carefully consult on home page copy, for instance. However, the client usually provides the rest of the content long after wireframes and designs have been signed off. And because our clients often prefer to populate the website themselves, too, again to save costs, it is often only finished at the point when the system is fully tested and literally ready for launch in all other respects. Basically, it&amp;#8217;s the very last stage and it is too late and too expensive to make changes to the system at this point.&lt;/p&gt;

	&lt;p&gt;Now I&amp;#8217;m thinking that even if a client can&amp;#8217;t afford to use a professional web writer, at least we can help them to produce effective content through providing guidance and reviewing the content they provide. More so than we do at the moment, anyway. We will also alter our process to bring forward content production &amp;#8211; clients may feel a little pressured by this as it&amp;#8217;ll be unexpected, I think, but the website/app will be so much better for the end result!&lt;/p&gt;

	&lt;p&gt;Thanks &amp;#8211; v. helpful!&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40465</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40465</guid>
      <pubDate>Thu, 06 Aug 2009 20:15:02 GMT</pubDate>
      <author>Jo Johnson</author>
    </item>
    <item>
      <description>&lt;p&gt;ugh. &lt;a href="http://doriantaylor.com/10a7bae4-013f-451e-a551-8f76e9dbea9d" rel="nofollow"&gt;http://doriantaylor.com/10a7bae4-013f-451e-a551-8f76e9dbe&amp;hellip;&lt;/a&gt;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40414</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40414</guid>
      <pubDate>Tue, 04 Aug 2009 20:05:53 GMT</pubDate>
      <author>Dorian Taylor</author>
    </item>
    <item>
      <description>&lt;p&gt;Yikes, I wasn&amp;#8217;t expecting that. Now with paragraph breaks: &lt;a href="http://doriantaylor.com/10a7bae4-013f-451e-a551-8f76e9dbea9d" rel="nofollow" rel="nofollow"&gt;Response to The Content Conundrum&lt;/a&gt;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40413</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40413</guid>
      <pubDate>Fri, 07 Jan 2011 19:49:50 GMT</pubDate>
      <author>Dorian Taylor</author>
    </item>
    <item>
      <description>&lt;p&gt;In some ways I think we still treat the design and production of Web-based systems the same as we do desktop applications (a safe conclusion given the explosive popularity of &lt;span class="caps"&gt;AJAX&lt;/span&gt; and the recent events around &lt;span class="caps"&gt;HTML5&lt;/span&gt;). Since I began using the Web in 1994, I have watched us contort it almost beyond recognition into a signal-degraded mimic of what we have had on the desktop for the last three decades. It&amp;#8217;s almost as if everyone has missed the point.&lt;br&gt;&lt;/p&gt;

	&lt;p&gt;The first half of the acronyms representing two of the three salient concepts of the Web are H.T. which stand for Hyper*text*, which enables us to convey information without having to spin the roulette wheel for the correct arrangement of concepts that pass the attrition test we call communication. The Web doesn&amp;#8217;t *have* content, the Web *is* content. Content as it has been for millennia with the addition of an eminently useful, newish form of punctuation known as the link. Given the state of the technology you&amp;#8217;d think it was hyperbuttons, or hyperwidgets or something, not hypertext. Content is what gets sandwiched between the code and the lozenges; what supplants Lorem ipsum on Photoshop mockups. When it shows up, it is barely distinguishable from its printed counterpart. How exactly did this happen?&lt;/p&gt;

	&lt;p&gt;As you underscore, content gets treated as orthogonal to programming and design (where &amp;#8220;design&amp;#8221; is defined as the production of the part that looks something between a magazine layout and an avionics panel). While I acknowledge that the engineering paradigm tends to dominate any knowledge product where executable code can be found, I wonder if the short-shrift situation of content has something to do with the way it is made.&lt;/p&gt;

	&lt;p&gt;We typically write content using tools designed primarily for the authoring of printed memoranda, and to a lesser extent, reports. Occasionally, we use tools designed for books, scientific papers or online help. With the possible exception of the very last, how closely do any of these targets resemble hypertext? Is it possible that the way that content is conceived and delivered compromises its potency?&lt;/p&gt;

	&lt;p&gt;Finally, it should be noted that code, interaction design and visual design can be spoken of in terms of content. Code is the principal way for programmers to tell one another what they are telling the computer. Interaction is a stochastic conversation between a person and a computation using what is ultimately a domain-specific language. Visual design emotes and implies what words can&amp;#8217;t reach. Rather than designating content as something that is plugged into a decorated shell, why not endeavour to put it at the centre?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40412</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40412</guid>
      <pubDate>Tue, 04 Aug 2009 21:15:08 GMT</pubDate>
      <author>Dorian Taylor</author>
    </item>
    <item>
      <description>&lt;p&gt;I enjoyed your article Chris. Been thinking about this a lot recently too (particularly about how to communicate it to other people in the industry). Though, I also agree with Todd that there&amp;#8217;s a major component involved in understanding the range and makeup of existing content, when designing for a site or property that already exists.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40410</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40410</guid>
      <pubDate>Thu, 06 Aug 2009 20:15:11 GMT</pubDate>
      <author>Rachel Lovinger</author>
    </item>
    <item>
      <description>&lt;p&gt;Thank you! I&amp;#8217;ve been a content strategy &amp;#8220;looky-loo&amp;#8221; for a while now, and your article struck a chord, prompting a response. I especially appreciated the graphic contrasting the approved design with the same design displaying real content.&lt;/p&gt;

	&lt;p&gt;I would like to add that I believe a piece of the solution is client education. If we agree (tacitly or not) to design web pages in the absence of content, we&amp;#8217;re setting ourselves and our clients up for delay and disappointment. Like Travis, this doesn&amp;#8217;t mean that I always get 100% of the content prior to design approval, but at the very least, it&amp;#8217;s critical to help clients understand the value of content in meeting their goals, and to understand on a visual level, the relationship between the &amp;#8220;shape&amp;#8221; of the &amp;#8220;real &amp;#8221; content and a successful design.&lt;/p&gt;

	&lt;p&gt;Happily for me, as a one-woman shop, I get to define the process, and set expectations with clients. Like Travis, I also find it helpful to &amp;#8220;assume&amp;#8221; copy writing as well as other content generation tasks in my proposals.&lt;/p&gt;

	&lt;p&gt;Thanks again for the article.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40408</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40408</guid>
      <pubDate>Tue, 04 Aug 2009 20:09:35 GMT</pubDate>
      <author>Jeri Hastava</author>
    </item>
    <item>
      <description>&lt;p&gt;Perhaps it&amp;#8217;s because I design for a publisher, but our content types for a new project are brainstormed, designed, and specified fairly early in the design process.   Where we fall over is in two primary areas.  1) we rarely examine the legacy content which is to be migrated to the new project closely enough.  In fact the IAs mostly look at a couple of representative &amp;#8220;edge cases,&amp;#8221; then find we need to make all sorts of concessions in our approved designs to accommodate the full set of real content.   But this is mostly on purpose &amp;#8211; we want to design the experience first and maintain optimism that our existing content and production workflows can support it.   God help us the day we start doing it the other way around.  2) we often find that our design mock-ups are too full of high quality art and layouts, and the production staff who needs to maintain the site often doesn&amp;#8217;t have access to the same art direction resources on an ongoing basis.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40406</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40406</guid>
      <pubDate>Tue, 04 Aug 2009 20:08:35 GMT</pubDate>
      <author>Todd  Toler</author>
    </item>
    <item>
      <description>&lt;p&gt;Thank you so much for highlighting this issue that so many of us face. We try very hard to get all the content prior to the completion of wireframes, but it rarely happens. Clients are not aware of how much time and effort it really takes to revise and generate new content. We now bring in a copywriter as the default in our contracts to try and minimize the content burden on the client.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40405</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40405</guid>
      <pubDate>Thu, 10 Sep 2009 04:59:36 GMT</pubDate>
      <author>Travis Smith</author>
    </item>
    <item>
      <description>&lt;p&gt;I appreciate that you offered concrete solutions. If we truly are advocates for the end user, we must push for our content collaborators seat at the table. Great article, Chris.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40404</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40404</guid>
      <pubDate>Tue, 04 Aug 2009 13:55:57 GMT</pubDate>
      <author>Jennifer Bohmbach</author>
    </item>
    <item>
      <description>&lt;p&gt;Chris,&lt;/p&gt;

	&lt;p&gt;Good article.  I face the content gap issue quite often with our clients.  Thanks for the insight provided in this article.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40403</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40403</guid>
      <pubDate>Tue, 04 Aug 2009 13:47:19 GMT</pubDate>
      <author>Tedrick Vernon</author>
    </item>
    <item>
      <description>&lt;p&gt;Enjoyed this article. I agree that it&amp;#8217;s open collaboration, between the technicians, strategists and artists regarding the content direction, that will determine the long-term success of a project.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40402</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40402</guid>
      <pubDate>Tue, 04 Aug 2009 11:59:59 GMT</pubDate>
      <author>Richard Ingram</author>
    </item>
    <item>
      <description>&lt;p&gt;Christopher,&lt;br /&gt;                    An article on content in B&amp;amp;A! Is &amp;#8216;content&amp;#8217; getting somewhere at last? An excellent article too and I agree absolutely with Rahel above. &lt;br /&gt;I wrote a short post last year about how I felt that content was not represented in the design process. I coined the term &amp;#8216;content centred design&amp;#8217; as I felt that content needed a champion throughout the whole design process as much as users did.  &lt;a href="http://patrickcwalsh.wordpress.com/2008/06/16/content-centred-design/" rel="nofollow"&gt;http://patrickcwalsh.wordpress.com/2008/06/16/content-cen&amp;hellip;&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;In the post I state that &amp;#8216;content has a structure and a purpose which is independent of the user or web designer&amp;#8217;. I really believe that what happens with many websites with regard to content is that the intentions of the author/copy writer are often willfully ignored and thus the communication with the user throughout the life of the website design is diminished.&lt;/p&gt;

	&lt;p&gt;If we treat content as a stakeholder and create a structure for &amp;#8216;content centred design&amp;#8217; mirroring &lt;span class="caps"&gt;UCD&lt;/span&gt; this might ensure that content is considered throughout the entire process rather than being shoehorned in at the end.  I think that not only will the final product be better for this but I would guess that more consistent development times might be achieved as there will be one less potential surprise to deal with towards the end of the process.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40401</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40401</guid>
      <pubDate>Fri, 07 Jan 2011 19:39:47 GMT</pubDate>
      <author>Patrick C. Walsh</author>
    </item>
    <item>
      <description>&lt;p&gt;This article resonates strongly with me because of all the reasons you mentioned, and more. The &lt;span class="caps"&gt;UCD&lt;/span&gt; process can be mirrored for content strategy &amp;#8211; loosely, user research, personas, task analysis and scenarios, content modeling (instead of wireframing), testing with real content and real users &amp;#8211; and iterate. It&amp;#8217;s got to be lock-step with development, and needs deliverables that are integrated within the project plan.&lt;/p&gt;

	&lt;p&gt;A few years ago, Joe Gollner articulated it this way: Content is too important an asset to be treated as a cottage industry. Your statement about usability becoming table stakes is well-taken. I&amp;#8217;ve been saying that usability is the treasure map, and content is the treasure at the end of the hunt. No content treasure is the ultimate user betrayal, no matter how well the treasure map helps with the hunt.&lt;/p&gt;

	&lt;p&gt;Glad to see that content strategy is making its way into this arena.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40400</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40400</guid>
      <pubDate>Wed, 23 Jun 2010 07:28:20 GMT</pubDate>
      <author>Rahel Anne Bailie</author>
    </item>
    <item>
      <description>&lt;p&gt;This is all too (sadly) true &amp;#8211; always remember that people come to the web for content, and everything else is there to support it. &lt;br /&gt;A major aspect of the problem is the paradigm of web design and development, and the role definitions and scope decisions that make projects almost bound to fail. Critique the project concept as early as possible&amp;#8230; by the time it gets moving, there may be no time for content exploration or for real collaboration with content partners.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40399</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40399</guid>
      <pubDate>Wed, 23 Jun 2010 07:25:24 GMT</pubDate>
      <author>David More</author>
    </item>
    <item>
      <description>&lt;p&gt;Great article and all matches with my experience. This is exactly why, although I do a lot of IA, I also spend a lot of time on content and copy with my clients.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40398</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40398</guid>
      <pubDate>Thu, 10 Sep 2009 04:59:04 GMT</pubDate>
      <author>Donna Spencer</author>
    </item>
  </channel>
</rss>

