So, alright, this might not be the BEST idea I’ve ever had.  However, it’s worth a post.

I’m asked frequently why we go with a letter landscape orientation for our default deliverable document.  The primary objection centers around a limited height for wireframes / mockups / screenshots, such that one may often have to resort to the “jagged edge” frame for the artwork.  My initial response is “Well, it’s modular, right?  So you can show the rest of the wireframe on the next page, and this situation doesn’t happen ALL that often, right?”

But then it occurred to me: what if the deliverable page could interactively show segments of that wireframe based on a button collection for pagination?  So, in the matter of 10 minutes or so I roughed out a “Click to view page segment” button set along with three frames for the artwork so that you can easily page up/page down through the full artwork within a single deliverable page. The solution is depicted in the short video below (<3 min).

(don’t forget to view full screen for best results!)

A state is a condition or mode of being, where the user interface or system satisfies particular conditions and/or awaits an interaction. Under different settings, the UI will produce perceivably different display variations or results. When annotating an interaction design, it’s helpful to comprehensive describe the range of states of each page, component, or even element of an experience. With such visual and textual descriptions, you can concretely set expectations to establish consensus and foster understanding across your documentation’s many audiences.

Common examples where a designer considers states include:

• When to show or hide a messaging unit to invite the user to sign in to a personalized experience.
• When particular tabular components are included above, below, or omitted relative to other components based on stored data
• When explicit user input (such as a product selection) as well as implicit behaviors (navigating an audienced site section) result in data entry defaults in a checkout process

The Fundamental Question

When describing states in interaction design, the designer’s focus is on the user - what can the user see, what are they perceiving, how is their cognitive model mapping to what the system actually manifests? Ultimately, these instances can be described by visible states that a designer can boil down to a fundamental question, with three parts:

When do you see what?

First, the “When.” This aspect focuses on the conditions or circumstances of a state. Here, it’s critical to describe conditions in terms of inexorable statements and visualizations, removing any ambiguity as to when such a state occurs - and doesn’t occur. If a designer can’t accurately describe conditions of when a state applies, then any hope at applying the “See” and “What” is fruitless. Example conditions include:

• Signed in?
• Old enough?
• Content available?
• Consumer or business or government?
  
• Account created?
• Option selected?
• Name defined?
• Playlist nonempty?
• A/B test resulted in showing version A?

All of these questions can be posed as circumstances with an answer that cannot be debated, if formed correctly. Yes, the user’s signed in or no, the user is NOT signed in. The user was defined as born before a specific date or the user is too young (or the system doesn’t know how old the user is).

Next, the “See.” This is pretty simple. When taking the user’s point of a view, describe states of a user interface is about defining whether the system should show or hide an element, component, or even a page as an interaction sequence progresses.

Finally, the “What,” which isn’t that complicated either. Here, the designer is looking to define precisely how the user interface appears. What gets shown, or not shown.

How do you communicate “When do you see what?” Via pictures and words, of course, which will be the subject of the remaining two segments of this topic.

One of the things Dan and I wanted to do with EightShapes is offer training. Sharing our experiences with other user experience professionals is enormously valuable, and contributes to our own education in the field.

I’m therefore really excited to announce that EightShapes is holding its first public workshop on August 8. Dan and I have been part of other programs, but have never hosted an event ourselves. This is a huge step for us, and we hope that the relatively low price-point of the session means that you can join us in this first of many events to come.

So, if you’ve been considering taking my intro documentation course, or wanted to double that up with some more heavy-duty thinking on wireframes, this is a fantastic opportunity.

I hope we see you there!

Often times, the reason is that as you Save, Save, Save, Save your file iteratively over it’s life cycle, INDD’s format tends to save alot of historical information about your artwork and changes over time.  Trouble is, it’s not like the file works as a Time Machine or anything - the information is just file bloat to you.

So today, as I rec’d a 33MB document, I applied my old trick of Save As.  By doing a “Save As” over top of the original file, the file size was halved to around 17MB and all that bloat is removed.  Much better, if still quite a bit large.  Oh well, life isn’t perfect.

