As one of the primary deliverables for information architects, wireframes represent a crucial stage in the

design process. Until wireframes, the final product has not been represented in a concrete way and therefore

they tend to generate a lot of discussion. One key element of wireframes is how data and information is represented. Since the wireframe is meant to show possible layouts for the display, it necessarily includes examples of the information users might find on the pages or screens.

Typically, the sample data and information in wireframes motivates much of the discussion around these

deliverables, since stakeholders and designers are seeing the data in action and in context for the first time.

At a stage in the design process where the requirements should be final, the wireframes open up new issues and

may force the team to revisit the scope of the project.

Different representations of sample data or example information in the wireframes can influence the direction

of these discussions.

Purpose

The purpose of using wireframes is to document and concept a vision for the ” to be” as a visual narrative and abstract documentation. By exploring these different approaches, the poster will help IA’s identify their own strategies for developing their deliverables.

Contents

The poster will describe five different ways of representing data in wireframes, comparing the pros and

cons of each approach. For each approach, the poster will identify the implications for different audiences, like

visual designers, business owners, and technologists, and questions each might ask.

Examples:

Background

As one of the primary deliverables for information architects, wireframes represent a crucial stage in the design process. Until wireframes, the final product has not been represented in a concrete way and therefore they tend to generate a lot of discussion.

One key element of wireframes is how data and information is represented. Since the wireframe is meant to show possible layouts for the display, it necessarily includes examples of the information users might find on the pages or screens. Typically, the sample data and information in wireframes motivates much of the discussion around these

deliverables, since stakeholders and designers are seeing the data in action and in context for the first time. At a stage in the design process where the requirements should be final, the wireframes open up new issues and may force the team to revisit the scope of the project.

Different representations of sample data or example information in the wireframe can influence the direction of these discussions.

Purpose

The purpose of this poster is to catalog different ways of representing sample data in wireframes. By exploring these different approaches, the poster will help IAs

identify their own strategies for developing their deliverables.

Contents

The poster will describe five different ways of representing data in wireframes, comparing the pros and cons of each approach. For each approach, the poster will identify the implications for different audiences, like visual designers, business owners, and technologists, and questions each might ask.

What liked the most about playing with the old controllers was that fact that they just never seemed to fail as compared to today’s modern controllers. The controller I use for an Xbox 360 feels like it has a serious case of arthritis.

While playability and human factors are important in gaming controllers the industry is now realizing that the controller is not just an extension of the human form, it is just getting in the way of human to game interaction. The controller will die similarly like the mouse and keyboard and will be replaced by more natural systems that use gestures, touch interfaces and speech recognition systems to manage user input.

For major planning meetings consider printing at least one large diagram of the site organization, so that everyone can see the big picture as it develops from meeting to meeting. The site diagram should dominate the conference table, becoming a tactile, malleable representation of the plan. Everyone should be free to make notes and suggest improvements on the printed plan, and the revised diagram becomes the official result of the meeting.

Site diagrams

As your team works out the information architecture and major categories of content, site diagrams visualize the developing information hierarchy and help communicate the organizational concepts to the team and to stakeholders and project sponsors. This communications role is crucial throughout the project, as the site diagram evolves in iterations from a brainstorming and planning document into a blueprint for the actual site as it will be developed.

Site diagrams can range from simple hierarchical “org chart” diagrams to more complex and information-rich maps that show both the major divisions of the site as the user experiences them, but also act as an overview of the site directory and file structure. The well-known information architect Jesse James Garrett developed a widely used visual vocabulary for site diagrams that has become the de facto standard, and the symbols are broadly useful for portraying site structure and interactive relationships and user decision points (fig. 3.10).

Major elements of a mature site diagram include:

• Content structure and organization: major site content divisions and subdivisions
• Logical functional grouping or structural relationships
• The “click depth” of each level of the site: How many clicks are required to reach a given page?
• Page type or template (menu page, internal page, major section entry point, and so on)
• Site directory and file structure
• Dynamic data elements like databases, rss, or applications
• Major navigation terms and controlled vocabularies
• Link relationships, internal and external to the site
• Levels of user access, log-ins required, or other restricted areas

Site diagrams start simply, and may evolve into two distinct variations: conceptual site diagrams that communicate at a general level the evolving site structure to clients and stakeholders, and more complex blueprint diagrams that are used by the technical, editorial, and graphic design teams as a guide to the structure of both the user interface and the directories and files.

Figure 3.11 depicts a simple site diagram for use in presentations and general overviews and the same site shown in greater detail for use by the site development team. These site diagrams can be developed with drawing software such as Adobe Illustrator but are usually developed with specialized diagrammatic software such as Microsoft Visio, ConceptDraw, or OmniGraffle.

Site file and directory structures

