Boxes and Arrows: Stories by Stephen Turbek

The Lazy IA's Guide to Making Sitemaps

Stephen Turbek — Mon, 30 Jan 2006 08:33:06 GMT

"I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities. ... So what is an IA to do?"

This article further develops the excellent Automating Diagrams with Visio by Michael Angeles.

Sitemaps are common deliverables, desired by clients who want a visual representation of a site. Since they are rarely used to make decisions, information architects may not consider them the valuable tools they are. The effort required to make and maintain them requires time that might be better used elsewhere. In fact, I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities. Especially when your sitemap looks like this. So what is an IA to do? Turn to Excel, of course. Storing sitemap data in a structured data format such as Microsoft Excel makes the data easy to edit, easy to share with the team, and easy to elaborate on (e.g., adding example notes and URLs that may not be appropriate for the map itself). Unfortunately, this approach requires maintaining a spreadsheet in addition to maintaining the visual sitemap. Or does it? This article includes step-by-step instructions on how to make sitemaps with: 1. Excel and Visio 2000 or Visio 2003 (Windows only) 2. Word and Inspiration (Mac OS and Windows) Use these lazy techniques and spend your time on better and more interesting problems than lining up little boxes!

Techniques

I’ve chosen these three options because they use standard applications that store the sitemap data in a format that can be edited by non-IAs. Each option demonstrates how you can store the data in the first format (Excel or Word) and import it into the second program (Visio or Inspiration) to—Voila!—create the sitemap.

You can use this zip file to access all the templates referenced in this article. I suggest doing the exercise once with the sample file to get the hang of it, then editing that file to your needs. The Excel spreadsheet has been written to do some semi-fancy calculations to let you store your data on the import sheet in a nice format and to output Visio-readable data on the output sheet.

Tips
1. Only edit data on the Input page. 2. Eliminate blank rows in the middle of your data. 3. The top sitemap box must be in field A2. 4. The template is defined for up to 200 elements

Technique 1: Excel and Visio 2000 / 2003

This approach uses the import data feature of Visio 2000 (Note that this feature has been removed in Visio 2003) and (mis)uses the “Organization Chart Wizard” from Visio 2003. You store and manage the sitemap data (the list of links in a structured organization) in Microsoft Excel, save it as a text file, and import it into Visio for quick visualization.

Step 1: Enter your sitemap data in the “Input” sheet in the file "template_for_visio_2000_and_2003.xls."

For Visio 2003, proceed to the variation below. Step 2: Go to the “Output for Visio 2000” sheet (and pay it no mind).
Save as Type “Text (tab delimited)."
You will see two alerts. Click OK and Yes.
Close the file. You may get the alerts again, hit "OK" and "Yes." Closing the file is actually important! Step 3: Open Visio 2000. Click "Open." Choose Files of Type “Text (.txt, .csv)." Choose the file you just saved.
Step 4: When the dialog box pops up, set Field separator to [Tab] Text Delimiter to “Comment Character to ;. Click "OK."
Step 5: A sitemap! Edit your sitemap to suit your fancy.

Variation for Visio 2003

Step 2: Click on the Sheet tab “Output Visio 2003” (and pay it no mind). Save the Excel file and close it.
Open Visio 2003. Select the “Organization Chart Wizard.”
Step 3: Select “Information that is stored in a file or database.” Click “Next.”
Step 4: Select “A text, Org Plus (*.txt), or Microsoft Excel file. Click “Next.”
Step 5: Find the demo file included with this presentation “example_visio_2003.XLS.” Click “Next.”
Step 6: Leave these defaults. Click “Next.”
Step 7: Remove “Title” as a displayed field. Click “Next.”
Step 8: Ignore the Custom Property fields (though you might be able to think of some use for the other fields in some interesting way). Click “Next.”
Step 9: You can make sitemaps that span multiple pages. Choose “specify.” Click “Next.”
Step 10: This allows you to define the top Sitemap box on the page. If you follow the Excel template, you can leave this alone. Click “Finish.”
Step 11: A sitemap!
Step 12 Right click on the sitemap to edit properities.
“Arrange subordinates” changes the sitemap layout. "Change Position” changes the look of the boxes

Technique 2: Microsoft Word and Inspiration