With the CS3 release in early 2007, Indesign offered the enhanced capability to place one INDD file into another INDD file enabling us to modularize wireframes and components. With that, we extended our use of InDesign to also include the creation of wireframe artwork (pages, components, elements), abandoning the use of Illustrator for that purpose. This enabled InDesign to serve more comprehensively for the creation of wireframes and the deliverables that contain them. Clients look favorably on learning and buying one tool instead of two. Anyways…

Adoption of InDesign for wireframing is increasingly widespread, and was greeted with enthusiasm by the many EightShapes clients who purchased our documentation system and wireframing component libraries. However, all of a sudden in early 2008, we heard requests and/or interest in Adobe Fireworks for the production of wireframe and mockup-grade prototypes. Trust me, we’d not heard a whisper about Fireworks for documentation systems prior to 2008. Call it coincidence, call it a recent groundswell of popular support for Fireworks as a UX tool. Regardless, the prevailing opinion is that Fireworks is a more optimal tool for producing prototypes and smoothly blends vector- and pixel-based artwork. But is it more appropriate for a large-scale wireframing system?

As we approach not one, not two, but three clients expressing interest in Fireworks for the wireframing portion of the documentation system, it’s high time for a comparison of the strengths - and weaknesses - that each environment brings when considering a modular, component-based approach wireframing, documentation, and prototyping. With that in mind, this article strives to compare InDesign CS3 to Fireworks CS3 across some of the major categories of consideration for such a wireframing system.

Artwork

Both tools support a sufficient array of vector-based illustration, including anchor points, common shapes, stroke & fill controls, effects, object settings (such as rounded corners / “9 slicing”) and more. As far as vector-based artwork, both products are sufficient.

Modularity

Both tools support drag-and-drop panel collections of symbols (including elements and components): object libraries in InDesign, the symbol panel in Fireworks. However, that’s about where the similarities end.

Fireworks:

• Symbols are specific to a document, although you can manually import/export, cut/paste, and drag/drop from one document to another.
• Symbols can be managed as libraries, but must still be imported into a document prior to use.
• Symbol master changes can be propagated across instances of that symbol in the same document.
• You can embed artwork from one PNG into another via import; however, you cannot place and link artwork from one document into another.

InDesign:

• InDesign supports snippets, a convenient and independent file of page objects that are often used for wireframe page components. Snippets retain layer associations, resource definitions, styles, and support drag/drop of many items at one time.
• You can embed artwork from one INDD file into another, but you can also place and link artwork from many different formats (including INDD, PDF, EPS, PSD, PNG, JPG, and more) into an InDesign document. Linking files is a central tenet of modularity. Through linking, you can modularize components from the pages that contain them, and manage components over time within and across documents and projects.
• When placing artwork, you can control what layers and which page in the placed file is exposed in the destination file, without impacting what layers or page are selected in the source document.
• You can crop and resize placed, linked artwork in interesting ways without impacting the source file. For example, the placed file could contain a 2 x 2 grid of component variations, of which you’d crop out 3 of 4 variations to only expose the variation of interest in the full page wireframe.

While Fireworks symbols are more robust for within-document modularity, InDesign’s file linking, independent object libraries as panels, and snippet libraries represent a more scalable solution for efficiently and portably applying and managing design assets across files, projects, design staff, and a documentation system.

Typography

Both tools support a rich set of type attributes, including font family, size, weight, decoration, leading, kerning, leading, alignment, spacing, and baseline shift.

However, InDesign has broader features for text areas, flowing text across areas, and more.

Styles

Both tools support fundamental style capabilities for managing and reusing styles across objects and text, including fill type and color, patterns, angle, position, opacity, stroke type and color, type font, size, style, alignment, kerning, scale, and leading.

However, InDesign’s style capabilities are far more robust, which is critical for consistent visual language and maintaining large libraries of flexible design objects. These differentiators include:

• Style inheritance (e.g., quickly propagate a new font through a range of hierarchal styles)
• Style groups (surfaced through folders in each style panel)
• Style quick apply, via CTRL-ENTER followed by typing an autocompleted search for the style name, which is far more efficient than select object-and-click style to apply each one.
• Next paragraph style, useful for relationships such as a “normal paragraph” always following a “header”
• Distinct style collections for paragraphs (blocks of type), characters (inline type), objects, tables, and table cells
• For paragraphs styles: tab rulers with left/center/right aligned tab stops, character color, numbering systems, bullets/numeric lists, hyphenation, and strikethrough
• For object styles: text inset padding (left, right, top, bottom), text column count with gutter size, and text wrap for overlapped objects
• Distinct effects for object, text, stroke & fill

