<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Tyler Tate</title>
    <link>http://www.boxesandarrows.com/person/1369</link>
    <pubDate>Thu, 22 Mar 2012 09:55:44 GMT</pubDate>
    <description>Comments by Tyler Tate</description>
    <item>
      <description>&lt;p&gt;Great article, thanks Adam. I think that associating a numerical value to features would be a very helpful exercise.&lt;/p&gt;

	&lt;p&gt;I have always been heavily influenced by the book &amp;#8220;Information Architecture for Designers,&amp;#8221; by Peter Van Dijck (link below). Our firm always walks through a strategic planning process with the client where we first develop 1) business goals that the project needs to achieve, and then define 2) user goals of why someone would visit the website. We then prioritize each goal and generate a list of 3) potential features that would accomplish each goal.&lt;/p&gt;

	&lt;p&gt;The problem with our current system is that personal opinion can still play a large role in deciding if a feature effectively fulfills a business or user goal. I think the next logical step in our process should be to numerically rate each potential feature as Adam has displayed here. For us, at least, I believe this faceted feature analysis will still be one step of several rather than a end-all be-all solution.&lt;/p&gt;

	&lt;p&gt;Information Architecture for Designers:&lt;br /&gt;&lt;a href="http://www.amazon.com/exec/obidos/ASIN/2880467314" rel="nofollow"&gt;http://www.amazon.com/exec/obidos/ASIN/2880467314&lt;/a&gt;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/faceted-feature#content_9880</link>
      <guid>http://www.boxesandarrows.com/view/faceted-feature#content_9880</guid>
      <pubDate>Thu, 22 Mar 2012 09:55:44 GMT</pubDate>
      <author>Tyler Tate</author>
    </item>
    <item>
      <description>&lt;p&gt;Thanks Stephen for this thought-provoking article. I definitely agree with what you&amp;#8217;re saying, but with one small twist. Design patterns are good: they demand rigorous thought to create and are a relatively concise way to communicate ideas. However, I firmly believe that well-executed component libraries (i.e. coded, working elements) always trump design patterns libraries in both their communicative ability and their return on investment. I made a similar argument on UX Magazine about a year ago: &lt;a href="http://uxmag.com/articles/from-pattern-to-component" rel="nofollow"&gt;http://uxmag.com/articles/from-pattern-to-component&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;I think a quintessential example of a component library is Twitter&amp;#8217;s Bootstap project (&lt;a href="http://twitter.github.com/bootstrap/" rel="nofollow"&gt;http://twitter.github.com/bootstrap/&lt;/a&gt;). In a recent article on A List Apart, it&amp;#8217;s co-creator Mark Otto described their approach as making it into a self-documenting style guide (&lt;a href="http://www.alistapart.com/articles/building-twitter-bootstrap/" rel="nofollow"&gt;http://www.alistapart.com/articles/building-twitter-boots&amp;hellip;&lt;/a&gt;).&lt;/p&gt;

	&lt;p&gt;From my experience actively curating a component library at TwigKit over the past two years, the two greatest lessons I&amp;#8217;ve learned are: design and development must collaborate as closely as possible, and iteration is vital to success.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/are-design-patterns#content_112856</link>
      <guid>http://www.boxesandarrows.com/view/are-design-patterns#content_112856</guid>
      <pubDate>Mon, 06 Feb 2012 16:38:29 GMT</pubDate>
      <author>Tyler Tate</author>
    </item>
  </channel>
</rss>