This (mis)uses the flowcharting tool Inspiration. To do so, you format the sitemap in Microsoft Word outline format, save it as a RTF document, import it into Inspiration, and modify the diagram to look like a sitemap. The outline format can also be created directly in Inspiration, but storing the data in Word allows you to better collaborate with coworkers and clients.
Step 1: Outline your sitemap using Microsoft Word’s Outline format. Save it as a RTF file. (Step 1 is optional: you can make the outline in Inspiration, but some users may wish a more accessible format, like Microsoft Word.)
Step 2: Open Inspiration. Create a new file. Open the RTF file. Step 3: Inspiration converts the RTF file to its own format. You may have to do some minor editing to remove blank rows, as shown above. (See image 26)
Step 4: Click the ”diagram” button at the upper left. What a mess! But click the “arrange “ button…
Step 5: Select diagram type “Top down Tree” and Lower level stacking option “Right."
Better arranged, but visually lacking.
Step 6: Select all then click the rectangle in the menu bar. Now you can do things like take off the drop shadow, change the fill color to white, change the line color, etc.
A sitemap!
Working hard, hardly working Sitemaps can be useful tools and are a whole lot easier when you separate the data from the visualization. After you have done these steps a few times, you will be able to update a sitemap in under a minute. All these techniques can be expanded and improved upon. Let me know what you have done and what works for you. Have fun, but don’t work too hard! Downloads This article references the following downloads: Templates referenced in article (Visio, Inspiration, Excel) For more information This article includes step-by-step instructions on how to make sitemaps with: Excel and Visio 2000 or Visio 2003 (Windows only) Word and Inspiration (Mac OS and Windows) Downloadable excel Site Map Thanks to Jon Stuckey and Marcia Stanton.

Real Wireframes Get Real Results

Stephen Turbek — Tue, 19 Sep 2006 14:01:09 GMT

“Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra.”

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

Wireframe tests usually take place with well-meaning, but unsophisticated users. They generously accede to poking and prodding and answer questions as best they can, despite not exactly understanding what is wanted. This realism gap is due to the lack of definition of what should and should not be looked at. “Look at the field names but not body copy.” “You can look at the forms but not images.” “Comment on the page layout but not design, and, yes, the font size but not font.” It’s no wonder that the layperson is confused.

Visual affordances, such as color and underlining links are key to using a site, and these cues make a significant difference in a usability test. Users cannot confidently predict how they would use a page if they don’t recognize links or can’t read what the page expects them to. Information architects, however, tend to shy away from these cues because they don’t want to step on designers’ toes. Wireframes, after all, are not designs.

Or are they?

Avoiding “design” elements removes visual cues that users rely on:

* Color, which identifies hyperlinks and focuses the user’s attention on an element of the page * Branding, which confirms that the user knows where they are * Recognizable web page elements, such as forms and search fields * “Content,” such as account numbers or product names, which allows experienced users to focus on how they would really use the page, instead of interpreting “lorem ipsum”

The boundaries of the role of the information architect shouldn’t be more important than clarity.

Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Why wireframes?
Information architects construct wireframes instead of designing final pages, in part, because:

# Wireframes are faster. # Information architecture and design phases can happen in parallel. # Wireframes force viewers to focus on the content, not the visual design.

Notice anything? All these goals are internally focused on the project-team. Wireframes aren’t created for external audiences.

Figures 1,2: Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Wireframes are conceptual models of a page that web design teams have become to interpreting. Each wireframe is surrounded by experience in reading them, knowledge about the project scope, knowledge about how the designer will use the document. Liz Danzico writes about this wireframes becoming project memory in the article “The Devil’s in the Wireframes.”

Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra. Likewise, the test subject knows only that “the page isn’t going to look like what they see,” but what they see is all they have to react to.

Wireframe makeover
Here is an example of the simple steps to transform a standard wireframe into a realistic wireframe. In this example, let’s say we are designing a registration process for Verizon.com (no special criticism is intended for the site below).

The site we are designing for Verizon.com:

Here is a standard wireframe:

And here is the same wireframe, made more real. (An additional 10 minutes was required to use the standard header and a library of realistic form elements in Visio or InDesign.)

And here is a version re-using Verizon’s standard buttons and clip art. (Additional time: two minutes.)