Advantage: InDesign. Sure, these are advanced style features. But advanced style features are just what the doctor ordered when creating a scalable, managed wireframing system.

Interactivity

Both tools support flexible interactive features, including:

• Buttons, hotspots, and hover panels
• Rollovers and disjoint rollovers
• Swap image and restore
• Attaching multiple behaviors to a single object
• Absolute and relative URLs
• Page selection within the current document
• Hyperlink destination management in a distinct panel (Fireworks: URL, InDesign: Hyperlink Destination), and can centrally manage and propagate changes to destinations through a document

But, make no mistake, Fireworks is made for prototyping. If a team is looking to create clickable walkthroughs, then either tool does the trick. But if advanced prototyping features are more your thing, then look only to Fireworks to find:

• Navigation bar collections
• Popup menus
• Animations with frames, tweening, and playback control
• Button symbols (as opposed to only instances)
• Named pages for easier selection
• Alternative text
• Status bar control
• Target specification
• URL library maintenance in a separate HTML file to manage and choose from common destinations.

Advantage: Fireworks. While InDesign provides all the fundamental interactive features needed to create a working, flexible prototype, it’s Fireworks targeted and broader features, ease of use, learnability, and HTML (instead of PDF) output that establish an obvious edge.

Output

Fireworks’ native format is PNG (a plus, for quick previewing outside the program) and can be exported to a range of optimized image formats as well as clickable, HTML-based prototypes. InDesign has a native format specific only to InDesign itself, and produces PDF output, albeit with a multitude of options for interactivity and more. However, InDesign’s export to HTML is pretty horrendous.

Advantage: Depends on your context and workflow. Mostly documents you produce? InDesign. Focused on prototyping? Fireworks.

Overcoming Prejudices

While InDesign is a tool primarily targeted at print publishing, there are existing prejudices that may inhibit individuals from recognizing InDesign product features that lend themselves well to wireframing and mirror those found in Fireworks.

Sure, you can “export html and create an entire site from Fireworks,” whereas the output of InDesign is an interactive PDF, whose behaviors and feel are not equivalent (if still similar) to a browser experience. But, that same designer who dismissed InDesign out of hand is biased by notions about InDesign that are not correct. In contrast to assumptions we heard, you can use either tool to quickly prototype pages, create a walkthrough of multiple pages, and use “symbols.” Plus, the designer’s rejection of InDesign doesn’t really mesh with the 8+ clients that have paid for and enjoyed the benefits of an InDesign-based wireframing  and deliverable solution.

InDesign is not a tool to touch up photos or create pixel perfect design. However, it’s vector approach, superior and broad styles, type capabilities, and modularity support systematic wireframing to depict lower fidelity site structure and behaviors. Additionally, restricting the UI or IA resource from pixel-based can be a good thing. I can recall too often the time lost and rabbit holes explored when tweaking and polishing visual style when a design solution and/or visual system has not yet matured to that stage - OR - matured so far that my artifacts and their audiences need not be concerned with such detail.

The Verdict?

They are both good, very good. Choose a tool for wireframing depends on the specific organizational setting, preexisting tool proficiencies, need to also support visual design in the same tool, likelihood of heavy vs. light prototyping, and modularity.

I don’t regret at all using InDesign for every single component library we’ve built to date, even knowing what I have now learned about Fireworks. It’s a great tool that’s surprisingly well-suited to the extreme wireframing approach we’ve fine tuned with our clients. It has served us - and our clients - very very well. We’ll continue to use InDesign for wireframing and prototyping in the future, I’m sure.

I am also extremely excited by the prospect of using Fireworks as well, kicking the tires and taking it not for a test drive, and diving deep on one or more client component libraries in the coming two or three months. Fireworks usage and adoption, as well as some burgeoning capabilities coming up in the next release, leave me very optimistic that we’ll have yet another tool in our kit. And, as you might guess, another tool mousepad available for sale on our site. Cheers!