Site diagrams are also useful when your project moves from planning to web page production. As the new site is built up in a directory on the web server, the site diagram is often the first place programmers look to gain an understanding of how the site files should be subdivided into directories (folders) on the server.

Wireframes

The information architecture process is fundamentally one of avoiding the particular while insisting on the general. At various points in this conceptual phase, stakeholders, clients, and even members of your design team may find it irresistible to launch into specific proposals for the visual design of pages. In particular, concern about the possible look and feel of the home page is notorious for throwing planning processes off the rails and into detailed discussions of what colors, graphics, or general character the home page should have, long before anyone has given serious thought to the strategic goals, functions, and structure of the site. Wireframes force teams to stay focused on the information architecture and structural design without getting sidetracked by the distraction of the visual layer.

If site diagrams provide the global overview of the developing web site, then wireframes are the “rough map” that will eventually be used by graphic and interface designers to create preliminary and final page designs for the site. Wireframes are rough two-dimensional guides to where the major navigation and content elements of your site might appear on the page.

Things that might appear as standard elements of a web page wireframe include:

• Organizational logo
• Site identity or titles
• Page title headlines
• Breadcrumb trail navigation
• Search form
• Links to a larger organization of which you are a part
• Global navigation links for the site
• Local content navigation
• Primary page content
• Mailing address and email information
• Copyright statements
• Contact information

To keep the discussion focused on information architecture and navigation, keep your wireframe diagrams simple and unadorned. Avoid distinctive typography, use a single generic font, and use gray tones if you must to distinguish functional areas, but avoid color or pictures. Usually the only graphic that appears in a mature wireframe will be the organization logo, but even there it may be better simply to indicate the general location of the logo.

The page wireframe will acquire more complexity as your thinking about global and local navigation matures and you are more certain about the nature and organization of the primary site content.

Canonical form in web pages: Where to put things, and why

What governs how people scan pages of information, print or screen? According to classical art composition theory the corners and middle of a plane attract early attention from viewers. In a related compositional practice, the “rule of thirds” places centers of interest within a grid that divides both dimensions in thirds. These compositional rules are purely pictorial, however, and are probably most useful for displays or home pages composed almost entirely of graphics or photography. Most page composition is dominated by text, and there our reading habits are the primary forces that shape the way we scan pages. In Western languages we read from top to bottom, scanning left to right down the page in a “Gutenberg z” pattern.

Eye-tracking studies by the Poynter Institute of readers looking at web pages have shown that readers start their scanning with many fixations in the upper left of the page. Their gaze then follows a Gutenberg z pattern down the page, and only later do typical readers lightly scan the right area of the page (fig. 3.15a). Eye-tracking studies by Jakob Nielsen show that web pages dominated by text information are scanned in an “F” pattern of intense eye fixations across the top header area, and down the left edge of the text (fig. 3.15b).

Figure 3.15 — Eye-tracking studies show that our page- scanning patterns are dominated by top-left scanning for the most important words and links on a page.

When readers scan web pages they are clearly using a combination of classic Gutenberg z page scanning, combined with what they have learned from the emerging standards and practices of web designers. As the web nears its twentieth anniversary some clear trends have emerged that will eventually form the basis for “best practice” recommendations in web page composition. Human interface researchers have done studies on where users expect to find standard web page components and have found clear sets of expectations about where some items are located on web pages.

The web is still a young medium with no standards organizations to canonize existing typical page layout practices. Until we have a Chicago Manual of Style for the web, we can at least combine current mainstream web design practice, user interface research, and classic page composition to form recommendations for the location of identity, content, navigation, and other standard elements of pages in text-dominant, information-oriented web sites (fig. 3.17).

What does MRI stand for?
Mixed Reality Interface is a combination of digital content with real objects.

Why is the MRI innovative?
What makes the MRI innovative is that everyday objects can be used. An adhesive label is stuck to the bottom of the desired object and it can thus be used for operating a computer.

Can free form surfaces be ordered as the navigation surface?
Round, rectangular and other shapes are available.

“Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn’t explain how the interface is intended to work.”

What kinds of interfaces can you prototype?

Paper prototyping can be used for virtually any type of human-computer interface – software, Web site, hand-held device, or even hardware. Its purpose is to get quick feedback from users while the design is still (literally) “on the drawing board.” Some paper prototypes are hand-drawn, while others use printed-out screen shots.

How is paper prototyping related to usability testing? The above definition of paper prototyping overlaps with usability testing, but the two concepts are not quite the same. It’s possible to conduct usability tests on real interfaces, not just paper prototypes. And paper prototypes can be used for purposes other than usability testing – some product teams find them helpful in generating design ideas and conducting internal interface reviews.

What skills do you need? You do not need to be a graphic artist or software engineer to create a paper prototype, though those skills might come in handy when you’re ready to build the real thing. If you have ideas for your interface and can draw them – rough sketches will do – then you can create a paper prototype.