Which do you think would be easier for test subjects to understand?

Tips to get real
These tips are best for intranets or sites with defined styleguides, and less useful for graphical or marketing pages where the design is the content of the page.

# Make a header bar with the company branding. It should look like the site they are used to, showing the company logo. # Use color. Hyperlink color is a basic requirement. # Put a web browser frame around the image (or at least the first page). # Use real form elements, not drawn replicas of them. # Create a template or library of real form elements (feel free to share yours in the comments below). # Avoid lorem ipsum. Instead, use: “Descriptive text that will explain this product.” to avoid confusion about greeked text. # Use accurately sized fonts (this also keeps you honest about what can fit on the page). # Use real detail such as products names and data. Especially on transactional tools with expert users, users care about what they are reading and recognize and use data like account numbers. It may not be important to us, but they have expectations that need to be met.

Compare the wireframe to the current site, note any changes in functionality that may trip them up.

The page doesn’t have to be perfect, just enough to give the test subject their bearings. A semi-designed page is easier to understand than a non-designed page. This is not wasted work; these decisions need to be figured out at some point. Consider bringing designers into the process earlier, cooperating on file formats and processes. It might even make their jobs easier.

Are traditional roles limiting projects?
Wireframes are in fact the first design iteration, and this overlap with visual design can be uncomfortable for teams. However, denial is not the way to fix this issue. Good collaborative relationships should make this overlap an opportunity to reduce work, not fight over ownership. Concern that wireframe might be mistaken for a visual design, or worse, be criticized for lacking design, may be holding the entire project back. It is much easier to communicate within the project team than the outside audience.

Consider these and other ways to make the transition as smooth as possible, for example, by having the wireframe be designed to import into the designer tool without retyping all the text.

Advancing Advanced Search

Stephen Turbek — Wed, 16 Jan 2008 16:29:32 GMT

Advanced search is the ugly child of interface design -always included, but never loved. Websites have come to depend on their search engines as the volume of content has increased. Yet advanced search functionality has not significantly developed in years. Poor matches and overwhelming search results remain a problem for users. Perhaps the standard search pattern deserves a new look. A progressive disclosure approach can enable users to use precision advanced search techniques to refine their searches and pinpoint the desired results.

Fig. 1: A typical separation of standard and advanced search (Yahoo!). The design discourages use of advanced search.
In the quest to make web sites more usable, we settled on a pattern of a clean, minimal search box with a link to an advanced search page. Jakob Nielsen recommended, “use an intimidating name like ‘advanced search’ to scare off novice users from getting into the page and hurting themselves.”(1) This model has been successful. Search rivals hierarchical website navigation on many sites and is the primary means of navigation on enormous sites such as Ebay and Amazon. Advanced search, however, has not fared so well, with only a small percentage of users using it.

Why most people don’t use advanced search

Despite its name, advanced search has not advanced very far. There is great power to conquer the overwhelming number of search results, but the current standard presents barriers to users. Specifically,

The link is often small, vague, and does not describe benefits to the user
Advanced search pages typically have confusing page design for the few who make it there.
There is generally poor search revision functionality: Once a search is performed, the “advancedness” is lost. For example, the Google advanced search delivers the standard search results page. You have to get the query right the first time; there is no opportunity to adjust your query.

Fig. 2: Google’s advanced search is still complicated.

Who does use advanced search?

Tim Bray wrote, “The people who do use Advanced Search are your most fanatical users, the professional librarians, spooks, and private investigators.”(2) As in many situations, segmenting a population makes it harder to see whether the needs of a subgroup are shared by the majority. Current design is based on the idea that there are two separate audiences with distinct needs. The reality is that there are overlapping needs that are limited by the search pattern.
The essential problem of search — too many irrelevant results — has not gone away.
A typical user has to make a choice between doing a search and clicking a link to do a search. In other words, do you want it now, or want to go somewhere else to look? The immediacy of the search text field and the complexity of advanced search means that users will try the text search first.
Perhaps the old framing is wrong. Rather than being a matter of geeks versus normal people, the question should be whether users see a benefit to advanced search on starting. Unfortunately, there is typically no way to use advanced search at the point users realize they need it — when they haven’t found what they were looking for and have too many search results. They have “missed the exit” to advanced search. Users don’t want to lose the investment in their search; they need a way to use additional techniques to work with what they have. A new model of search can help with this problem.