| View | Upload your own

Monday April 14 2008, 9:30 - 10:15AM

As designers, why don’t we concentrate more on designing our documentation? Too often artifacts of our design process are initiated haphazardly, difficult to maintain, unusable by recipients, and organically grown into something we never anticipated. Are our artifacts optimally user-centered? Not as much as they could be.

We’ll explore both the artifacts we produce and the audiences we produce them for, and by mapping those artifacts to audiences, we’ll reveal what works… and what doesn’t. The discussion will focus on the phases through which a deliverable evolves - the deliverable’s life cycle - and we’ll discuss why that life cycle is problematic. We’ll then shift into specific ideas about what we can do to fix it such as deliverable recipes, page patterns, and even modular deliverables tailored to specific audiences.

With an interesting blend of helpful software tips and real-world examples, this talk aims to provoke you to be more prepared, predictable, structured, focused, investigative, and mechanized with your design communications.

Step 1: Create Page Pattern Cards PDF

I started by using InDesign (obviously) to create a page pattern card template with appropriate master (obviously) for each page of four card containers (obviously). Then, place screenshots of the patterns into the containers (obviously) via drag and drop, fit to the appropriately sized containers (obviously), and move onto the next page. Why is everything obvious? Well, it was rewarding to know that creating the page pattern cards was almost exactly like using the page patterns themselves for an actual deliverable.

The master include cut guides to facilitate cutting and exact sizes later, as well as the hole location I’ll use for punching each hole. The proportion of cards for each pattern is roughly equivalent to their frequency of use, popularity, and what stories I want to tell. This first step ended with a trial print and then PDF of the 40 page document of 160 cards.

Step 2: Create the Business Card Document Metadata

On the reverse of each card is my blog address, my name, my business email address, and my phone number. While I hope to encourage visitors to participate, I’ll also offer that they take their favorite or most interesting card home with them and communicate with me later if this is a technique they embrace themselves.

Step 3: Printing

All cards were printed in color on an HP Color Laserjet 3600n using glossy HP Brochure & Flyer paper. Such paper is a heavier stock that’s far more appropriate for cards since they will be shifted, shuffled, hung from push pins, and taken home by interested visitors.

Step 4: Cutting

Using my kitchen’s somewhat smaller cutting board, I proceeded to cut 8 slices per page followed by folding and tearing to remove the cards from their source sheet. The process took about 1 1/4 minutes for each page, and efficiencies learned over time sped up the process, like:

• Pin knife on top guide, press steel ruler edge against the knife, and then rotate ruler to align with bottom guide. This is far faster than just moving the no-slide ruler atop the paper by hand to align with both guides simultaneously.
• Try to get the knife’s edge as parallel with the paper as possible. This results in a deeper and easier cut than if the knife is perpendicular to the paper.
• After cutting, fold the paper along all cuts as a paper page overall instead of just starting to peel out individual cards. By folding both ways along each cut, separation was sped up since multiple cards shared each fold.

Step 5: Punching Holes

With the 1/8 inch hole on each card’s front side, it was easy to precisely cut a hole with a 1/4 inch hole punch by aligning the puncher circle’s bottom edge with the printed circle’s bottom edge. I even started doubling up cards with confidence since the cuts had been so exact.

Step 6: Clean Up

Yeah, there’s alot of extra scraps that result, thrown to the floor as each page is cut. I’ve not completed that step yet.

So there you go, 160 “trading” cards for placing page patterns on the poster. Should be fun! See you at the IA Summit in Miami later this week…

Tonight I just completed the Instant Deliverable Mix poster for the 2008 IA Summit, which presents a thumbnail gallery of page patterns under a blank deliverable, and explanations of page patterns, recipes, and practical tips on the periphery. Even better, visitors to my poster will be able to unhook page pattern cards and actually create the deliverable themselves in real time (thanks EightShapes staff for the ideas)! Should be a fun time, and I look forward to feedback from the community.

Once a library is discovered, information architects can collaborate with other disciplines to organize the library, build out relevant assets, document the taxonomy and guidelines on usage, and ultimately publish and promote adoption of the library when it’s ready for prime time.

Such discovery can emerge from a range of activities, which include:

