<?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: Stories by Nathan Curtis</title>
    <link>http://www.boxesandarrows.com/person/291</link>
    <pubDate>Wed, 10 May 2006 19:24:41 GMT</pubDate>
    <description>Stories by Nathan Curtis</description>
    <item>
      <title>Know Your Place</title>
      <link>http://www.boxesandarrows.com/view/know_your_place</link>
      <guid>http://www.boxesandarrows.com/view/know_your_place</guid>
      <description>&lt;pullquote&gt;"As IAs, it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision."&lt;/pullquote&gt;
&lt;p&gt;Web standards, browser support, and continued creativity are resulting in increasingly sophisticated web-based experiences. As information architects (IAs), it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision.&lt;/p&gt;

As such, conversations about how to evolve our tried-and-true approach of wireframing are rampant. Some argue eloquently that we should move away from wireframing altogether and instead prototype a living, functionally evolving target experience (such as Garret Dimon's "&lt;a href="http://www.garrettdimon.com/archives/ajax-dom-scripting-just-build-it"&gt;AJAX &amp; DOM Scripting: Just Build It&lt;/a&gt;&amp;#8221;). That's also the direction espoused recently in "&lt;a href="https://gettingreal.37signals.com/"&gt;Getting Real&lt;/a&gt;" by 37signals. Others have demonstrated techniques to enrich wireframes by simulating in-page interactions via interactive storyboards (such as Bill Scott's "&lt;a href="http://www.boxesandarrows.com/view/storyboarding_rich_internet_applications_with_visio"&gt;Storyboarding Rich Internet Applications with Visio&lt;/a&gt;&amp;#8221;).  

However, IAs may be unable (lacking technical know-how) or unwilling (because of time, culture, or other constraints) to illustrate design solutions with such technically demanding methods. So, in keeping it old school, many will continue to focus on improving wireframing techniques. One improvement is to illustrate and document a design's modular framework via efficient reuse of a similarly modular set of artifacts.

&lt;strong&gt;Reuse&lt;/strong&gt;
Tired of cutting and pasting the same page module throughout a myriad of different wireframes? Even more frustrated when, late in the design cycle, it turns out that you need another tab or link in that header that you've already cut and paste into 22 wireframes? Ever wondered how you can improve your spec documents to generalize elements repeated across pages by using the same artwork that you've used in your wireframes? Do you reuse and centralize the storage of varied design artifacts throughout your process?  

Front-end developers have long used "includes," which are HTML markup snippets that are abstracted from a single page and reused across an entire site via a single code source. Similarly, site styles can be abstracted into linked cascading style sheet files shared by all pages in a site.

Our commonly used wireframing tools, such as Adobe Illustrator and Microsoft Visio, enable us to approach our challenges in illustrating and documenting our UI design within artifacts in a similar, scalable way.

&lt;strong&gt;Views and modules&lt;/strong&gt;
Regardless of what stage of the design process you are in, at some point you'll begin wireframing one or more &lt;strong&gt;views&lt;/strong&gt; (commonly, web pages) to represent a structured display in a specific, static context.  

In all but the most small-scale design processes, &lt;strong&gt;modules&lt;/strong&gt; begin to emerge that are repeated across different views or variations of the same view. A module is an element or meaningful group of elements on a page that, while possibly static and unchanging, typically varies in presentation based on dynamically populated data, display conditions defined by business rules, and changes in state triggered by events and interactions.

Initially, perhaps it's just a header that contains a tab set and text indicating "You are logged in as John Doe (&lt;u&gt;Log Out&lt;/u&gt;)." But eventually, numerous views (or variations of the same view) reuse more and more modules, even if those modules vary only subtly in different scenarios.  Common examples of modules include:&lt;ul&gt;&lt;li&gt;A product item displayed in search results may be on sale, out-of-stock, also available via auction, or without a thumbnail image 
&lt;li&gt;A hierarchical tree view or navigation list, such as a structure that includes expandable/collapsible items for Inbox, Sent Items, Trash, and more
&lt;li&gt;A context-sensitive bar for common actions like Add, Copy, and Delete
&lt;li&gt;An article list, such as a link set generated by an RSS feed
&lt;/ul&gt;

Modules can be far more page- and context-specific (and less like a reusable design pattern), particularly if a single context warrants illustrating a range of instances, such as:&lt;ul&gt;&lt;li&gt;A configuration tool for a wireless rate plan that varies based on audience, active promotions, expanded and collapsed elements, and more  
&lt;li&gt;Shipping method (e.g. overnight) and destination (address) that varies based on prefilled customer options, customized corporate-specific displays, types of items in the order, etc. 
&lt;/ul&gt;

If a module is used in more than one illustration, then abstract and manage it in its own file. Once abstracted, you can reuse it in other deliverables such as views, flows, or specs as necessary. For example, if you have a header that's used in two views, then cut and paste the header into a separate file and place that file in every view that contains a header.

&lt;img alt="Curtis_knowyour_0605_1" height="402" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_1.gif" width="502" /&gt;
&lt;em&gt;Cut each module from the view and paste it into a new, separate file&lt;/em&gt;

&lt;pullquote&gt;Tip: If saving artwork in Adobe Illustrator with the intent to include it in a different file, then ensure you check &lt;strong&gt;Create PDF Compatible File&lt;/strong&gt; in the &lt;strong&gt;Illustrator Options&lt;/strong&gt; dialog during the Save process. That way, not only will the artwork be visible in the document within which you include it, but you can also subsequently view that Illustrator file in various versions of Adobe Acrobat, including the free Adobe Acrobat Reader.&lt;/pullquote&gt;

&lt;strong&gt;Placing artwork&lt;/strong&gt;
Inserting a module from a separate file into an illustration can be accomplished via the following commands:

Adobe Illustrator CS2&lt;ul&gt;&lt;li&gt;Click &lt;strong&gt;File&lt;/strong&gt; &gt; &lt;strong&gt;Place&lt;/strong&gt; 
&lt;li&gt;Browse and find the separate .ai file in which you've stored the artwork to place 
&lt;li&gt;Check &lt;strong&gt;Link&lt;/strong&gt; so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document 
&lt;li&gt;In the subsequent &lt;strong&gt;Place PDF&lt;/strong&gt; dialog, select &lt;strong&gt;Crop to Art&lt;/strong&gt; and click the &lt;strong&gt;OK&lt;/strong&gt; button. &lt;/ul&gt;

Note that when you place Illustrator artwork in a separate file, artwork outside the file's Artboard boundary will not be visible once placed.

Microsoft Visio 2003&lt;ul&gt;&lt;li&gt;Click &lt;strong&gt;Insert&lt;/strong&gt; &gt; &lt;strong&gt;Object&#8230;&lt;/strong&gt; 
&lt;li&gt;Select &lt;strong&gt;Create From File&lt;/strong&gt; to toggle the dialog to enable file selection 
&lt;li&gt;Browse and find the separate .vsd file within which you've stored the artwork 
&lt;li&gt;Check &lt;strong&gt;Link to File&lt;/strong&gt; so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document 
&lt;li&gt;Click the &lt;strong&gt;OK&lt;/strong&gt; button &lt;/ul&gt;

&lt;img alt="Curtis_knowyour_0605_2" height="325" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_2.gif" width="420" /&gt;
&lt;em&gt;Microsoft Visio's Insert Object dialog&lt;/em&gt;

By following these commands, you should now see the artwork from the included file as an object. You can move, resize, crop, and even edit the module from within the current document. However, since the artwork is linked, the module remains independent and can be reused across other documents. As you change and extend the module over time, updates will propagate automatically to every other document that links to it.

&lt;strong&gt;Embracing modularization&lt;/strong&gt;
Numerous capabilities arise through a modular file approach:&lt;ul&gt;&lt;li&gt;Change once and have updates propagate everywhere
&lt;li&gt;Nest relationships of modules within each view (and view variation), modules within modules within views, modules within views within flows, etc. 
&lt;li&gt;Abstract design elements progressively as each module emerges, solidifies, and extends 
&lt;li&gt;Reuse and share between designers and across projects &lt;/ul&gt;

Additionally, nomenclature you establish during this process can permeate the team's discussions and downstream development efforts. Take the advice of &lt;a href="http://koechley.com/nate/presentations/webvisions2004/first_things_first_final.ppt"&gt;Christina Wodkte and Nate Koechley&lt;/a&gt;, who point out "If you're making up a name, make it something we can all use." Your modular concepts could align with CSS naming conventions, influence the markup, and even suggest core objects built during the development of client-side scripting.

But a module's usefulness is not limited to reusing a single representation. Within the file, you can create multiple variations of a display, apart from the representation or scenario where the module initially emerged.

&lt;strong&gt;Good variations&lt;/strong&gt;
Module variations are critical in comprehensively depicting behaviors, state, dynamic data, and conditional displays during wireframing. 

For example, consider a mini-shopping cart displayed in many views of a shopping experience. Over time, teammates will need clarity on how the mini-cart appears in different states:&lt;ul&gt;&lt;li&gt;Empty 
&lt;li&gt;Contains 1 item 
&lt;li&gt;Contains 2+ items 
&lt;li&gt;Transitions when updated in real-time via an interaction to add an item to the cart from elsewhere in the view (without a refresh)  
&lt;li&gt;Transitions when an item is interactively removed (without a refresh) &lt;/ul&gt;

&lt;img alt="Curtis_knowyour_0605_3" height="402" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_3.gif" width="502" /&gt;
&lt;em&gt;A grid of module variations based on display conditions and interactions&lt;/em&gt;

The module's file is an ideal, consolidated location to store and evolve these variations. Within this file, you can quickly illustrate many variations in concert and manage those illustrations simultaneously.  

This process frequently yields a grid of variations and enables visualization of patterns and differences across data, display rules, and state. With the consolidated display, teammates can more broadly understand how context influences the flexibility and scalability of the module's elements. Additionally, if you need to update the module (whether to add a variation, update an element, or even modify copy), you have a single source.

&lt;strong&gt;Harvesting your crop&lt;/strong&gt;
With module variations prepared, you can more quickly prepare many example views and flows. But, as you place a module file into each view, you now have an illustrated grid of instances instead of just one representation. Therefore, you must crop the placed artwork to show only the variation applicable to that view's context.

&lt;em&gt;Adobe Illustrator CS2&lt;/em&gt;
There are many techniques for cropping artwork in Illustrator, including:

1. Create a clipping mask
Regardless of how variations are arranged within a module's file, you can use a clipping mask to hide all but the variation of interest:&lt;ul&gt;&lt;li&gt;Create a path (such as a rectangle with a stroke color but no fill color) surrounding the variation of interest and above the placed artwork  
&lt;li&gt;Select the path and placed artwork simultaneously 
&lt;li&gt;Select &lt;strong&gt;Object&lt;/strong&gt; &gt; &lt;strong&gt;Clipping Mask&lt;/strong&gt; &gt; &lt;strong&gt;Make&lt;/strong&gt; (or &lt;strong&gt;CTRL-7&lt;/strong&gt;) 
&lt;li&gt;Use the &lt;strong&gt;Selection&lt;/strong&gt; tool to arrange the cropped illustration within the view or flow &lt;/ul&gt;

2. Placement options
If a variation is at the artwork's edge or corner, avoid the potential maintenance issues of a clipping mask and instead use the Placement Options dialog: &lt;ul&gt;&lt;li&gt;Select the placed artwork  
&lt;li&gt;Click on the artwork's filename in the &lt;strong&gt;Control Palette&lt;/strong&gt; (displayed via &lt;strong&gt;Window&lt;/strong&gt; &gt; &lt;strong&gt;Control Palette&lt;/strong&gt;), and click on &lt;strong&gt;Placement Options&lt;/strong&gt; in the resulting menu 
&lt;li&gt;Select to preserve: &lt;strong&gt;File Dimensions&lt;/strong&gt;, select the corner or edge of the variation in the &lt;strong&gt;Alignment&lt;/strong&gt; grid, and check &lt;strong&gt;Clip to Bounding Box&lt;/strong&gt; 
&lt;li&gt;Click the &lt;strong&gt;OK&lt;/strong&gt; button 
&lt;li&gt;Drag object handles to hide portions of the placed artwork except the variation of interest 
&lt;li&gt;Use the &lt;strong&gt;Selection&lt;/strong&gt; tool to arrange the cropped illustration within the view or flow 
&lt;/ul&gt;

&lt;em&gt;Microsoft Visio 2003&lt;/em&gt;&lt;ul&gt;&lt;li&gt;Select the placed artwork 
&lt;li&gt;Click the &lt;strong&gt;Crop&lt;/strong&gt; tool (if the &lt;strong&gt;Picture&lt;/strong&gt; toolbar is not visible, select &lt;strong&gt;View&lt;/strong&gt; &gt; &lt;strong&gt;Toolbars&lt;/strong&gt; &gt; &lt;strong&gt;Picture&lt;/strong&gt;, which will display the toolbar that includes the Crop tool), or click &lt;strong&gt;CTRL-SHIFT-2&lt;/strong&gt;
&lt;li&gt;Drag a selection handle to hide portions of the placed artwork except the variation of interest
&lt;li&gt;Select the &lt;strong&gt;Pointer&lt;/strong&gt; tool (or click &lt;strong&gt;CTRL-1&lt;/strong&gt;) to arrange the cropped illustration within your broader view or flow
&lt;/ul&gt;

&lt;img alt="Curtis_knowyour_0605_4" height="402" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_4.gif" width="502" /&gt;
&lt;em&gt;Cropping or masking a grid to show only the variation of interest&lt;/em&gt;

&lt;pullquote&gt;Tip: Module, view, and flow placement is supported by your design tool's related product for creating documentation, such as Microsoft Word (for Visio-based artwork) or Adobe InDesign CS2 (for Illustrator-based artwork).&lt;/pullquote&gt;

&lt;strong&gt;Spec and flow&lt;/strong&gt;
Although boxes and arrows may be sufficient to illustrate a sequential experience path, &lt;strong&gt;flows&lt;/strong&gt; that directly incorporate wireframes result in a far more engaging understanding of an experience. With variations of each view in your path (each built upon module variations), you are better positioned to efficiently construct numerous flows. Such storyboards are more compelling and accessible, relative to your audience's cognitive struggle to map boxes and arrows to wireframes, relate decision points and business rules, and construct the experience in their mind's eye.

As the design matures, many reach a point where the design must be annotated or thoroughly documented. The existing abstraction and relationships you've built significantly ease the documentation process; in fact, a modular structure should directly suggest a design's decomposition into &lt;strong&gt;specification&lt;/strong&gt;. You can consolidate your modular artifacts (flows, views, and modules) by placing each into this central document and then detailing each to your heart's content. 

Ideally, a spec's detailed descriptions are layered onto and beside each type of placed artwork. Examples and variation grids are displayed in tandem with referenceable descriptions of dynamic data and attributes, display conditions, and events (including triggers, transitions, and resulting states).  

&lt;img alt="Curtis_knowyour_0605_5" height="402" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_5.gif" width="502" /&gt;
&lt;em&gt;Module placed into a spec document and subsequently annotated&lt;/em&gt;

&lt;strong&gt;Managing a hierarchy of modularized artifacts&lt;/strong&gt;
Ultimately, a result of modularization is an interdependent hierarchy of linked files: modules in views and spec, views in flows (to illustrate sequences and storyboards) and spec (to consolidate examples), and flows in spec (for high-level paths and understanding of the experience).

&lt;img alt="Curtis_knowyour_0605_6" height="402" src="http://www.boxesandarrows.com/files/banda/know_your_place/curtis_knowyour_0605_61.gif" width="502" /&gt;
&lt;em&gt;Examples of linked documents: modules in views and spec, views in flows and spec, and flows in spec&lt;/em&gt;

An IA can certainly adhere religiously to their own style for managing files and folders. Why not?  If it ain't broke, don't fix it--especially if it fits your process or model. Up to now, you may not even have worried about this because all of your artwork has been in a single file. However, this modular approach requires that you consider how to store what could end up as many artifacts. One solution is to create directories that mimic your artifact types, such as:&lt;ul&gt;&lt;li&gt;/projectName/modules/ 
&lt;li&gt;/projectName/views/ 
&lt;li&gt;/projectName/flows/ 
&lt;li&gt;/projectName/spec/ &lt;/ul&gt;

&lt;pullquote&gt;Tip: Consider an archive subdirectory (such as /projectName/modules/ archive/) where you store older versions to which you can refer or revert. Such a file structure becomes even more important as you share your modular artifacts with a larger team via a network drive or versioned storage system.&lt;/pullquote&gt;

&lt;strong&gt;Pros and cons&lt;/strong&gt;
Of course, such an approach has pros and cons:

&lt;em&gt;Pros:&lt;/em&gt;&lt;ul&gt;&lt;li&gt;Easier updates throughout 
&lt;li&gt;Scales well 
&lt;li&gt;Enables asset sharing for larger projects or multiple projects 
&lt;li&gt;Engenders analysis to consider more peripheral behaviors and scenarios 
&lt;li&gt;Triggers discussions of the team's shared concept of the experience 
&lt;li&gt;Simplifies design decomposition for documentation &lt;/ul&gt;

&lt;em&gt;Cons:&lt;/em&gt;&lt;ul&gt;&lt;li&gt;Remains only a static representation of an interactive experience 
&lt;li&gt;Requires discipline and initial effort to abstract modules 
&lt;li&gt;May need to re-crop artwork as variations are added to a file that has already been placed and cropped 
&lt;li&gt;Updates require tinkering to cascade through multiple placement levels across files (in InDesign and Illustrator)&lt;/ul&gt;

&lt;strong&gt;Tighten your use&lt;/strong&gt;
Some additional ideas to enhance your modular approach:&lt;ul&gt;&lt;li&gt;&lt;b&gt;Manage your links&lt;/b&gt;
Adobe's products offer a Links palette for viewing, reloading (because of updates), and editing your linked files of placed artwork. Microsoft Visio offers the Drawing Explorer to identify what artwork has been inserted. 
&lt;li&gt;&lt;b&gt;Establish size and grids&lt;/b&gt;
Once you break out artwork into separate files, it will be very painful to reuse illustrations and maintain consistency unless you establish standard sizes for elements (headers, boxes, form elements) and a grid for placement. Of course, this assumes you've conveyed what your wireframes are meant to depict (and not depict) to your visual design and development staff. 
&lt;li&gt;&lt;b&gt;Review your artifacts with their audience!&lt;/b&gt;
Seek out visual designers, developers, and quality assurance staff early to ensure your technique produces something they want. The better the spec, the better the questions, and ultimately the better the product.
Parting thoughts &lt;/ul&gt;

I'm all for interactive prototypes. In the near future, I look forward to seeing static wireframe and spec artifacts increasingly combine with interactive prototypes via an approach that simultaneously documents and demonstrates our designs in a single presentation.

However, while such interactive prototypes are valuable, the industry (or at least the type of environment where I most often find myself) is far from denying the need for printable, reviewable, versioned, and auditable documentation that details a design. The waterfall development process, for better or worse, is still a world where many of us live. Therefore, in the short term, modularization is but one way to more efficiently, clearly, and comprehensively illustrate a complex design via wireframes.</description>
      <pubDate>Wed, 10 May 2006 19:24:41 GMT</pubDate>
      <author>Nathan Curtis</author>
      <category>Deliverables</category>
    </item>
  </channel>
</rss>