Other approaches to search
Let’s take a quick look at other search innovations from the last decade. Web data has matured and become more structured. Taxonomies and tagging are now common. There are new opportunities to deal with search results overload by filtering, as long as it is clear and easy for the audience. Despite the truism that users will not go past the first page of search results, they will use obvious tools to refine their searches.

Searching by defined parameters is natural in some circumstances (for example, airline ticket searching) but the majority of sites are not sufficiently data-driven to have an interface designed around the data.

Fig. 3: travelocity.com Flight searches, in a sense, only use advanced search.

Tags can improve search results by better describing what someone is seeking.

Fig. 4: amazon.com’s approach to tagging a product

Faceted searching, or returning browsing categories in the search results (as eBay does) can be effective at prompting the user to select a single category.

Fig. 5: ebay.com’s faceted search

Filtering search results

Amazon and Kayak offer filters to enable users to reduce many results to a few. This can be very effective, but there are obvious constraints due to the limited space available for each filter. Only the first few filters are visible when the page loads.

Fig. 6: Filtering on amazon.com and Kayak

Another approach: Progressive disclosure of functionality
One solution to the essential problems of advanced search discoverability and complexity is to progressively disclose (3) the functionality to the user. Instead of a single, complicated page, break it into understandable units and give each to the user when they ask for it.
In this example, show the ways the user could filter the results (e.g., “Brand” or “Price”) in a highlighted banner above the search results.

Fig. 7: Filters highlighted in a banner (it doesn’t have to be green, it just has to stand out!)

When the user clicks a link, display the filter with enough space to clearly articulate how to use it. Don’t cram it in; the user asked for it. In contrast to the left-hand column filters in the examples above, which are naturally space-constrained, this method can hold many more types of filters and doesn’t show functionality they didn’t request.

Fig. 8: When the user clicks "price" above, give the module enough space to be readable.

Let’s look at an example scenario.

1. The user performs a text search normally.

Fig. 9: Searching for a DVD player using the simple search box

2. On the search results page, show options to filter the search in a prominent location above the results. Communicate the value of filtering. Order them by popularity, using size and font weight to highlight others. If there are many options, consider hiding rarely used options under an expandable section.

Fig. 10: A search results page, with options to filter.

3. When the user clicks an option, display a page module for that search parameter without reloading the page. The user should be able to change the parameters at any time to receive an updated search. If possible, show the number of results for each parameter, so the user can see how exclusive it is, and identify which parameter maybe giving them 0 results.

Fig. 11: The search results, filtered by price.

4. Enable the user to add several modules, stacked in chronological order as the user builds up a complicated query.

Fig. 12: The search results, filtered by price and rating.

Recommendations
Define an implicit method for Boolean rules (AND and OR rules) based on normal search patterns — do not ask users to compose Boolean queries. A system that has worked for me is this: If a user selects several different search parameters, perform an AND search between them (e.g., Sony AND Portable). If they choose multiple values for the same parameter, perform an OR search (e.g., Sony OR Panasonic). However, if parameters (such as product features) are clearly non-exclusive, perform an AND search (e.g., Portable AND “HD ready”).

Recognize that quick searches, text searches, and advanced searches may be built with different technologies (e.g., direct database searches, a Google box, or a content management system). You may need to work closely with the developers to make a seamless transition between technologies.

If there are many parameters (more than 15), consider reducing complexity by hiding less used ones under a “see more…” link below the displayed options. Clicking it should display all the options without a page refresh. Evaluate your search logs to make sure you are exposing the right ones. Consider rotating the exposed ones to discover potential popular features, as exposed options will naturally get more usage.

Conclusions
At its core, advanced search is an under-utilized tool hampered by its own design. By enabling the user to add specificity as they request it, designs such as the one above avoid the lonely fate of the standard advanced search page. Defusing this complexity and locating it where users will naturally find it will help advanced search be truly advanced.

References
(1) Nielsen, J. (1997). Search and You May Find. Alertbox, July 15, 1997.
(2) Bray, T. (2003). On Search: The Users.
(3) Wikipedia. Progressive Disclosure