• During Design: Creating a component-based design solution can lead to numerous efficiencies during the design process. That said, it is very difficult to realize a formalized, long-term component library during rapid design cycles that push towards implementation. The library discover process includes an evolution of the components themselves as well as the classification model that organizes them. Such efforts can derail a project’s process and focus, or simply be abandoned as deadlines approach.
• Analyzing a Design System: A designer familiar with a design system approach and component strategy can independently assess that design system to recommend a component library. Beginning with independent research of a production system based on scope defined by the organization, the designer can apply their own knowledge along with best practices to identify reusable components in context.
• Workshop Exercises: Nothing beats the energy of getting a team together to mutually decompose an existing design system and arrive at a component library together. From information architects to visual designers, from coding technologists to site strategists, from ux leads to directors, the more you involve, the easier you gain consensus and create a baseline for adoption and practice over time. Eightshapes has facilitated numerous component discovery exercises for teams large and small; at a high level, teams slice up screenshots with scissors, organize the multitude of variations, and work on grouping, labeling, prioritizing, and archiving the results. All the while, individuals work together to discuss assumptions and clarify component roles and approaches with EightShapes experts.
• Code Architecture: Often, a component library may be derived from an implemented code base, content management system, or other technical architecture. While there may be incongruities with the preferred modularity of the user experience, there are numerous advantages to adopting a technical baseline as the foundation for the library, including shared nomenclature and implicit buy-in from the technical team(s).

Up until now, nearly all wireframes are composed as a combination of many independent “objects,” those vector-based descriptions of a shape (e.g., gray outline box or drop down menu or popup icon) or text (e.g., “Submit” or “Spotlight Title”). By independent, I mean that each one is constructed and managed separately on the canvas. For complex UI, this becomes a vast array of overlapping anchors and segments that become more and more difficult to manipulate.

However, as my fluency in Adobe InDesign CS3 has increased, I’ve become more adept in utilizing three key features that simplify the complexity of component layout: inline objects inside objects, text wrapping, and greater use of tab stops and alignment.

Inline Objects Within Objects

InDesign enables you to paste not only text within an object’s frame, but also other objects. Therefore, you can flow text and objects (such as form elements, buttons, icons, or other simple elements) together and control alignment, spacing, and other attributes globally or by line.

In the screenshot displayed here, the example on the left shows the “old school” approach, with independent object frames for each label, each dropdown, and the title label. Painful to update if you are trying to change the format of all labels at once, or align them with form elements, or other manipulations.

On the right, a single “padded” container object (with gray stroke and 10pt padding on all four sides) contains a single inline series of labels and dropdowns. Granted, the dropdowns are sized specifically for this container width. But the text is far easier to type across fields, and after each label a simple CTRL-X pastes yet another dropdown. With a bit more familiarity with the Direct Selection tool (shortcut: A), you can even reach into the object frame and manipulate the dropdowns - objects within objects. No doubt this is a cleaner representation of the same content, both for creation and maintenance.

You can also explore making that container object have 2 or more columns and start using column breaks - then things get really fun!

Tab Stops & Alignment

So how about that text for every other month? Is that accomplished via a healthy dose of the spacebar? Nah, tab stops.

Opened via a shortcut (CTRL-SHFT-T), the overlaid tab ruler enables you to add tab stops easily to a single line of text. In this case, I wanted center-aligned stops for each month, more precisely aligning each stop with the embedded object below it. No problem - select the Centered icon, then click (and drag if necessary) for each stop. Once complete, close the Tabs dialog, and type & tab to your hearts content.

Such tab stop configuration is especially helpful for creating tables without tables, such as a checkout price summary where both the label and dollar value are right aligned. Using the tab ruler is far quicker for a set of 6 or 7 lines in that format than creating (and extensively deformatting) an InDesign table.

Not All Objects Go Inline

In some cases, it may be easier to overlay an image as an object separate from the object containing the text. With that approach, you can apply text wrapping attributes to the image so that the text in the container below will wrap / space appropriately.

In the example on the left, individual objects are used for the header, descriptive text, image, container, and learn more link. Ugh, so much manipulation. On the right, all text is embedded in a container object, and the image object is overlaid with text wrapping attributes so the text formats correctly.