Axure RP 6 Prototyping Essentials

Axure RP 6 Prototyping Essentials RAW Book Creating highly compelling, interactive prototypes with Axure that will imp...

Author: Ezra Schwartz

56 downloads 887 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Axure RP 6 Prototyping Essentials RAW Book

Creating highly compelling, interactive prototypes with Axure that will impress and excite decision makers

Ezra Schwartz

BIRMINGHAM - MUMBAI

Axure RP 6 Prototyping Essentials Copyright © 2011 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Current RAW Publication: October 2011

RAW Production Reference: 2071011

Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-849691-64-2 www.packtpub.com

About the Author Ezra Schwartz is an information and user experience architect, who specializes in logistics of complex user interface frameworks. He focuses on device and locale agnostic global enterprise applications, team collaboration strategies, UX requirements traceability and specification documentation forphased, multi-release projects.

Ezra helps clients to integrate successfully rapid UX prototyping, validation and testing with their development culture.He assists clients with adoption of user-centered-design methodologies, compliance and best practices. He has led mission-critical user experience projects in the finance, aviation, healthcare, mobile, publishing, media research, manufacturing, academic research and software development industries. Ezra also provides his services pro-bono to select non-for-profit organizations. Ezra is the founder and organizer of AxureWorld.org, a free community-driven international conference, dedicated to rapid UX prototyping. He talks regularly about user experience topics at conferences and on his blog www.artandtech.com.

Table of Contents Preface Chapter 2: Axure Basics—the User Interface

1 7

Getting Started Axure File Formats

7 9

The .RP File Format (Stand-Alone) The RPPRJ File Format (Shared Project) The RPLIB Format (Axure RP Libraries) Format Comparison Table

9 9 11 11

The Workspace Customizing the Workspace The Wireframe Pane

12 13 13

Grid and DPI Settings Guides

14 15

The Sitemap Pane

15

Wireframe Pages

16

The Masters Pane

16

What is a master Master Behaviour Usage Report

16 18 21

The Widgets Pane

22

What is a Widget Wireframe Widgets Flow Widgets Create your own widget library 3rd Party widget libraries

22 23 27 28 28

The Widget Properties Pane

28

Annotation Tab Interactions Tab Formatting Tab

29 33 36

The Page Properties Pane

38

Page Notes Page Interactions

38 39

Table of Contents Page Formatting

39

The Dynamic-Panel Manager

40

Overview What is a Dynamic Panel The Menu Bar

40 42 47

Summary

47

Chapter 3: Prototype Construction Basics

49

Principles The Demonstration Project

50 50

Digital Library Project, Phase 1: The Proof of Concept

51

Getting Started Productivity in 30 minutes Initial Requirements and Use Cases Use Case Diagram Page Saving the Project File First Wireframe Pages Task Flow Diagram Page

52 53 54 57 58 59

Browse Path Flow Diagram Search Path Flow Diagram

60 61

Link Use Cases to Flow Diagrams Generating HTML Prototype Getting Started – Part 2 Navigation Systems

63 64 66 68

Main Global Navigation Bar

69

First Masters

71

First Custom Page Style Secondary Navigation System

74 76

First Dynamic Panel

77

Dynamic Panel States

79

Wiring Navigation Systems

83

Adding Visual Effects Apply Group Selection

85 87

Update Task Flow Diagrams Summary

88 89

Chapter 4: Interactivity 101

91

Overview

91

The 1950-60s The 1970s The 1980s The 1990-2000s The 2000s The Present, Future, and Axure Interactions

92 93 94 95 96 97

Understanding Axure Interactions Anatomy of Axure Interactions Axure Events

98 98 100 [ ii ]

Table of Contents

Event Triggered By Pages and Masters Changing the Default Landing Page Selected State and Contextual Navigation More Context with OnPageLoad Events Page and Master Event Flow

101 101 103 105 106

User Triggered Events

107

Back to the Requirements Simple Events: Adding OnMouseOver State Construction Considerations Widget Event Flow Contextual Widget Events

108 109 111 111 112

Axure Cases Demo Prototype Example

113 114

The requirements Construction Considerations Construction with UI Specifications Document In Mind Adjusting the Wireframes

Axure Actions Links Actions Dynamic Panel Actions Widgets and Variables Actions Miscellaneous Actions Back to Example: Wiring the Cases for the 'Sign In' Link

114 115 116 116

119 119 119 119 120 120

Taking a Wrong Turn… What's In A Name? Masters and Interactions Back On Track Devil in the Details The Username Password Popup

121 122 125 125 126 126

Naming Conventions Benefits The Anatomy of a Page ID

130 130 130

Masters ID Dynamic Panel ID State ID Nesting Widgets IDs Summary

133 133 133 134 135 137

Chapter 5: Advanced Interactions

139

Conditions Example

140 140

The Objective

140

The Workstream Prefix Page Number Page Names

131 132 132

[ iii ]

Table of Contents Preparation Setting the Interaction with Conditions

141 141

Condition Builder Deep Dive

143

The Importance of Labelling The Condition Builder Window

143 144

Troubleshooting Conditions Raised Events Raised EventsDeep Dive ExampleThe Objective

148 149 149 149

Preparation Let’s try without using a Raised Event: Creating Raised Events, Part 1 – On the Master Creating Raised Events, Part 2 – On the Page

Raised Events in Action Variables and Functions Overview Create and Manage Variables

150 151 153 156

157 158 158 159

Manage Variables Dialog Set Variable and Widget Value Window

159 161

Initializing, Passing and Resetting Variables Step 2: Passing Variables Step 3: Resetting Variable Value

161 163 163

Variable Types

163

Global Variables Local Variables

163 166

Naming Variables

166

Axure Rules Variables Naming—Best Practice

166 167

Functions Variables and Usability Testing

167 168

Example: Closing the Identity Gap

169

Variables and Prototype Construction Variables and Localization

175 176

Example

176

Pros and Cons of Using Variables

178

What Was I thinking? Specifications

178 178

Summary

179

Chapter 6: Managing Patterns with Widget Libraries

181

Masters and Widget Libraries Built-In Libraries Community Libraries Your Own Widget Libraries Create a New Widget Library

183 184 185 186 187 [ iv ]

Example 1: A Lorem Ipsum Widget Example 2: A Vertical Scroll Bar Widget Example 3: A Dialog Box Widget Example 4: An Incremental Search Widget

Managing Widget Libraries Masters and Widget Libraries Revisited Managing Visual Design Patterns From Low to High Fidelity Prototypes—Strategies Prototype with Existing Visual Design Apply Visual Design to an Existing Prototype

188 190 193 195

202 204 205 206 206 210

Summary

210

Chapter 7: Managing Prototype Change

211

Transition to Reality Align Expectations Development Models

212 212 213

Waterfall Agile

Estimating Your Axure Work Calculate Your Time

Align Expectation with Education Align Expectations for Prototype Granularity Align Expectations for Detailed UI Specifications From Concept to Detailed Design From Sketch mode Toggle sketch effect in the html prototype: Hide Sketch Effect on the Page:

Foundations and Scaffoldings Determining Wireframe Width Guides The Grid

Page Templates Page Style Editor

Widget Style Editor Default Widget Styles Style Painter Pros Cons Integrating with the Project Style Guide and CSS The Style Guide Axure Custom Styles From Style Guide to Axure Custom Styles

To Sync or Not To Sync (with the Visual Design)? Change Control

213 214

216 217

218 219 219 219 220 221 222

223 223 226 230

231 232

235 236 237 240 240 241 241 242 242

251 251

Chapter 8: Functional Specifications

253

Collaboration with the Development Team Capture UI specifications Global Specifications

255 257 258

Page Notes

263

Generators and Outputs: Specifications and Prototypes Customizing the Word Specifications Generator One Note Section vs. Many

259 262 265

Annotation Views Specifications and Construction Methods Generate Specifications The General Section The Pages Section The Masters Section The Page Properties Section The Screenshot Section The Widget Properties Section The Layout Section The Word Template Section Summary

269 271 271 271 272 274 278 280 282 284 285 288

Chapter 9: Collaboration

289

The Environment Check out/in statusSetup Shared Repository Loading From a Shared Repository The Share Menu

291 292 298 300

Create and Load Update Entire the Entire File Update Single Page or Master Manage Shared Project… Browse Shared Project History… Repoint to Moved Shared directory… Clean Up Local Copy…

Best Practices for UX Axure Teamwork Naming conventions for workstreams Feedback from Stakeholders – The Discussion Tab Step 1: AxShare Step 2: Setup the HTML Prototype Step 3: Discuss Summary

300 300 301 302 304 306 307

308 310 310 311 314 316 318

Preface Welcome to Azure RP6 Essentials, the RAW edition. A RAW (Read As we Write) book contains all the material written for the book so far, but available for you right now, before it's finished. As the author writes more, you will be invited to download the new material and continue reading, and learning. Chapters in a RAW book are not "work in progress", they are drafts ready for you to read, use, and learn from. They are not the finished article of course—they are RAW! User experience (UX) has gone mainstream. It is finally recognized by business and software development stakeholders as a critical pillar of social acceptance and commercial success. The timing coincides with an explosion in expressive means to create new and highly compelling user interfaces that operate on a wide range of powerful devices, such as smartphones and tablets. UX encompasses a wide range of disciplines including cognitive psychology, user research and visual design, and it all comes together in the prototype – an interactive simulation that excites decisionmakers and validates the design approach before it is coded. Boxes and arrows just don't cut it anymore. Axure, the leading UX tool for wireframing, rapid prototyping and specifications, has quickly become the UX tool of choice for thousands of practitioners worldwide. This book offers a holistic overview of Axure and its use throughout the interface development life cycle. The intent is to help you construct wireframes and prototypes with your 'headlights on' – taking into consideration the inherent iterative nature of the UX process. A sample project is weaved into the chapters. It provides an opportunity to discuss in context and in sequence practical topics such as addressing business and technical requirements, handling use cases and flow diagrams, low and high fidelity wireframe construction, naming conventions, creating interactions, writing annotations, generating detailed UX specifications and requirements traceability.

Preface

You may not be in a position to change how projects are scheduled, budgeted and managed, but hopefully, by the time you finish this book you will feel confident about adding Axure to your set of trusted UX tools. Based on my personal experience, I can promise you that it will enhance your ability to deliver topquality deliverables and tackle the demands for rapid iterative UX projects of any complexity and size, for any platform and device.

What's in this RAW book In this RAW book, you will find these chapters: Chapter 2, Axure Basics – The user interface...File formats, the workspace, wireframe pane, sitemap pane, masters pane, widgets pane, widget properties pane, page properties pane, dynamic panel manager, toolbar and menu bar. Chapter 3, Prototype Construction Basics... requirements and usecases, flow diagrams, navigation, masters, dynamic panels Chapter 4, Interaction Basics...Axure interactions, events, cases, actions, naming conventions. Chapter 6, Managing Patterns with Widget Libraries... masters and widget libraries, built-in libraries, community libraries, create your own widget library, managing libraries, managing visual design patterns, device specific libraries.

What's Still to Come? We mentioned before that the book isn't finished, and here is what we currently plan to include in the remainder of the book: Chapter 1,Prototyping Fundamentals Chapter 5, Advanced Interactions... raised events, variables, conditions, drag and drop, animation, Chapter 7,Managing Prototype Change Chapter 8, UI Specifications Chapter 9,Collaboration

[2]

Preface

Conventions In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning. Code words in text are shown as follows: "Using the CCGradientLayer class we can programmatically create gradients." A block of code will be set as follows: CCGradientLayer *gradientLayer = [CCGradientLayer layerWithColor:c cc4(61,33,62,255) toColor:ccc4(65,89,54,255) withDirection:CCGradientD irectionT_B width:480 height:100]; [gradientLayer setPosition:ccp(0,50)]; [self addChild:gradientLayer z:0 tag:TAG_GROUND_GRADIENT];

When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:

CCGradientLayer *gradientLayer = [CCGradientLayer layerWithColor:c cc4(61,33,62,255) toColor:ccc4(65,89,54,255) withDirection:CCGradientD irectionT_B width:480 height:100]; [gradientLayer setPosition:ccp(0,50)]; [self addChild:gradientLayer z:0 tag:TAG_GROUND_GRADIENT];

Any command-line input and output is written as follows: # cp /usr/src/asterisk-addons/configs/cdr_mysql.conf.sample /etc/asterisk/cdr_mysql.conf

New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen". Warnings or important notes appear in a box like this.

Tips and tricks appear like this.

[3]

Preface

What is a RAW Book? Buying a Packt RAW book allows you to access Packt books before they're published. A RAW (Read As we Write) book is an eBook available for immediate download, and containing all the material written for the book so far. As the author writes more, you are invited to download the new material and continue reading, and learning. Chapters in a RAW book are not "work in progress", they are drafts ready for you to read, use, and learn from. They are not the finished article of course—they are RAW! With a RAW book, you get immediate access, and the opportunity to participate in the development of the book, making sure that your voice is heard to get the kind of book that you want.

Is a RAW Book a Proper Book? Yes, but it's just not all there yet! RAW chapters will be released as soon as we are happy for them to go into your book—we want you to have material that you can read and use straightaway. However, they will not have been through the full editorial process yet. You are receiving RAW content, available as soon as it written. If you find errors or mistakes in the book, or you think there are things that could be done better, you can contact us and we will make sure to get these things right before the final version is published.

When Do Chapters Become Available? As soon as a chapter has been written and we are happy for it go into the RAW book, the new chapter will be added into the RAW eBook in your account. You will be notified that another chapter has become available and be invited to download it from your account. eBooks are licensed to you only; however, you are entitled to download them as often as you like and on as many different computers as you wish.

How Do I Know When New Chapters Are Released? When new chapters are released all RAW customers will be notified by email with instructions on how to download their new eBook. Packt will also update the book's page on its website with a list of the available chapters.

Where Do I Get the Book From? You download your RAW book much in the same way as any Packt eBook. In the download area of your Packt account, you will have a link to download the RAW book. [4]

Preface

What Happens If I Have Problems with My RAW Book? You are a Packt customer and as such, will be able to contact our dedicated Customer Service team. Therefore, if you experience any problems opening or downloading your RAW book, contact [email protected] and they will reply to you quickly and courteously as they would to any Packt customer.

Is There Source Code Available During the RAW Phase? Any source code for the RAW book can be downloaded from the Support page of our website (http://www.packtpub.com/support). Simply select the book from the list.

How Do I Post Feedback and Errata for a RAW Title? If you find mistakes in this book, or things that you can think can be done better, let us know. You can contact us directly at [email protected] to discuss any concerns you may have with the book. Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply drop an email to [email protected], making sure to mention the book title in the subject of your message.

[5]

Axure Basics—the User Interface This chapter provides a solid foundation for understanding Axure's user interface. It will establish a familiarity with the concepts and rich capabilities of the tool that will help you construct prototypes quickly and efficiently. Like all creative professionals, who must rely on tools to express our ideas and deliver our work, we must understand the possibilities and limitations of the tools we use. There is no substitute for diving into Axure and discovering its features through first-hand exploration. Nonetheless, there is real value in approaching wireframe construction with Axure through rigorous and systematic study of its interface because we can deliver a better product.

Getting Started When you launch Axure you are presented with the Welcome Screen and Licensing window, which allows you to: •

Open recent files

•

Create new files

•

Access online tutorials, including video tutorials

•

See which version of Axure you are running. Typically Axure releases several updates during a version's life cycle; it is recommended to keep current

•

Check on the status of your license

•

Contact Axure's support

Axure Basics—the User Interface

This screen is the closest Axure has to a 'Preferences' (Mac) or 'Settings' (Win) screen. For this reason, you may want to keep it unchecked for a while. A checkbox at the lower left corner of the dialog allows you to prevent this screen from showing at startup. However, you can access this window at any time using the Help menu | Welcome Screen and Licensing…

Working with multiple files In the PC version, each instance of Axure can have only one file open. When you have one file open and you choose the Open command from File menu, the current file will close, replace it with the newly opened file. In order to work with multiple files, launch another instance of Axure from your program menu. The Mac version supports the launching of multiple files from a single instance of Axure. The Windows menu lets to navigate between the open files.

[8]

Chapter 2

Axure File Formats Axure supports two distinctly unique modes of prototype development workflows. The first is focused on the needs of a single designer who is the sole author of the prototype in Axure. The other workflow mode facilitates team collaboration. Depending on your circumstances, you will use one or the other.

The .RP File Format (Stand-Alone) This format is appropriate if you are the only person ever to need direct access to view or edit the file you are using. In other words, if you are a single practitioner working on a prototype using Axure, this is the default format to use. However, I suggest that you also read about the RPPRJ format because it offers some significant value for a single user. You can always convert a single-user .rp file to a shared project rpprj file and vice-versa.

Managing Change with RP files Prototypes saved in the RP format are stored as a single file on your drive that has the .rp suffix, for example, My Project.rp. Iteration is the essence of prototyping and managing change is always a sticking issue, because the single file you are working on goes through evolutionary and sometimes revolutionary changes. Sometimes you need to go back to an older version, which can be a problem if your file not longer contains it. Here is a simple method I use to keep the history of previous iterations: In your project directory create two directories: 'Current' and 'Archive'. Keep your working copy in the 'Current' directory. When you are done working on Axure for the day, use the 'Save As' command to save a copy of the file in the archive directory and append the date to the beginning of the file name. For example: 2011-29-01_ myProject.rp. This system allows you to sort the files in your archive by date, and therefore easy access to restoring anything useful that had been removed from the working copy.

The RPPRJ File Format (Shared Project) This is the appropriate format for a team of UX designers working on a prototype. The ability to distribute work among multiple resources is very important for large enterprise projects and so is the reliability of the environment. Axure has been supporting collaboration since version 4.5 and the feature is very stable. [9]


The key features of this format are: •

Check out/Check in controls

•

Restore previous versions

Some setup is required before you can begin using this format. Most importantly, there needs to be a shared environment where the central repository can be stored. The various setup options and their pros and cons are covered in Chapter 8: Collaboration. You can create a share-project file from an existing stand-alone rp file. This is useful when a single designer initiates a project with a vision concept using an rp file. Then, when a team is on board, this file becomes the foundation for share project file of the team's work. To create the shared project, open the .rp file in Axure, and from the 'Shared' menu, select 'Create Shared Project from Current File…'. Follow the simple wizard and you are all set. To create a share project file from scratch, follow a similar path by opening Axure and using the blank file that opens.

[ 10 ]

Chapter 2

Managing Change with RPPRJ Files The shared project format is one of Axure's greater feats. It allows to distribute the workload associated with the development of a large-scale prototype among a team of designers. The supporting platform is notably efficient and reliable. You don't have to worry too much about maintaining version control or backup files. Just make sure that you and your colleagues adhere to the simple check in and check out procedures. Also make sure that and the hosting server is being backed up. Each time you check in your work or send your changes to the shared directory, a new version of the file is being created and the prior version is archived. At any time, you can restore a previous version of the project by using the Browse Shared Project History command from the Share menu, and export that version into a stand alone RP File. I cannot emphasize enough how reassuring is the knowledge that you can always go back to an earlier version of your work!

The RPLIB Format (Axure RP Libraries) Regardless of the workflow mode you use to create the prototype, you will use this format to create or use custom widget libraries. In the Widgets pane, select Create Library or Load Library and a new instance of Axure will open up. A closer look will reveal minor differences in the user interface: Instead of the Sitemap pane, there is a Widgets pane, and the Page Notes pane is labeled 'Widget Notes'. Instead of creating a full-fledged prototype, you can focus on developing building blocks that can be reused in several prototypes.

Format Comparison Table Feature

.RP

.RPPRJ

.RPLIB

Single User

Y

Y

Y

Team Collaboration

N

Y

Y

Check Out/Check In

N

Y

N

Version Control

N

Y

Y

[ 11 ]


The Workspace

Axure's workspace is straightforward. The wireframe pane is at the center of the screen, flanked by supporting panes on the left, right, and button. The menu bar and toolbar complete the composition on top. The Mac and PC versions are very similar in appearance, with the exception of the toolbar and the position of the window controls. It is useful to understand how the various panes relate to the wireframe and to each other. It is possible to think of these relationships as hierarchical: A global highlevel perspective of the entire prototype and a detailed, low-level perspective of a single wireframe. You add new wireframes and widgets to the prototype from the Sitemap, Masters, Dynamic Panel, and Widgets panes. You edit wireframes using the Wireframes pane as well as the Page and Widget Properties panes. The menu bar and toolbar have functionality that may be applied to both creation and editing.

[ 12 ]

Chapter 2

Prototype Level

Wireframe Level

Widget Level

2. Sitemap Pane

1. Wireframes Pane

5. Widget Properties

3. Masters Pane

6. Page Properties

4. Widget Pane

7. Dynamic Panel manager

All Levels 8. The Toolbar and Menu Bar

Customizing the Workspace You have some control over the arrangement of the workspace, which includes the ability to hide or show all the panes with the exception of the Wireframe pane. You can detach the panes and move them around. This feature is very useful if you work with two monitors. A convenient way to organize your space is moving all the side and bottom panes to one monitor, while keeping the Wireframe pane on the other monitor. You can resize the width and height of the panels, and you can use the Left and Right buttons on the toolbar to toggle the visibility of the Sitemap, Widgets, and Masters panes (Left button) and the Widget Properties, Dynamic Panel Manager, and Page Properties (Right button). However, you cannot change the default location of panes when they are in their docked state. For example, the Sitemap pane is always parked on the upper left and cannot be placed in any other location.

The Wireframe Pane Simply put, in this pane you design and navigate open wireframes. There are four types of wireframes in Axure. Wireframes created in each type will open up in a dedicated tab in this pane. •

Page – Managed and organized in the Sitemap pane

•

Master – Managed and organized in the Masters pane

•

Dynamic Panel – Managed and organized in the Dynamic Panel Manager pane

•

State – Managed and organized in the Dynamic Panel Manager pane

It is technically possible to create a prototype using only page level wireframes. However, this approach, like traditional methods of creating wireframes in Visio or a drawing program, is limiting and may be sufficient only for simple, fairly static, and small applications.

[ 13 ]


Maters and dynamic panels offer a modular approach, which affords reuse and scalability with only a small hike on the learning curve. Do not hesitate to explore masters and dynamic panels! If you are designing a modern prototype, you will have to use them. Each wireframe type opens up for editing in its own tab and is essentially a Tabula Rasa, a blank slate to work on. Tabs display the name of the wireframe and you can move them around, changing the sequence of their display in the Wireframe pane. The Tabs menu allows you to navigate between tabs quickly when you have many tabs open.

Grid and DPI Settings Grid and guides (which we discuss next) are standard features we come to expect in any graphic software. Axure adds a few specialized twists that are useful for wireframing work. You can control the display of the grid and change its settings from the Wireframe menu. The Grid Settings dialog lets you to select from two types of grids, Line or Intersection, and to set the spacing. Note that the grid will not be visible in the HTML prototype or in the screen captures that will be generated in the Word specification document.

[ 14 ]

Chapter 2

Axure also lets you set the DPI for the prototype and in order to understand why this is important we need some background, because, quite frankly this is one of those murky, confusing subject matters that even if we don't care too much about, may have an impact on our prototype. DPI stands for Dots Per Inch which is intuitively easy to understand until you ask the question: Why should I care? The Windows operating system supports 96DPI, which the Mac OS supports 72DPI.

Guides Lock the guides if you use a present to ensure that positioning of elements does not shift during the weeks and months of the design. This is especially important for shared projects, where, the impact of a few designers using a slightly different grid might create serious havoc on overall consistency.

The Sitemap Pane The name of this pane may suggest a limiting web-centric approach to Axure prototyping, one that is limited to websites. But don't let the label mislead you. You can create highly complex enterprise grade prototypes for web or desktop applications with Axure. You can collapse the pane by closing the minimize icon or you can remove it from the workspace altogether by clicking on the close button. If you want to show the Sitemap pane again after it had been closed, use the View menu. In the Sitemap pane you create and organize Pages--the highest-level elements in Axure. If you are used to Visio, an Axure Page is similar to a tab in a .vsd file. Axure offers two types of Pages:

[ 15 ]


Wireframe Pages Generally, you can equate a page to an entire screen, which is a composition of widgets, masters, and dynamic panels. Lets consider as an example a very basic 'Home page', which includes a header, a global navigation pane on the left or right, a footer and a body area in the center. These layout regions are likely to be masters because they repeat with some variation on all other pages of the prototype, which you pull over to your 'Home page' wireframe.

The Masters Pane What is a master As the name suggests, a master is a single wireframe that can be used on many other wireframes. When you make a change to the master wireframe, the change will occur also in all the instances where this master is used . This is a significant time saving feature. The Master pane is used quite a bit because it supports an important principle of good user experience design, which is, of course, consistency of design patterns across the interface. The master pane allows you to manage and organize your collection of masters.

[ 16 ]

Chapter 2

Master management capabilities include: •

Add Folders

•

Add, Duplicate and Delete Masters

When you are prototyping, you do not always know in advance whether or not a particular element in a wireframe is a repeating element. What usually happens is that at some point in the design, you want to copy an element from a wireframe that already exists and paste it into the wireframe on which you are working at present. This is when you realize that you need to create a Master. Fortunately, Axure provides a really productive feature for creating masters out of any widget or collection of widgets on the screen using Convert To Master: 1. Select the widgets that make up the reusable object (Master) you want to create 2. Right-Click and select 'Convert to Master' 3. Presto! a new master will appear in your Masters Pane, and the collection of widgets you had on the wireframe turned into a single object with a pinkish shade.

As you add masters to your prototype, new masters labeled 'New Master' are added to the bottom of the master list.

Name Everything!

[ 17 ]


Organizing masters in the Masters pane include the capabilities to •

Group masters in folders

•

Rename masters

•

Change the position of masters in the pane

Master Behaviour Perhaps the word "behavior" is not the best to describe the feature that allows you to determine how to apply a particular master instance to a wireframe. The options are:

Normal This is the behavior of a 'classic' master: Drop it on any other Page, Master or State, and when you make a change to the master, all its instances will change instantly. The properties that will not change are the x and y positions of the instance on the receiving page or master.

Example Company logos are master 'naturals' because they are likely to appear on all or most pages. As you begin work on the header part of the prototype, one of the first elements you need is the logo. You might not have the actual logo so you use a placeholder at least for the first iteration. You create a new master and label it 'M-Logo'. The prefix 'M' will help you distinguish between master and page wireframes when they are open in the Wireframes pane. You drag the Image widget from the Widgets pane and drop it casually in the master wireframe. You proceed to set the logo's width and height based on a business requirement or on your judgment. Let's say it is 200 pixels wide and 120 pixels high. For now, the logo master is ready to be used in the prototype.

[ 18 ]

Chapter 2

The Home page is the first wireframe, in which you use the logo master. So you drag the master from the Masters pane and place its instance in the Home page wireframe. Notice the pinkish shade (Master Mask) that helps you distinguish masters from other widgets. Now you pay special attention to the position of the master on the page. In our example, you position the logo 10 pixels from left (x=10) and 10 pixels from the top (y=10).

You proceed to place other layout elements as needed, such as top and left navigation, and a center area. A few weeks of debate over the logo selection pass by, and finally the marketing department informs you that the size should be 260 pixels wide 140 high. You would like to see the actual logo? Well, they are still working on the graphic and waiting for final approval from the top brass. So you open the logo master and only change the dimensions of the Image widget you used as a placeholder. Please notice now that on the master, the logo has the corrected dimensions and it is in the same random position where you dropped the Image widget a few weeks ago. When you open the Home page, you will see that the updated logo now appears with the new dimensions w=260, h=140. As a result, you have to shift things around. But the position you selected for the logo has not changed - it is still at x=10, y=10.

[ 19 ]


To summarize, the position of the master instance on the page is relative to the page's upper left corner (x=0, y=0) and it is not affected by the position of the widgets that make up the master in the master wireframe.

Place in Background On goes the saga of our illustrious logo. The latest directive from the marketing department is that the logo, with absolutely no exceptions,must always be positioned at 10 pixels from left and top of the screen. The logo master will be used on many pages, and since you know that the placement of 'Normal' masters is page-based, you want to enforce the new positioning rule and reduce the risk of logo placement inconsistencies from page to page. The Place in Background behavior helps with exactly this need--the position of each master instance on every page maintains the position it has on the master.

You open the logo master and change the position of the Image widget from its initial random position to the required x=10, y=10. Now select in the Masters pane the 'Place in Background' behavior for the logo and you are set. From now on, whenever you drag an instance of the master logo to a page, it always locks into the x=10, y=10 position. In other words, once the element is on a page, you will not be able to change the position of a master that has a Place in Background behavior. If there is an exception and you end up having to change the position of a master instance on a particular page, all you need to do is to open that page, select the master, change its behavior to Normal and move it to the desired specific position on this page.

[ 20 ]

Chapter 2

Custom Widget A master with a custom widget behavior functions just like a custom widget created in the widget pane as part of a custom widget library. Both are instances of templates, which loose their link to the parent master, once they were dragged-over from their respective panes into the wireframe canvas,. Changes to a master with a custom widget behavior will not cascade down to its instances. The main difference between a master with custom widget behavior and a custom widget is in the repurposing and distribution. Custom widgets are stored in libraries that can be easily shared and repurposed in other projects that have entirely different subject matters. This can be done by you or by other designers who may be interested in the design patterns of a particular library. However, creating a custom widget library requires that you pause the work on which you are immediately focused in order to create an new library, load it into your prototype file and so on. Before you become engaged in this extra effort, make sure this is not overkill for your needs, especially if you are the only person using the file. A master with a custom widget behavior, on the other hand, is immediately available to you and your team in the file on which you are working. Note that repurposing a master in other projects is also an involved process, which includes importing the master from the file on which it was used. So why bother creating masters with custom widget behavior if their instances do not benefit from changes made to the master? TBD.

Usage Report Change is inherent to the iterative process. You may be working on a new page, and addressing requirements that are specific to that page, as you realize that a change is required in a master that is used on the page. No problem: Double-click, or check out the master for editing, and the change is done. But wait. You remember that all instances of the master will change instantly anywhere this master is used. The impact of changing a master hastily will be compounded if you are a member of a team of two or more designers, who collaborate in the shared project environment. In large and fast paced projects you may not be intimately familiar with the nuts and bolts of wireframes that were created by your colleagues, or with the requirements that guide design consideration in their part of the work. A change that was made to a master in order to fit it to one of your pages may come as an unwelcome surprise to your team members, who use the master on their pages. On their pages, the modification you made to the look and feel of the master, its functionality of both, 'breaks'

[ 21 ]


To solve this potential problem, Axure offers one of its most useful features, the masters Usage Report, which is available on a right-click menu of each master. This feature allows you see all the pages and other masters where a particular master is used.If a master is not used anywhere, you can probably delete it.

The Widgets Pane What is a Widget For a Visio user and for any user of a painting tool, the widgets pane is all too familiar. It is a collection of shapes that you can drag over to the canvas and use to assemble a wireframe. The widgets pane allows you to access Axure's built-in widgets collection as well as manage and organize imported third party or your own custom widgets collections: •

Wireframes - Geometric and basic user interface components such as radio buttons, fields, droplists and so on.

•

Flow - Diagram related shapes that can be used to create flow charts and other diagrams

[ 22 ]

Chapter 2

When you drag a widget to the screen, move it across the screen, select a widget and hover with your mouse over one of its handles, the location and size information are displayed. This is a helpful feature to ensure accurate placement.

Wireframe Widgets Axure's drawing capabilities are somewhat limited as compared to full-fledged drawing or diagraming programs like Visio or Fireworks. For example, you cannot rotate, skew or distort a Rectangular widget, which also means that you cannot create diagonal lines. Also missing are free-hand drawing tools and shapes like polygons and arrows. Nonetheless, Axure offers all the necessary visual vocabulary needed to create fully robust prototypes. Mastering the capabilities of each widget will help you construct better wireframes. Widget

Edit Text

Edit Tooltip

Set Disabled Enabled

Assign Selection Group

Edit States (Rollover, Mouse Down, Selected, Disabled)

Notes

Image

Y

Y

N

Y

Y

Import and resize image Files Optimize Slice Super Impose Text Preserve Corners

Text Panel

Y

Y

N

N

N

Hyper Link

Y

Y

N

N

N

[ 23 ]

This widget does not have an inherent hyperlinking behavior. It is just text widget that is preformatted with an underscore and Blue font color. To make it link to another page, you will create an interaction.

Axure Basics—the User Interface Widget

Edit Text

Edit Tooltip




Notes

Rectangle

Y

Y

N

Y

Y

To the uninitiated, a first glance at the Rectangle widget can be alarming because there appears to be only one geometric shape, the rectangle. But no worries. Drag a rectangle widget over to the wireframe pane and right-click. From the Edit Button Shape menu more shape options are listed. These fall into the following categories: Rectangle (normal, all round corners, top, bottom, left or right rounded corners) Tabs (left, right and center) Triangle (top, down, left and right) Ellipse (ellipses and full circles*..(hold the shift key while dragging a corner) So, when we talk about the Rectangle widget, we actually encompass this collection of shapes. At any point you can change a Rectangular widget's shape, for example, from a left triangle to right triangle or an ellipse.

[ 24 ]

Chapter 2 Widget

Edit Text

Edit Tooltip




Notes

Placeholder

Y

Y

N

Y

Y

It is useful when you need to secure an area of the screen for a piece of functionality that is yet to be developed for the prototype. Or, you want to indicate the space that will be occupied by an image, but you don't have that image yet, or you don't want to place it in the wireframe because it is going to create a distraction.

Button

Y

Y

Y

N

N

Keep in mind that all widgets can be buttons, meaning that you can attach interactions to any of the widgets in the Widget pane.

Table

Y

N

N

N

N

Axure's table widgets is quite rudimentary, so you can add and remove columns and we would love to see the ability to merge cells and have build-in formatting for evenodd row and column shading, or the ability to hook tables to an excel spreadsheet or desktop database such as Filemaker Pro or Access in order to generate more robust simulations of dataheavy grids.

[ 25 ]

Axure Basics—the User Interface Widget

Edit Text

Edit Tooltip




Notes

Text Field

Y

Y

Y

N

N

Limit max length Mask and Unmask text (Quickly simulate the behaviour of Password fields) Toggle Border Set Read Only (Set Not Read Only)

Text Area

Y

Y

Y

N

N

Set Read Only (Set Not Read Only)

Droplist

Y

Y

Y

N

N

List Box

Y

Y

Y

N

N

Checkbox

Y

Y

Y

N

N

Select/Unselect Checkbox

Radio Button

Y

Y

Y

N

N

Select/Unselect Radio Button Align Radio Button Left/Right Assign Radio Group

Horizontal Line

N

N

N

N

N

Vertical Line

N

N

N

N

N

Button Shape

Y

Y

Y

Y

Y

Image Map Region

N

Y

N

N

N

Inline Frame

N

N

N

N

N

Edit Default Target Toggle Border Show Scrollbars As Needed Always/Never Show Scrollbars

[ 26 ]

Chapter 2 Widget

Edit Text

Edit Tooltip




Notes

Dynamic Panel

N

N

N

N

N

Manage Panel States Set Visible/hidden Always/Never Show Scrollbars

Menu (Vertical)

Y

Menu (Horizontal)

Y

Tree

Y

N

N

N

Y*

Edit Menu Padding *Mouse down or Disabled States not Applicable

N

N

N

Y*

Edit Menu Padding *Mouse down or Disabled States not Applicable

N

N

N

N

Edit Tree Properties

Flow Widgets Flow diagrams are interesting because they are an abstraction of a flow, an algorithm expressed not as a mathematical formula, but rather in concrete shapes, arrows and text. A flow diagram is an image. And here is a situation where the phrase "An image is worth a thousand words" underscores a general problem with flow diagrams. Flow diagrams are often not very easy to understand and you actually need a thousand words to explain exactly what is going on. There are several methodologies to create flows: eXtreme Programming (XP), the Microsoft Solutions Framework (MSF) for Agile, the Rational Unified Process (RUP), the OpenUp (Eclipse), the Agile Unified Process (AUP), the Enterprise Unified Process (EUP) and there are still more. You may also need to use several types of flow diagrams, such as Affinity process, sequence, sitemap, interaction model, hierarchy and so on. Whatever choices you make for creating flow diagrams for your project, Axure 6 can help you put them together in a compelling way. In addition to the geometric shapes commonly used for diagraming, such as the Diamond for decision points, there are specialized shapes such as Database and Bracket, and most importantly, the Actor shape. [ 27 ]


You can reference any flow widget to any page on the Sitemap pane, which makes it possible to click the shape in the html prototype, and link to the actual wireframe page.

Create your own widget library Widgets are like Lego blocks--they are the raw materials from which you create your design. Widgets are templates from which you can quickly assemble less generic designs. Most importantly, widgets are used to apply consistent design patterns throughout the entire prototype. TBD

3rd Party widget libraries Before you embark on creating your own custom library, it is worth doing a little research to check out the free libraries that are listed on Axure's website. There is a high probability that some nice person has already done the work and graciously offered the fruits of his labor to the community.

The Widget Properties Pane This pane is perhaps the most important of all Axure's panes because it facilitates the three major aspects of a high-fidelity prototype: Interactivity, visualization and documentation. The pane is contextual to a widget selection, which means that it becomes active only when you have a single widget selected. Once a widget is selected, the properties pane allows you to define its behavior and attributes though the following three main sections: •

Annotations

•

Interactions

•

Formatting

[ 28 ]

Chapter 2

Annotation Tab Overview To appreciate this simple yet profound pane one needs to return to the days of Visio when we had to create the wireframes in Visio and maintain a separate Word documents to capture the annotations. These were the steps: 1. Create wireframe in Visio 2. Add numbered markers where needed 3. Take a screen capture of the wireframe 4. Name and Save the screen capture 5. Paste the screen capture into Word 6. Create an attributes table and for each of the numbered markers 7. Write the annotations This seven-step process had to be repeated for each wireframe. Since prototyping is highly iterative, you have to refine constantly your Vision wireframe, add or remove numbered markers, retake screen captures, resave (and I will not even bother describing the process of managing versions), replace the captures in the Word document and update the annotations. You can imagine the coordination effort and labor it took when a team of UX designers worked in the Visio environment. Also remember that both Visio and word are single-user applications. To summarize, this was a painful and expensive process. It was not only time consuming but also prone to errors, especially in large projects, where keeping the Visio and Word documents in sync was so complicated that often an Excel spreadsheet had to be used just to track updates and changes.

[ 29 ]


Axure's integrated environment means that wireframes and annotations are tightly coupled. Whether you generate an html prototype or a Word interactions, the most updated screenshots are created along with numbered footnotes. In Word, the annotation tables are listing the attributed widgets referenced in the screenshots. The time savings are monumental. This means that you can spend less time on the tedious mechanics of prototype documentation and more time on refining the design.

In Axure, life is significantly simpler because the drawings and their annotation are unified.

Annotation Fields Axure comes with a default set of annotation fields but this set can be easily customized.

[ 30 ]

Chapter 2

Consider carefully the number of annotation fields you add. The more fields you have, the more annotations you have to write. In large projects, high numbers of annotations can have a compounding effect due to the sheer number of widgets that are involved. Consider the value of each annotation field. Discuss the optimal field set with partners and the stakeholders, who are the consumers of the annotations, to discover which attributes provide them with the most value. Don't be shy about educating your partners about the work effort involved in wireframing and annotation. I recommend this especially for Agile projects, where requirements are developed on the go and it can be a real challenge to write specifications for an evolving product. Although many attributes can be captured, one must be practical. Remember , this may be the case where less is more. Develop the annotation field-set with the consumers of the UX spec Be practical about the number of annotation fields

Annotation Views Axure provides a useful feature to help organize annotation fields in smaller subsets that make the input of content more convenient. Other partners in the project will use the annotations, most notably the business analysts who write the business requirements, and development teams who code the software. Annotation views help plan the sequence in which the annotations are written to balance the load and to avoid a last minute crunch.

[ 31 ]


Another use of this feature occurs in shared projects when multiple teams are working on the Axure project file. The most common example might be when the UX team and the business analysts team collaborate and populate annotations. In this case you can create a view for BA's with fields that are relevant for them, and separate UX related fields for the UX team.

To create a new view: 1. open the 'Customize Fields and Views' dialog 2. Switch to the 'Views' tab 3. Press the + icon on the 'Customize Views' list on the left 4. Label the view 5. Choose the fields you want to have in the view from the 'Add' list on the right. To access the views:

[ 32 ]

Chapter 2

The benefit of grouping the fields into views is that the list of fields is short and you can see, without scrolling vertically or adjusting the height of the right-hand panes. On the other hand, one needs to be careful to enter annotations in the right view.

Interactions Tab Overview The next profound feature is Axure's ability to help us simulate the user experience in a hyper-fidelity way that helps tell a compelling and convincing story about the interface we are designing. The power of simulating interactivity cannot be exaggerated. The truth is that most people have a hard time imagining how something might work, even when they are presented with a wireframe. The phrase "A picture is better than a thousand words" is somewhat problematic in RIA's because any screen of even a mildly complex interface is divided into multiple areas, each involving multiple scenarios, paths and exceptions. A thousand words may not be enough to explain each wireframe, and we know from practical experience that this is not going to fly. For example, think about communicating a simple 'mouse over' interaction where, as the user's mouse is hovering over a text, its styling changes from Normal to Bold and Underlined, the color changes from Black to Orange, and after two milliseconds, a small popup appears on the upper right corner of the link. There are two options for how to provide a visualization of this interaction pattern. The first option is to provide two images, one depicting the 'mouse over' state and the other depicting the 'mouse out' event. The second option is to use a single image for one of the states while adding verbiage to explain the other state. Now, imagine a stakeholders' meeting with high-level executives to whom you want to communicate your vision of the design. The most trivial of interaction patterns requires so much explanation that it inevitably slows down the overall delivery of the application-flow. You might argue that this is how user interfaces used to be communicated not so long ago, and some practitioners continue with this practice. Keep in mind that the complexity of interaction and the flexibility afforded by modern browsers and development frameworks were not mature a few years ago. In order to provide a close simulation of interaction patterns, one had to use complex processes, which involved generating rollover states in tools like Fireworks, or creating a more dynamic html mockup in Dreamweaver. In many cases, part of the time and budget allocation in UX projects were dedicated to a developer who coded the prototype in Flash or html and JavaScript because this work requires a skillset that most interactions designer don't have. [ 33 ]


To conclude this introduction, new capabilities require adaptations, which Axure helps us embrace. In the case of the simple mouse-over interaction described above, all you need to do wit Axure is move the mouse over the text, and the rest becomes visible to the audience.

Creating Interactions Interactions are the stuff that makes an Axure prototype interactive. In its most basic form, the recipe for an interaction is simple: Select a widget. Chose from the list of events that are contextual to the widget to which they are going to be applied. To create a new interaction, select the widget in the wireframe pane and switch to the 'Interactions' tab in the widget properties pane. The available interactions events will be listed.

Events With the exception of the Dynamic Panel widget, Widget

OnClick

OnMouseEnter

OnMouseOut

Image

Y

Y

Y

Text Panel

Y

Y

Y

Hyper Link

Y

Y

Y

Rectangle

Y

Y

Y

Placeholder

Y

Y

Y

Button

Y

Table*

Y

OnKeyUp

OnFocus

OnLostFocus

Y

Y

Y

Y

Y

OnChange

Text Field

Y

Text Area

Y

Droplist

Y

Y

Y

Y

List Box

Y

Y

Y

Y

Checkbox

Y

Y

Y

Radio Button

Y

Y

Y

Y

[ 34 ]

Chapter 2 Widget

OnClick

Horizontal Line

Y

OnMouseEnter

OnMouseOut

Vertical Line

Y

Button Shape Image Map Region

Y

Y

Y

Y

Y

Y

OnKeyUp

OnFocus

OnLostFocus

OnChange

Inline Frame Dynamic Panel** Menu (Vertical)*

Y

Menu (Horizontal)*

Y

Tree

Y

All blank = N * = Table and menu cel ** = Separate table

Cases A good user experience must be contextual to the user and to the task being performed. The user and the task, along with specific business rules and other restrictions, should guide the behavior of the user interface at any point in time. In software development, the most appropriate method to capture all the contextual information is the use-case. Use cases exist in several flavors depending on the development methodology used, such as UML, RUP and so on. For our purposes here, we will treat a use case as an instruction that, given some conditions and user-driven events, the interface should behave in a certain way. In the Axure parlance these user-driven events are called cases. Typically, cases are attached to widgets--buttons, links, tabs, checkboxes, radio buttons and so on.

[ 35 ]


Formatting Tab Overview At its core a wireframe is a framed area with some boxes and text. It can work perfectly when sketched on a napkin or an index card, but this technique can get you only this far. With the evolution of User Experience as an established discipline, there has been a shift towards higher fidelity. From static, simple and often crude slides of Black & White boxes pasted into Word documents, where explication of the user experience relied on supporting text and the audience's imagination, we have moved to sleek, high fidelity interactive html prototypes that approximate the actual software to a very high degree. We are in the User Experience business and the 'experience' is determined as much by how the interface looks as by how it behaves. The tension between form and function is exceptionally strong. This is why large corporation often spend a considerable amount of effort on creating so-called 'Vision' prototypes to convince top management to invest in an expensive new application. These vision prototypes are executed in hyper-fidelity, including visual design and features that often would not make it to production. Nonetheless, these features play a critical role in galvanizing support for the new project and exciting the sales organization about the good things that are just around the corner. Whatever are the stylistic expressions appropriate for your project and your design philosophy, the Formatting tab is where you can define the visual properties of widgets. The pane is divided into six collapsible sections. Some deal with attributes that apply to a single widget, and some

[ 36 ]

Chapter 2

Location and Size Benjamin Franklin was perhaps the person who coined the phrase 'A place for everything and everything in its place'. Try to keep this in mind when constructing wireframes. In Axure you drag widgets from the Widget pane and drop them casually on the wireframe canvas. You resize, change color and style. You build up a wireframe from a blank page to a fully detailed one. You add widgets and place them in logical positions as called for by the evolving design. You are working on a composition--the careful placement of objects in a framed area. Giving some extra attention to exact sizing and placement of widgets will pay off handsomely down the road aesthetically as well as practically. In this section you can enter the exact height and width of widgets, which is faster than manually resizing using the mouse. You can also resize a group of selected widgets, which is convenient on various occasions; for example, when you want to uniform a few input fields. Finally, knowing the exact position and size of widgets helps when you add interactions that involve moving a widget to a different position. CSS 5 equivalent:

Font The role of typography in your prototype can not be underestimated. The typeface, its size, styling, color and spacing can make a sea of difference in how your work will be perceived - by your partners and by the end user. visual communication has not diminished a bit over the thousands of years it has been refined communicate been known Fonts play a major role in communicating a certain

Style From the Style section you apply the appropriate style sheet you want to apply to the page can access Axure's equivalent to style sheets, the Widget Style Editor and the Format Painter. We cover these pane in detail in chapter 7.

[ 37 ]


The Page Properties Pane This pane controls the attributes of pages, masters and dynamic panels. You can not have page-level annotations for the states of dynamic panel.

Page Notes This is where you can describe an entire screen at high level. In most cases, when you are annotating a page you are describing an entire screen. When you are annotating a master, you are describing a component that repeats on several screens. And when you are annotating a dynamic panel, you are describing the container. You can format your notes (bold, italic, etc.) by highlighting the section you want and applying the style from the toolbar. [ 38 ]

Chapter 2

Manage Notes The annotations are visible in the html prototype and in the Word specification documents. Typically, you are addressing an audience that has specific interest in only part of your description. For example, developers might be interested in behavior patterns of the screen and other technical information, while the business team is looking for the fulfillment of the business requirements. With Axure you can segment your writing by creating several note sections. Examples of such sections are •

BRD Reference

•

Accessibility (WAI/Sction 508) Notes

•

UX Description

Creating additional notes section should also be used in shared projects when several teams contribute content to the same wireframes. For example, the UX team provides UX related notes; business analysts add business requirements notes, and system analysts add functional notes. Victor Hsu, Axure's chief is the first to tell you that Axure is NOT a business requirements system. Nonetheless, in the realities of an ongoing project, it makes a lot of sense to aggregate all UX related content using the same tool. So it can be done, and we cover this in chapter x.

Page Interactions This tab allows to define how the page will render when it loads. This is an awesome feature because it affords an economy of construction. For example, instead of creating a unique page that visualizes how the page looks when a first time visitor accesses it, and another unique wireframe to show the page after the user loggedin, you can specify an onPageLoad event that determines which state of a dynamic panel to load. In the process of creating a high or hyper-fidelity prototype, you are likely to find yourself at some point walking the fine line between effort spent on maintaining the prototype.

Page Formatting In this tab you can define global attributes for the entire page, such as background color and alignment. This pane applies only to pages, and not to masters or dynamic panels.CSS 5 properties...

[ 39 ]


Sketch Effects New to version 6 is a new feature which deals with the formatting of the wireframes - NOT of the actual software you are prototyping, but rather - the look and feel of the

The Dynamic-Panel Manager Overview The Dynamic Panel is the most unique of all Axure's widgets and perhaps Axure's most unique feature altogether. It is the key to our ability to dream-up and communicate new highly interactive interaction patterns. It requires a shift in the way we design prototypes. Sometimes, historical context helps shed light on contemporary practice. Only a few years ago technical constraints posed significant challenges to interaction design, including slow networks, slow and expensive computers, the browser 'wars' and software incompatibility, protocols that required frequent full page refresh, and last but not least, a lack of specialized prototyping tools. Early prototyping was typically simple and page-based, often hand-made on index cards. For each screen of your application or website there was a corresponding wireframe. Sitemaps reflected not only the hierarchical structure of a site but often also how it was physically constructed. For example, a page with search functionality linked to another page that displayed the search results. Many interaction designers (by the way, this title did not exist a decade ago.), who were looking to adopt tools that helped visualize the page-by-page paradigm, flocked to Visio, a diagraming tool popularized by network and software architects because of its large libraries of specialized widgets and the ease with which one could whip up very complex, technical diagrams. Several factors converged to bring a sea of change to user experience design and the way we prototype: •

Constantly evolving technologies that make it possible to provide instant response to user actions without having to refresh it all, for example, typeahead behavior in search fields.

•

The push toward the Semantic Web and the decoupling the content layer from presentation presentation while supported by agnostic web services that make it possible to share and aggregate vast amount of data from disparate data sources.

[ 40 ]

Chapter 2

•

The emergence of portals and dashboards introduced a user interface that is composed of modular components, each dedicated to some aspect of the application, each encompassing specialized tasks and workflow paths.

•

User segmentation via roles and personas and the need to support a systems' plasticity to provide the appropriate data and functionality securely contextually depending on user login credentials.

•

Personalization – the user's ability to tailor the system to her own preferences by customizing aspects of the interface for improved productivity and satisfaction.

•

Proliferation of target display sizes. We used to design with a common size and resolution in mind, moving from 14" diagonals CRTs to 24" flat screens. Now we often have to consider display sizes ranging from 50" jumbo HD televisions through 24" desktops, 10" tablets to 3" smartphones.

•

The dominance of the web browsers as thin clients marks a shift from specialized desktop and client-server applications to the browser as the means for delivering the software. With this also came a shift from developing primarily with Internet Explorer in mind, to a wider range of browsers, including Firefox, Apple's Safari and Google Chrome.

•

Mobile devices with high-quality touch-screens and with them, the mobile App category are expending not only the vocabulary of user interaction patterns and the possibilities of direct-manipulation, but also the need to support specialized interfaces for the iPhone, Android and Windows 7 Mobile.

•

Proliferation and integration of Social media in every aspect of our life creates a demand to integrate it into the user experience of most applications.

•

Finally, companies see the value of investing in the user interface or, as it is now more commonly known, the user experience. Although it remains not very well understood, our work is no longer viewed as 'graphics' or 'eye candy'.

These trends and changes affect our work. We need to communicate to stakeholders how a screen morphs not only in response to the user's location, access authorization, system-determined personalization, and user-set preferences, but also how this context and content impact various elements on the screen as they change asynchronously in response to user actions and system events. And so, let me introduce to you the Dynamic Panel:

[ 41 ]


What is a Dynamic Panel As its name suggests, Axure's dynamic panel has something to do with facilitating change, movement and interaction. Indeed, you can control its visibility properties and make it move around the screen. Most importantly, the dynamic panel stores and displays one or more variations of an interface object with the instances that are appropriate for the context of the overall screen in a given point of the interaction path. There are several ways to create dynamic panel: 1. You can drag the Dynamic Panel widget from the Widgets pane and drop it in the wireframe 2. On the wireframe, select one or more widgets(including masters and other dynamic panels) and use the 'Convert to Dynamic Panel' function from the contextual menu (on right-click) 3. On the wireframe, select one or more widgets (including masters) and from the menu bar select the Object menu A dynamic panel has at least one state and each state constitutes a discrete wireframe. Consequently, a dynamic panel widget is only a container for wireframes. A deck of cards is a good analogy: The box is the dynamic panel and the cards are the states. Performance Note: Axure considers each layer to be a page in its own right. The more states in a dynamic panel, and the larger the dynamic panel, the more work a browser has to do loading a page that has this dynamic panel on it.

Sometimes you don't necessarily need multiple states but rather want to toggle the visibility of an interface section, or have it change position in response to user action. In most cases, however, you will use several states.

Creating Dynamic Panel and States We'll use a tutorial to illustrate the construction flow of a dynamic panel and corresponding states. Suppose we want to simulate a login area where the user provides her user name and password. For now you only need to capture two key scenarios: 1. Successful Sign In 2. Failed Sign In

[ 42 ]

Chapter 2

We begin by creating the initial state, a wireframe that visualizes the interface before the user attempts to sign in. Drag over a couple of Text Fields, a couple of Text Panels, a Hyperlink and a Button widget. After you organize the widgets on the screen, drag your mouse to select the entire group and right-click. Select Convert to Dynamic Panel from the contextual menu.

Notice how the entire section is framed by a masked bluish frame. This is how Axure helps you distinguish dynamic panels from other widgets. If you have done this already, make sure that the Dynamic Panel Manager is visible. You will find it in the View menu on the menu bar. In the manager pane you will see that a new dynamic panel has been added, nested under the pagein which it was positioned (In our example, this is the Home page.). By default new dynamic panels are 'Unlabeled'. Notice that the icon to the left is a miniature of the dynamic panel widget in the widgets pane. Nested below the new panel is the first state, labeled, by default 'State1'.

[ 43 ]


Now we want to create the Successful Sign In state and there are two methods to add a new state to a dynamic panel. The first, using the Dynamic Panel Manger:

The second method is just to double click on the dynamic panel and use the Dynamic Panel State Manager dialog:

Either way, a new state is added. Notice how all along, Axure nudges you to label new objects you as you add them to the prototype. We have a whole section devoted to naming conventions, but if there is only one take-away you gain from this book, it should be – label everything in your prototype, and the sooner – the better. In this example, I will leave all those widgets unlabeled. Double-click the new state to open it for editing. A new tab opens in the Wireframes pane, showing the name of the state and its associated page.

[ 44 ]

Chapter 2

The dotted blue area indicates the area of the dynamic panel. This area was established by the first state we created. No worries – the size of the container can be adjusted at any time. Note that anything placed outside of the dotted line will not be visible on the page this dynamic panel is placed on. The best starting point for the new state is the previous state. Open the first state by clicking it in the Dynamic Panel Manager. Select All to copy all the widgets and switch to the new state. Make the appropriate changes and move on to create the third state.

The third state is almost identical to the initial state, but the system will provide some inline text letting the user know the credential supplied were rejected and to try again. You paste the widgets from the first state into the blank new third state, and realize that the Blue dotted line is tightly wrapping the existing widgets, leaving no room for the needed inline text. As mentioned, you can always resize the dynamic panel – remember, it is the container that holder all the states. So for now, just ignore the Blue dotted line, drag over a Text Panel and make the necessary changes to this wireframe.

To recap, we now have a dynamic panel that deals exclusively with the Sign In section of the page. We captured three key states, Initial, Success and Failure. If we did not rename anything, the Dynamic Panel Manager looks something like this:

[ 45 ]


Hard to tell what is what, ha? Ok, I think you got the importance of labeling, but le''s continue a bit more like that. After all, when you are working under pressure, who has time to label or document anything, right? So now we just want to adjust a bit the size of the dynamic panel. There is an easy and fast way: Double click the Dynamic Panel and resize it liberally to make sure it can contain every possible state. I encourage you NOT to do this. We really want the size of the dynamic panel to fit the width and height of the biggest state, but not much more.

Use the up arrow to move State 3 to the top position. Switch to the Dynamic Panel Tab, click on the dynamic panel and use the resizing handle to extend the frame so that theentire content of this state is visible. In our example, adding 5 pixels to the height of the dynamic panel were all that was needed.

Finally, reorder your states in their original sequence. Do''t label them yet. The Toolbar and Menu Bar Now that you are familiar with the various options and capabilities in the workspace it is time to introduce Axur''s Toolbar and Menu bar. One of the few places where there is some difference between the Mac and PC versions of Axure 6 is the toolbar because each of those desktop clients is native to the operating system it is indented for.

[ 46 ]

Chapter 2

On the PC you toggle the display of toolbars using the View menu while on the Mac you use Customize Toolbar after right-clicking the toolbar area.

The Menu Bar When I open software ''ve never used before, one of the first activities I turn to after playing around, is going methodically over the menu bar, one item after the other. I get a better sense of the softwar''s capabilities and features because most are listed right there.

Summary If you are new to Axure, I hope that this chapter got you excited about wireframing with the tool. And if yo''ve been using Axure for a while, I hope that this review helped close gaps and learn about the new features in version 6. If you have not done so already, I highly recommend visiting Axur''s website. It offers a wealth of videos and tutorials that will help you master the too''s rich feature set. Many users, myself included, were able to do productive work with Axure within hours from downloading the trial version (offered for a 30 days evaluation). If you plan to purchase am confident that you will get a return on your investment within days if not hours, the more you know the more freedom and control you will have over your prototype. [ 47 ]

Prototype Construction Basics User experience design is part art, part craftsmanship; the fusion of methodology and patterns with creative problem solving. The prototype plays a major role in the success of UX projects because it is simultaneously a concrete interactive preview of both the vision for and the actuality of the application being designed. For the UX designer Axure offers the abilityto deliver quickly and iteratively simulations of rich interactive user experience without having to know programing A few years ago the cost of providing timely interactive prototypes was prohibitive for many companies. Most UX designers are not programmers and so have been limited to producing static wireframes in Visio or similar tools Skilled developers had to be engaged in order to convert the static wireframes into interactive JavaScript, Dynamic HTML, or Flash simulations This was a mini development effort that required the UX designer to invest significant amounts of time to communicate interaction flows and the behavior of various widgets to the developer and later, help debug the simulation. Once a prototype has been coded, it typically reflected an outdated version of the actual static wireframes because in the mean time, these were subject to a number of iteration cycles. With Axure, UX designers can create very sophisticated interactive prototypes without having to know how to code in ActionScript, JavaScript, or having to engage developers to create the simulation. The gap between our ability to imagine the experience and articulate it in the prototype had closed. With this power also comes a need to develop and perfect prototyping best practices to support proficiency and productivity.

Prototype Construction Basics

Principles To paraphrase John Donne,''no prototype is an islan''. As user experience architects and designers, our contribution to the final product must be viewed as part of the entire software development life cycle. We impact the work of other teams and are influenced by it. The larger the project, the more orchestration and coordination are required to keep all the moving parts in sync. Iterative design, the core of UX user-centered methodology, can end up crashing us against the solid rocks of budget and timeline It is possible to distill three guiding principles of prototyping that are projectagnostic and support consistency and predictability the quality of our work: 1. Deliver on vision, on time, and on budget while avoiding a death march Estimate and plan the prototyping and specifications effort ""The medium is the message""— The tools we master and the quality of our craftsmanship help shape our deliverables, and in turn increase the confidence of our clients and partners in our expertise and in the vision we help shape. 2. Zen''s Paradox of Plurality does apply to prototyping Be strategic about the low-level high-fidelity details to which you are committing. Throughout the book, I will demonstrate the application of these principles to real life scenarios using a demonstration project. You will find that although many of the ideas and best practices are presented in the context of Axure, they are in fact toolagnostic and can help you in your work even if you use other prototyping tools

The Demonstration Project Elephants and mice share common ancestors and similarly, albeit oddly compared, UX projects for the global enterprise share the DNA of much smaller UX projects. Core activities such as discovery, user and application research, requirements gathering, iterative design and usability testing are fundamental to user centered design even when the difference in scale and complexity of the UX projects is profound. The focus of our demo project is obviously creating an interactive prototype with Axure.The process involves rapid cycles of iterative design as we move from a high level view of the site map and global navigation to the low level details involving thelayout of pages and finally, the behavior of discrete widgets. Several streams of information inform our design: 1. Business Requirements 2. Feedback from stakeholders 3. Intermediate usability tests to validate the proposed desig [ 50 ]

Chapter 3

We will simulate iteration and feedback, including feedback that will require rework as a result of changes in the requirements or surprising responses from users The book will address you, the reader. We will pretend that you are a single designer, hired as a principal UX architect to conceptualize the vision prototype of the application. In phase 1 of the project, you will be working on your own. However, in the process, you will also consider the larger team of designers, who iares going to join you after the approval of the vision prototype. Phase 2 will follow the smashing success of your initial vision prototype.You will be asked to lead a larger UX team through an ambitious development project. You will be responsible for providing the UX activities for the overall project plan, estimate the time and resources needed to do the work, collaborate with the team on the prototype in the Axure share project environment, and generate the UX specifications document. These advanced prototyping concepts will be covered in depth in the last chapters of this book, but we will continuously touch upon them throughout..

Digital Library Project, Phase 1: The Proof of Concept A digital library is a perfect project for this book because it provides us with opportunities to demonstrate various Axure prototyping techniques in the context of an application that is familiar to most readers. Sometimes called''Visio'' prototype, the Proof Of Concept (POC) is a high fidelity, highly polished interactive prototype. More than anything else itis a sales tool, which plays a major role in rallying top management to support major investment in the next generation of a software product, or to persuade investors to bet on a new venture. Key attributes of the POC are: •

Not burdened too much by detailed business, functional, or technical requirements

•

Highly interactive simulation that highlights new features of the proposed approach to innovative user experience

•

Highly polished execution that incorporates branding and visual design

The POC articulates the appearance and behavior of the new software. It presents its''look and fee'' in the best of all possible worlds. The closer the actual product ends up being to the vision, the better job we did as UX architects. It is an opportunity to think''out of the bo'', while keeping in mind the fact that a box does exist in the form of budgetary and technical constraints. It is a''Jack in the bo'' demonstrated in reverse order.

[ 51 ]


Getting Started Productivity in 30 minutes Pardon me this gimmicky header, but I want to emphasize Axur''s value proposition as a primary UX design application. Any tool must balance its cost, feature set, and ease of use. If you purchase software with your own funds, clearly you ask: ""If I invest time and money in this new tool, how soon can I be productive and do actual work?"" As you will soon find out, in the case of Axure, the answer is, in a matter of days. So, le''s assume you have already completed some of the initial project tasks, including: •

Strategy sessions with various stakeholders in the company

•

Contextual interviews with end user

•

Establish a base line by conducting usability studies of the existing applicatio.

•

Review of competitive and related application.

•

Analyze the sit''s conten

•

Develop the taxonomy and global navigatio

•

Have a list of key features and user flows

•

Develop personas and a matrix of user roles and their key tasks

•

Have high-level business requirements

With this solid understanding of the product and its intended users, you are ready to dive into Axure and unleash your creative energies. In this chapter, you will learn how to use Axure to •

Create Use Case diagrams

•

Create Interaction Flow Diagrams

•

Create Pages, Masters, and Dynamic Panels

[ 52 ]

Chapter 3

Initial Requirements and Use Cases Based on discovery activities conducted so far, you have a list of high-level requirements that provide a core set of guidelines and define the product offerings. In some projects the list of business requirements is handed to you, and in other projects you can play a key role in their development. Regardless, the requirements should not define the user experience. Rather, our contribution as UX designers is to translate the requirements into a world-class practical user experience.sLet's digest the first set of requirements: 1. From the Home page, the user should be able to browse or search the library. 2. The user should be able to get more information about a title without leaving the Home page 3. Each title should have a dedicated page with full details as well as preview capabilities 4. The user should be able to search the library from any page using either a simple Google type search box or an advanced search feature. 5. Search results will be presented in a list of matching titles. 6. The user should get more information about a title without having to leave the search results screen. 7. From the search results screen, the user should be able to access any titl''s detail page. 8. If no matching titles are found, provide the user with a relevant notification Good requirements can be easily broken into short and unambiguous sentences with a syntax that includes the user, a user action, and the interaction outcome. In other words, each of these sentences becomes a use case> The high level requirements with which we started, drive the following use cases: •

Browse items of the library

•

Search the library for specific item(s)

•

Use Advance search to look for specific item(s)

•

View search results

•

Item not found

•

View item details

[ 53 ]


Use Case Diagram Page When you launch Axure, it opens with a blank new file. In the Sitemap pane add a new page just above the Home page. I recommend keeping''met'' pages such as use case and flow diagrams before wireframe pages. The order in which pages are listed in Sitemap pane is the order in which those pages will be generated in the HTML prototype and Word specifications. By placing the meta pages first you control a logical narrative that provides high level abstractions such as flows before moving into the actual interaction. This will work well in review meetings as you describe the prototype. Additionally, in a later stage, readers of the UX specification will be able to form a clear idea of the application by flowing the page progression.

Rename the new page''Use Case''. Axure provides a method to differentiate between wireframe pages and diagram pages: Right-click and select the Flow option from the Diagram Type contextual menu. Notice that the page icon has changed, making it easy to distinguish between wireframe and flow pages. Double click this new page to open it as a tab in the Wireframe tab.

[ 54 ]

Chapter 3

Wireframe and Flow pages are identical in all aspects except the icon to the left of their name,

Next, select the Flow widget library in the Widgets pane. Drag the Actor widget to the page. This stick figure is the standard representation of users in UML and most diagraming methodologies. Drag over an Ellipse widget and label it''Browse the Librar''. The Ellipse is the UML notation for use case. Continue to add and label ellipse widgets as needed:

To complete the use case diagram we want to connect the actor widget to the use cases and organize the widgets nicely on the page for a polished presentation.We will begin with the layout and organize the cases in a vertical order that follows a logical progression of possibilities

[ 55 ]


This is a great opportunity to become familiar with Axur''s three selection modes, which help moving and arranging the widget on wireframe and flow pages. You can find these in the toolbar. 1. Select IntersectedMode. This is Axur''s default mode. When you click and drag your mouse over the wireframe, all the widgets that are part of your selection area, even if they were only partially included in it, are selected. 2. Select ContainedMode. In this mode, only widgets that are fully included in your selection are selected. 3. Connector Mode. This mode is most effective when you work with Flow widgets because it generates connector lines that you can use to hook up the various flow widgets in your diagrams. Personally, I prefer mode B, the Select Contained Mode, because it provides precision by including only items fully encompassed by my selection, leaving out others that are in close proximity. Select the widgets and use the Align and Distribute options on the toolbar to balance the page visually. After all the use cases are virtually aligned and evenly distributed, group them together using the Group option on the toolbar. Select this group and, while holding the Shift Key, select the Actor Widget. Use the Align middle option to have the Actor facing the use cases

Next, switch to the Connector mode and draw lines from the Actor widgets to each of the use cases. You should end up with a page that looks something like this:

[ 56 ]

Chapter 3

Estimated time to completion: 5 minutes

Saving the Project File Now is a good opportunity to save your file. Let''s pause for a moment and consider some of the realities involved in rapid iterative prototyping. During the initial days and weeks of work, you will add tremendous amounts of detail as you address increasingly finer requirements. In some areas, you will find that ideas that had looked initially promising are not working as well as you thought. Feedback from stakeholders and users may require more changes, sometimes requiring that you backtrack to previous version It is in your best interest then, to maintain an on going history of your Axure file. When you work on a stand-alone file (.RP), this means that you are responsible for managing the revision history. I am not talking here about merely backing up your file, which is a given.

[ 57 ]


For managing the history of revisions, a technique or rather a behavior that works for me is quite simple and easy to implement: At the end of each workday, save the file. Then, use the Save As, to save the file in an Archive directory and append the date to the file name.The next day, open the file from the current directory. With this method you will have always be able to restore or find previous items and add them back to the Current file, if needed. I To setup the directory structure, do the following: 1. Create a directory on your drive and label it Digital Library. 2. In this directory, create two folders:""_Curren"" and""Archiv"". Adding the'''' character in front of''Curren'' is optional. It will ensure that this folder is listed first Back to Axure, hit the''Sav'' button. Label the file''Digital Librar'' and navigate to the''Curren'' folder. Save the file there

Estimated time to completion: 2 minutes.

First Wireframe Pages With initial use cases in place, you can move forward and create relevant wireframe pages.The pages that immediately come to mind are: •

Home Page

•

Search Results Page

[ 58 ]

Chapter 3

•

Item Details Page °°

Advanced Search Page

As you might have noticed, when you launch Axure it opens a new document, similarly to an MS Office applications like Word or PowerPoint. You will see in the''Sitema'' pane that Axure places a''Hom'' page and three nested pages. This is the default for each new Axure file For your project, you need a Home page, so one is already there. All tha''s left to do is to change the non descript''Page '', Page '', and''Page '' labels of the three nested pages to something more meaningful. Your Sitemap pane should look something like this:

Note that you can change the order of pages by using the Move Up and Move Down arrows (A) and change their nesting level by using the Indent and Outdent arrows (B). Estimated time to completion: 1 minute

Task Flow Diagram Page A prototype is tailored to visualize and demonstrate the user experience 1. The controls and views that facilitate how a user interacts with the application to accomplish specific tasks 2. The ways in which the system responds to allow the user accomplish the tasks efficiently and satisfactoril So before we can develop the demonstration, we really need to nail down the tasks that are, after all, the reason for the existence of the application. Since the scope of this book limits our discussion of the topic to the context of Axure, I will focus on task flow diagrams

[ 59 ]


Task flow diagrams are a model, an abstraction of the Ping-Pong exchange that makes up user-system interaction. These diagrams also play an important role in validating the sequence and logic of each task with business and technical stakeholders, and they are used to develop an agreement on which flows and parts of flows should be prototyped. The diagrams should be shaped by explicit context: Given a particular user, the options afforded to the user by the system and a particular user action, the system should respond in a particular way. While there are no set standards for UX flow diagrams, keep in mind that clarity, precision, and organization would help you during joint sessions with stakeholders Axure provides a one-stop shop for creating both flow diagrams and the wireframes that are associated with them. As you will soon see, the ability to use a single application for modeling, creating and documenting the user experience gives us with a powerful work environment. Two main flows that immediately come to mind involve browsing and searching. In the first option, the user can browse titles on the home page and drill down for more details. The other path lets the user search for a set of titles, or for a specific title. Matches are presented in the search result list, and the user can drill down to the details of a desired title. Thus, both paths end on the same page. Let''s create a couple of task flow diagram pages, one for modeling the ""browse"" path and the other for ""search"". In the Sitemap pane click on the home page and add the two siblings above it. Label the pages and use the Diagram Type menu to change their icon to mark them asflow pages.

Browse Path Flow Diagram To compose the diagram, follow these steps: 1. Double click to open the Browse Path page in the Wireframes pane. 2. From the Widgets pane, drag over the Actor widget 3. Now comes the cool part: From the Sitemap pane, drag over the Home page: It is the entry point to this flow. Notice that the widget inherits its label from its parent page on the Sitemap pane. Also note the document icon on the upper left corner of the widget. It means that when you generate the HTML prototype, clicking on this widget will link to the actual Home page

[ 60 ]

Chapter 3

4. Drag over a Parallelogram widget to indicate the browsing activity. 5. From the Sitemap pane drag over the Item Details page. 6. Select the four shapes and use the Align Middle and Distribute Horizontally options. 7. Change to Connector mode to draw connectors from the Actor widget to the Home page and from there to the Item Details page. Use the Arrow Style options to add directional arrow heads to the connectors. You have just completed your first flow diagram in Axure and it should look something like this:


Search Path Flow Diagram The initial requirements call for two search features: 1. Simple Search 2. Advanced Search Both methods take the user through a similar path: If any matches are found, they are displayed in a results list and the user can drill down to the detail from there. If no matches are found, the user is notified and can run a new search

[ 61 ]


Double click the Search Path flow page in the Sitemap pane to open it for editing in the Wireframes pane. As you create the flow, keep in mind that Axure aligns and distributes widgets according to your first selected widget. The following example shows a case where we have used the Distribute Horizontally option to spread out evenly group A of widgets. To align vertically group B of widgets based onthe position of widget 1, which participates in both group A and group B, click on it first, continue to select the other items, and finally, use the alignment or distribution options

As you complete the Search path you realize that it exposes an important risk. If users run either a simple or an advanced search but do not find what they are looking for, there is a possibility that the users would abandon the flow and move on to another site. Your justification for providing enhanced search capabilities should be tied to the strategic importance of ''search'' in the digital library, given the central role it plays early on in the interaction model. This insight underscores one of the major benefits of developing supporting diagrams for the prototype.

[ 62 ]

Chapter 3


Link Use Cases to Flow Diagrams In addition to being able to create and store diagrams and wireframes within the same application, you can link diagrams and wireframes to create a seamless transition from the one to the other: 1. Open the 'Use Cases' page in the Wireframe pane. 2. Right-click the 'Browse the Library' use case and select the Edit Reference Page option from the Edit Flow Shape sub menu. 3. The Reference Page popup that appears lists all the pages in the Sitemap pane. 4. Select the 'Browse Path' to link the use case to the task flow.

[ 63 ]


Continue to link the cases to the appropriate flows.


Generating HTML Prototype It is now time to generate your first HTML prototype to review the work you have completed thus far. As your prototype advances, you will find yourself generating previews quite often in order to validate that the html output works in the way you indented. Accessing the prototype feature in the PC and Mac versions is similar and is accomplished either from the toolbar icon or from the Generate menu. The Generate Prototype dialog allows you to specify various settings that impact the output. But at this early point, you want to start with the General section and let Axure know where to output thehtml prototype.

[ 64 ]

Chapter 3

Earlier in this chapter I began introducing a strategy for saving the file. As part of the approach I advocate, you created a directory labeled "_Current". Before you generate the prototype for the first time, open this directory, create a new folder, and label it "HTML". Now, launch the Generate Prototype dialog, and in the General section, set the Destination Folder to be the new HTML folder you just created. The idea behind this approach is to keep all your project information under the same directory, which makes it easier to find all your project stuff, especially when you want to transport and back it up. An alternative option is to use Axure's default for the destination folder. In this case, Axure will create a directory labeled 'Axure Prototypes'' in your Documents folder. Next, Axure allows you to specify the browser to run the prototype. Axure supports the 'native' browser in each platform; Safari for the Mac and Internet Explorer for the PC. The Mac version supports Google's Chrome and both versions support Firefox, which until now provided the best performance, especially for large, complex prototypes. My recommendation is to set Firefox as your default browser. New to Version 6 is the option Do Not Open. What it does is to generate the HTML files and code without triggering the browser to open. At first glance, it may not appear very useful since the whole idea of a prototype is to view it in a browser. However, you might find this option useful after all. Each time you generate the prototype it opens a new tab in your browser. If you generate frequently, which occurs as you add interactions, you may end up with lots of open tabs. With this new option, use your target browser when you generate the first prototype of the day. Then, use the Do Not Open option for subsequent generations, and simply use the Refresh button on the browser to view your latest work.

Finally, you are ready to view your work in HTML form. Hit the Generate button and within a few seconds the browser will display your prototype. The Sitemap pane lists all the pages we created, and the first page on the list is displayed in the center.

[ 65 ]


As you roll your mouse over the use cases you notice that the cursor changes, indicating an active link, which links you to the relevant flow task page. On the lower right corner of linked use cases you see a small icon. Clicking on this icon opens the linked tab in a new tab or a new window, depending on how you set up your browser.

To summarize what we covered thus far: •

Creating use case and task flow diagrams

•

Saving your project

•

Linking pages

•

Generating an HTML prototype.

In less than 30 minutes you were able to create a meaningful piece of work that you can immediately use in upcoming sessions with stakeholders. You have a compelling, clickable presentation, which will be impressive and help move forward the discussion.

Getting Started – Part 2 With the foundation in place, you can now develop some rough wireframes, focusing your work on high-level requirements and the information you gathered thus far. You want to focus on answering some interesting questions: •

Page Layout: How is information organized on each screen and what are the master templates for page types?

•

What are the navigation systems?

•

What are common components that are shared across screens? [ 66 ]

Chapter 3

You may have started the exploration process by sketching some layouts on paper or iPad. It is also quite possible to do that in Axure:

New to version 6 is the Sketch Effects feature, which can be found under the new Page Formatting section. You can now simulate the tentative appearance of a hand drawing in your wireframes. For early iterations of the prototype, this kind of treatment might help communicate to stakeholders that we are still looking at initial concepts. Experiment with the Sketchiness slider to find the level that works for you, and remember that the prototype is a means to an end, so use this effect sparingly. In our Digital Library project you start by outlining three layout blocks: •

Header

•

Body

•

Footer

The significant difference between creating these initial blocks on paper or a Visio type drawing software and creating them in Axure will become apparent in the coming pages.

[ 67 ]


Navigation Systems The Home page isprobably the most important page for websites just as it is for applications. However, in a world of deep links, where the user's first interaction with a site is often on pages other then the home page, navigation systems are the critical competent. At a glance, the user should be able to discern: •

Where they are

•

What the landing page is about

•

The actions available in the context of the page and the site

•

Where to navigate within the site

In order to develop the navigation systems for the Digital Library, we need to expand on the initial business requirements. The revised first requirement is: R1 A. From the Home page the user should be able to browse or search the library. For the Release 1, the library will offer subscribers three types of media: 1.1. Electronic books 1.2. Electronic Newspapers and Magazines 1.3. Streaming movies and TV shows R1 B. For each type of media the user should be able to select from a list of genres: 0.4. Electronic Books: 0.4.1. Fiction 0.4.1.1. Classics 0.4.1.2. Humor 0.4.1.3. Mystery 0.4.1.4. Romance 0.4.1.5. Thrillers 0.4.2. Non Fiction 0.4.2.1. Advice 0.4.2.2. Biography 0.4.2.3. Cooking 0.4.2.4. Sports 0.4.2.5. Textbooks 0.5. Newspapers and Magazines 0.5.1. Newspapers [ 68 ]

Chapter 3

0.5.1.1. US Newspapers 0.5.1.1.1. Chicago Tribune 0.5.1.1.2. New York Times 0.5.1.1.3. Washington Post 0.5.1.2. World Newspapers 0.5.1.2.1. The Hindu 0.5.1.2.2. Le monde 0.5.1.2.3. Times of London 0.5.2. Magazines 0.5.2.1. (Release 1 US Only) 0.5.2.1.1. The Atlantic 0.5.2.1.2. Popular Science 0.5.2.1.3. Wired Magazine We are obviously limited in space here and cannot continue to list all the sub categories for each of the media types. But, equipped with an initial taxonomy, we can begin the development of our global navigation. Note the appearance of the phrase 'Release 1' which helps define the scope of work planned for the initial launch. It also implies that future releases will expand on the initial offering, so scalability and flexibility should be an important design consideration.

Main Global Navigation Bar To facilitate access to each of the media types offered in the library, you decide to try a horizontal navigation bar that will appear on all pages, thus making it a global element. There are several benefits to this approach: •

It communicates very explicitly the type of offerings in the library.

•

It is very easy to navigate from one segment to another.

•

It is a common navigation element and most users will be familiar with it.

There are also some drawbacks to consider, such as: •

There is a scalability limit of how many categories can be placed horizontally.

•

Where and how to present items of various media types.

[ 69 ]


At this point, you feel strongly that the benefits outweigh the potential problems, so let's move to Axure. 1. Open the Home page for editing. 2. Drag down the Body and Footer blocks about an inch, to make room for the navigation bar. 3. Drag over a Rectangle widget. If you decided to keep Sketch Effects for this iteration of wireframes, the widget will have the same Sketchiness. 4. Resize the widget so it fits the space you made between the Header and Body blocks. 5. Right-click the widget and from the Edit Button Shapecontextual menu, select Tab Left. 6. From the contextual menu, select Copy, and then paste the widget 3 times. 7. Distribute and Align the widgets in a horizontal row. 8. Select the left most widget, hit the Enter (PC) or Return (Mac) keys and type the word 'Home'. 9. Label the other tabs 'Books', Newspapers &Mags' and 'Movies & TV'. 10. Save your work. Your wireframe should look something like this:

[ 70 ]

Chapter 3

The next step is to address the intra-navigation within each media-specific category page. Let''s use the Books page as a model before applying the pattern to the other pages. Also, in this early stage of work, it is important to validate such approaches with stakeholders and gain their approval. First, you need to add the new page to the sitemap. Here, you have a couple of options: 1. Since you already have a basic wireframe with repeating elements, you could right-click the Home page and select the Duplicate Page from the contextual menu. 2. Use Axure's Masters feature to make some modifications to the construction of the Home page, and build the Books page from scratch, using masters. We are going to try the second option. Add a new page to the sitemap, label it 'Books' and open it for editing.

First Masters In the Books page you want to visualize a left pane navigation bar, which would help the browsing users narrow down to the items they are looking for. You hope to use this pattern on the other media pages. When you open the Books page for editing it is, of course, blank. You want to use some of the global elements that you have already created for the Home page wireframe. The traditional method of wireframing implied pasting the wireframe from the Home page and adjusting as needed in the new page. One of the big pain-points for UX designers has always been that when a global element were changed on one wireframe, it required labor-intensive work manually to apply the changes to all the wireframes that include this common element.

[ 71 ]


In Axure, you can use Masters. Masters are components of the user interface that can be used on multiple pages. When you make a change in the master, all its instances that are used in the prototype are immediately updated. A twist that Axure has added to masters is that while the look and feel of a master is identical wherever you use it, its behavior can be tailored to fit the context in which it is used. The first master will be the global navigation bar you just created: 1. In the Wireframes pane, switch to the Home page and select the group of tabs that make up the global navigation bar. 2. Right-click anywhere within the selection and in the contextual menu, select Convert to Master option from the Convert submenu. 3. Alternatively, you can also use this option from the Object menu, in Axure's menubar.

4. Axure will prompt you with a dialog. Take a moment to read the text: 5. "Converting these widgets to a master creates a new master containing a copy of these widgets." This means that a new master will be added in the Masters pane. 6. "Then, these widgets are replaced with the new master. Note that interactions on other widgets affecting these widgets will need to be updated." This means that a single item, the master, will replace the four discrete images that you placed in the wireframe. The master, which is an independent wireframe, now has those four widgets. When we discuss interactions later in the book, the impact of this procedure will become meaningful. 7. "If you would like to continue, enter the new master name and click Continue."

[ 72 ]

Chapter 3

8. Since we do want to convert this navigation bar into a master, type in the label 'Global Nav' and hit the Continue button. 9. You will immediately notice a change in the way the navigation bar looks: All the widgets are grouped together and the entire block has a pink shade—a mask color that helps you identify masters. 10. The new master appears in the Masters pane. When you want to reuse the master in other wireframes, you will drag it out of this pane. Note, that you can have nested masters, i.e. masters that are used within other masters. The Masters pane is not contextual to a specific wireframe. Rather, it is the repository of all the masters you have in your project file. 11. A new and a great addition to Axure 6 is that all the masters that are used in a wireframeappear in the Dynamic Panel Manager pane. This pane is contextual to the active wireframe in the Wireframe pane; you can easily see which masters are used in the wireframe.

In the Home page, continue to create masters out of the Header and Footer blocks since you also need these on every page. The Body block, however, is not going to work as a master because the Home page, category pages and other auxiliary pages that will be added later do not share the same layout and content. New masters from scratch You can also create new masters without having to convert existing widgets. This is a good option when you know in advance that the wireframe will be used as a master. The two options provide you with the flexibility to be productive in various prototyping workflows.

[ 73 ]


First Custom Page Style Open the Books page for editing and drag over the three masters you just created: A Header, Global Nav, and the Footer. You immediately notice that the masters lost their Sketchiness effect. Page Formatting is disabled when editing a master in the Wireframes pane. Masters inherit the formatting applied to the page on which they are.

This happens because the Sketchiness setting for the Books pages is set by default to zero. Obviously, you want all the wireframes in this iteration to have the same appearance. Axure's Page Style Editor provides a method to apply a consistent set of page style parameters effortlessly: 1. In the Books page, click on the document icon (A) next to the Page Style attribute in the Page Formatting tab. 2. Page styles are listed in the left hand column (B). Initially, only the Default style appears. Notice that the Sketchiness property is set to zero, and that all other properties are applied. Click on the Plus icon and a New Page Style is added to the list. Notice that all properties become de-selected. 3. Give the new style a descriptive label, for example, Sketchy (D). 4. Set the Sketchiness level to your preferred level in the range between zero to one hundred (greater than zero, of course). 5. Click on the checkbox net to the Line Width property and set it to +2. 6. Click OK to add the new page style to your project. The Page Style Editor dialog will close. 7. Back the Page Formatting tab the new style will now be listed in the Page Style drop list (E). Select it. 8. The Sketchiness level you set for this page style will be applied to the Books page. [ 74 ]

Chapter 3

9. In the Wireframes pane, select the Home page tab, or open the Home page for editing, if it is not there. You will notice that that the Page Style for the Home page is Default, but the Sketchiness level is set to your original value. Apply the new style to this page as well to ensure that changes you make to the Sketchy page style will be applied to all the pages in this iteration. 10. Save your work.

[ 75 ]


Secondary Navigation System To create the left navigation pane, drag over a Rectangle widget. Notice how the Sketchiness property is applied to it. Make it tall and about twenty percent of the width of the wireframe. Add another rectangle widget as a placeholder for the Body block. The structure you want to model based on requirement R1.B.1 is: 1.1. Electronic Books: 1.1.1. Fiction 1.1.1.1. Classics 1.1.1.2. Humor 1.1.1.3. Mystery 1.1.1.4. Romance 1.1.1.5. Thrillers 1.1.2. Non Fiction 1.1.2.1. Advice 1.1.2.2. Biography 1.1.2.3. Cooking 1.1.2.4. Sports 1.1.2.5. Textbooks The Left Navigation communicates to the user the categories and a sub category available in the library, and it supports a browsing interaction pattern. Axure provides a number of ways to wireframe the structure. The Tree widget is a fast and efficient way to model a hierarchical navigation system. Drag one to the Books wireframe.

[ 76 ]

Chapter 3

After completing the tree structure, select the Left Pane rectangle widget and the Tree widget. 1. Convert the component to a master, since the three category pages will share a similar layout. 2. Label the new master 'Media Left Pane'.

First Dynamic Panel It looks like you are ready to duplicate the Books page to create an instance of Newspapers &Mags and Movies & TV pages because in these wireframes you are applying the same conceptual layout to create an efficient reusable user interface framework. Please, wait just a little longer: These wireframes share several masters, but each master should be contextual to the page on which it is located. For example, let''s consider the Left Navigation pane. For consistency in interaction on all pages, the Left Navigation pane component should have an identical position on the page and identical behavior. However, on each media page the left pane should also reflect the appropriate categories for that media. Axure's Dynamic Panel widget provides a solutionto create variations of an instance. Open the Media Left Panel master for editing. 1. Select both the category Rectangle and Tree widgets. 2. Right-click and in the contextual menu select Convert to Dynamic Panel from the Convert menu (A) . [ 77 ]


3. Alternatively, you can also use this option from the Object menu, in Axure's menubar.

1. Axure will prompt you with the Convert to Dynamic Panel dialog (B). Take a moment to read the text: °°

"Converting these widgets to a dynamic panel creates a new dynamic panel containing a copy of these widgets." This means that a new dynamic panel will be added in the Dynamic Panel Manager pane.

°°

"Then, these widgets are replaced with the new dynamic panel. Note that interactions on other widgets affecting these widgets will need to be updated." When we discuss interactions later in the book, the impact will become meaningful.

°°

"Would you like to continue?" Well, yes.

°°

I recommend not leaving the "Do not show this message again" checkbox unchecked for now.

2. Notice that when you converted widgets to a master a similar dialog also provided the opportunity to label the new master. This is not an option in the case of a new dynamic panel. Since we do want to convert this left pane into a dynamic panel, hit the Continue button.

[ 78 ]

Chapter 3

3. You will immediately notice a change in the way the left pane looks: All the widgets are grouped together and the entire block has a blue shade, a mask color that helps you identify dynamic panels on the page. 4. The new dynamic panel appears in the Dynamic Panel Manager pane (C). Dynamic panels are contextual to the page. Masters are listed in both the Masters pane and in the Dynamic Panel Manager pane and they are reusable anywhere. Dynamic panels, on the other hand, are not reusable. But you can always convert a dynamic panel to a master. 5. Change the label of the dynamic panel from Unlabeled, which is the default Axure assigns, to 'All States'. 6. Notice the node under State1. Axure automatically labels new states in an ascending order: State1, State2, etc. Change the label of the first state fromState1 to Books. New dynamic panel from scratch You can also create new dynamic panels without having to convert existing widgets. This is a good option if you know in advance that the component you are going to wireframe needs to be a dynamic panel. The two options provide you with the flexibility to be productive in various prototyping workflows.

Dynamic Panel States The Books tree is the first State of the new dynamic panel and your next step is to add the Newspapers & Mags and the Movies & TV states. 1. The Media Left Pane master should be open for editing in the Wireframes pane. Double-click the 'All States' dynamic panel. In the Dynamic Panel State Manager dialog that opens up, click the Add icon. A new state State1 will be added below the Books state. Label this new state Newspapers &Mags. 2. To add the third state repeat step one, or get acquainted with another method, using the Dynamic Panel Manager pane. Click the Add State icon there and a new state labeled State1 will be added below the Newspapers &Mags state. Label this new state Movies and TV.

[ 79 ]


3. At this point, the two new states you added are basically blank wireframes. The next step is to create the appropriate trees for each one in order to reflect the digital library's categories for these media types.

4. To open all three states for editing, click the Edit All States option either by double-clicking the dynamic panel to launch the dynamic panel state manager (A), or from the menu of 'All States' in dynamic panel manager (B). 5. Three new tabs will be added to the Wireframes tab, with the first state, Books, as the active tab ready for editing (C). This is a nice tweak to previous versions of Axure, where the last state would be the active tab. 6. Remember that the dynamic panel itself 'All States' resides on the master Media Left Pane (E), which currently is placed in the Books page (F).

[ 80 ]

Chapter 3

7. Copy the tree and rectangle widget from the Books state wireframe and paste it in the Newspapers &Mags state wireframe. 8. In the Newspapers &Mags edit, the tree to reflect the category structure per requirements R1B2: 9. Newspapers and Magazines °°

Newspapers °°

°°

°°

US Newspapers °°

Chicago Tribune

°°

New York Times

°°

Washington Post

World Newspapers °°

The Hindu

°°

Le monde

°°

Times of London

Magazines °°

(Release 1 US Only) °°

The Atlantic

°°

Popular Science

°°

Wired Magazine

[ 81 ]


As you complete the tree structure, it becomes clear that the nodes are wider than the containing frame you initially set for this navigation element. The fastest way to resolve this minor issue is to expand the width of the rectangle not only on this state but also on the Books state. Adjusting the width is an opportunity to become acquainted with the Size and Position options (A). We will discuss advanced techniques to handle such cases in a later chapter. For now, keep in mind the balance between fast and dirty vs. complex and potentially slow. The goal is to stream fast when developing initial concepts for validation. So even if adjusting the width of a widget on several states manually appears a bit primitive, it is the appropriate thing to do now.

10. In the Newspapers & Mages wireframe, widen the Rectangle of the left pane so that the tree fits in comfortably. The goal is to prevent wrapping of the tree nodes, while keeping the width of the Left Pane at a proportionately reasonable size in relation the body section. Note the width in the Size and Position fields. 11. In the Books state wireframe, apply the same width to the Media Left Pane in the Width field in the Size and Position option. 12. Copy the tree and rectangle widget from the Books state wireframe and paste it in the Movies & TV state wireframe. 13. There, edit the tree to reflect the category structure per requirements R1B3: °°

Movies °°

Action & Adventure

°°

Children & Family

°°

Drama

°°

Foreign [ 82 ]

Chapter 3

°°

°°

Sci-Fi

°°

British TV

°°

Kids' TV

°°

TV Comedies

°°

TV Dramas

TV

It looks like you have almost completed your first dynamic panel, which means that the Media Left Pane master can be used on the other media pages. 1. In the Sitemap pane duplicate the 'Books' page. 2. Re-label 'Copy of Books' as 'Newspapers & Mages'. 3. Repeat step one and re-label the copy 'Movies & TV'. 4. Use the Down arrow to move this page below the 'Newspapers & Mages' page. At this point, the Wireframe Pane tabs bar is becoming crowded with all the open wireframes. Use the Tab Menu to close all tabs.

Wiring Navigation Systems Generate an HTML prototype of the work you have done so far. Sure enough, the wireframes are not clickable. Switching between the four main pages is only possible if you click the relevant page on the Sitemap pane. The two most basic interaction goals we want to accomplish at this time are: 1. Make the Global Nav work – Clicking any page on the top horizontal master should switch to the relevant page. 2. It will be nice if the Global Navis contextual and visually reflecting the page we are on. 3. Make the Media Left Pane change to the relevant state when the associated media page is selected. [ 83 ]


Let's begin with the first goal: 1. From the Masters pane, open the Global Nav master for editing. 2. Click the 'Home' tab. 3. Click the Interactions icon in the Widget Properties pane. 4. The interaction we want to accomplish is straightforward: When the user clicks the Books tab, link to the Books page. So, the action word is Click, and the OnClick action will facilitate the desired interaction. 5. Click the OnClick action and select Add Case from the contextual menu or alternatively, double-click the OnClick line to launch the Case Editor dialog. 6. We will discuss the Case Editor dialog in Chapter 5, but there is nothing more inspiring than a quick preview: °°

For now, ignore Step 1: Description

°°

In Step 2: Add actions, click the Open Link in Current Window. It is the first item listed under the Links group of actions.

°°

The two columns, Step 3 and Step 4 columns will become populated. Step 3: Organize actions, will show the action Open Link in Current Window and Step 4: Configure actions will list all the pages currently in the Sitemap pane.

°°

From the list of pages in Step 4, select 'Home'.

7. Click OK to close the Case Editor dialog. 8. Save your work. Repeat these steps for each of the tabs, and generate an HTML prototype. I admit that I am always pleasantly satisfied clicking around the clickable HTML prototype. Simulating the experience creates a compelling case when you demonstrate the concepts. Another important benefit is that any problems with the interaction are strongly pronounced and more evident as compared to a static page-by-page presentation.

[ 84 ]

Chapter 3

Adding Visual Effects The Global Navigation works, and it is time to enhance the user experience with visual effects in response to user actions. In our example, the Global Nav is constructed from Rectangle widgets and for these Axure supports the following styles: •

Rollover

•

Mouse down

•

Selected

•

Disabled [ 85 ]


In the past, we had to create dedicated graphic files for each of the states and deal with the JavaScript required to make the simulation actually work. Moreover, managing changes in style implied the need to recreate the images. With Axure, here is yet another example where a previous hit on productivity and speed of iteration has been eliminated. To apply the rollover style: 1. Open the Global Nav master for editing. 2. Select all four tabs and right-click anywhere to get the contextual menu (A). 3. Select Edit Rollover Style from the Edit Button Shape sub-menu. 4. In the Set Rollover Style Dialog (B) that appears, set the desired style. In our example here, I will stick to a Grayscale palette. The background will be Black, the type will be White and Bold. Note that in order to apply the Bold style to the font, you have to press the B icon next to the Click to Toggle Bold property. 5. Axure provides a 'live' preview of the style: Check the Preview checkbox (C), to see how the widgets appear on rollover. 6. Click OK when you are satisfied with the rollover style for the Global Nav. 7. Back on the wireframe, a new Black and White square (E) appears on the upper left corner of each widget. This is a Rollover indicator. Move your mouse over the square to preview the rollover state for this widget.

[ 86 ]

Chapter 3

You can continue and set the Mouse Down and Selected styles. Prototype in Color or Grayscale? If you ever want to start a heated debate among UX designers, bring up this topic. From a perspective of pure efficiency, at this early phase of the design, colors slow you down without adding significant value to your discussions with the stakeholders. If fact, the discussion may end up being prematurely diverted to the topic of visual design and branding. Initial focus on a scalable interface framework, navigation systems and information architecture tends to be more focused in grayscale.

Apply Group Selection You want to make the Global Nav contextual so that the navigation bar would visually reflect the active page on which the user is. Axure 6 provides an improvement over previous versions with a fast and easy method to support such navigation behavior: 1. Select all the widgets in the Global Nav wireframe. 2. Right-click anywhere and in the contextual menu select Assign Selection Group from the Edit Button Shape submenu (A). 3. In the Selection Group popup (B), type a name for this group of widgets. For example, GlobalNav. Click OK to close the popup.

The Selection Group feature means that when a member of the group is set to Selected, all other members of the group will be set to their default style. This is great, because you do not have to worry about explicitly resetting each of the other widgets to the default style. [ 87 ]


Now, as you generate the prototype, the Global Nav has the following working behaviors: •

Respond to rollover

•

Mouse Down

•

Linking to the appropriate page

The context behavior still has to be wired. We will address this in the chapter on Interactions.

Update Task Flow Diagrams Now you realize that the Browse path flow diagram has to be updated. The initial flow does not reflect the fact that the user can browse the media pages in addition to the Home page. Your task now is to update the wireframe on you own, without a step-by-step description of the process. The end result, including linking to reference pages, should look something like this:

[ 88 ]

Chapter 3

Summary Congratulations! In about an hour or so you have made quite a progress. In fact, you have plenty of materials to review in your upcoming meeting with business stakeholders.

[ 89 ]

Interactivity 101 In this chapter we will cover the fundamental structure of Axure interactions—the powerful feature that empowers non programmers to develop high-fidelity, fully responsive UX prototypes. We'll review the triad that makes an interaction: Events, cases, and actions in the context of a typical UX practice, which means taking into evolving business requirements, wireframe construction strategies, the impact of interaction on the Work specification document, and how to implement a consistent naming convention to make it easier to built interactions and deliver a clear specification document.

Overview Before we dive into the nuts and bolts of Axure interactions, a brief discussion of the evolution of user experience is in order, because historical perspective provides valuable insights into the reasons for and nature of changes in the way people interact with computers. These changes, in turn, define the way we do our job as UX practitioners evolves, and the type of tools we embrace in order to keep up with constant change. Like quick-drying cement, professional conventions and patterns set in fast, making it difficult to respond quickly to new demands. Twenty five hundred years ago Heraclitus observed: "Nothing endures but Change," and this still holds true today. Axure emerged in response to a growing need for a UX-specific tool that could move us from the static to the dynamic—A tool that empowers a UX pro to create compelling rich user interaction fast and without dependence on the services of a programmer or advanced programming skills.

Interactivity 101

Traditionally, user interface designers have been using basic tools to visualize the user interface. From the proverbial napkin, index cards, sketch books, and other paper products to general-purpose software such as PowerPoint, drawing software such the Adobe trio Illustrator, Photoshop, or Fireworks and of course, the all time favorite, Microsoft Visio. With the exception of visual design and branding related mockups, low fidelity static wireframes were the norm for user interface deliverables. Why?

The 1950-60s Many historical and practical reasons contributed to the predominance of the static wireframes approach. The chief reason is the fact that the discipline of User Experience as we think of it today emerged only in the 1980s. In the 1950s and 1960s the reality was different: •

Computers came in room size flavors and at a cost a small country's budget.

•

Computers were used primarily in scientific, military, government, or large corporate settings.

•

Most development was done in-house for specialized hardware, with proprietary programming languages that supported it.

The target user-base was small and intimately familiar with the intended functionality of the software. Input was loaded via punch cards and later keyboards and the computer 'run' the software from start to end. The user experience of that era could be compared perhaps to baking a cake: Follow a recipe using the required ingredients, put in the oven, and hope that the outcome is edible. Logic and algorithms were paramount, placing programmers and analysts in a natural position to control all aspects of software development.

[ 92 ]

Chapter 4

Under these circumstances, in the early days of software development, the general public had little exposure to, experience with, control over or expectations regarding computers in general, and even less when it came to interaction with computers. The common perception was that working with computers was limited to smart people, and the idea that computers are difficult to use took root.

The 1970s The Personal Computer (PC) began to trickle into the market in the 1970s and turned into a real commercial success with models such as the Apple II and, in 1981, the IBM PC. Human-Computer interaction in these systems was facilitated by the keyboard and operating systems such as Microsoft DOS. Despite the many changes brought by the PC, development methods and software complexity remained much as they were in earlier decades. Nonetheless, the PC, as these system came to be known, marked the beginning of a dramatic transition from a user interaction that is strictly controlled by, limited to and conducted in a business environment, to one that happens in home settings. Initially, there was a minor hitch. Once you got your new box, there were very few software titles available to do what you wanted. In order to use new software, or more importantly, play a new game, you had to write it yourself. So naturally, programmers continued to control all aspects of software creation. A new and hugely successful business model emerged from what started as a past-time hobby— software development. While the size and cost of computing has placed the ownership of a computer within the reach of consumers, remaining hardware and software limitations has several implications: •

Extensive use of abbreviations. From file names that could be only eight characters long, to truncated terms ('Ext P' instead of 'Extended Price'), to the notorious Year 2000 fiasco.

•

Extensive use of reference codes substituting entire words and phrases, with number or letters. For example:

•

°°

1 for "Exempt"

°°

2 for "Non Exempt"

°°

3 for "Not Applicable" and so on

The correlation between the code and what the code stood for was not on the interface, but rather included in a training document or user manual.

[ 93 ]

Interactivity 101

•

Keyboard shortcuts and obscure key combinations were the only method for user input. The benefit was fast data entry and the drawback was the increased load on memorization requirements.

•

12" to 14" monochrome, and later color monitors at a resolution of 640x480 were the standard display hardware. This small real estate translated to proliferation of windows, dialog boxes and horizontal scrolling. To complete a single task, a user was frequently required to negotiate many windows, dialogs boxes and other prompts, which disrupted and slowed down the natural flow of relatively simple tasks.

This list includes some of the key ingredients for cryptic, ambiguous and difficult to use software. The prevailing perception that software is complicated and hard to use was even further enhanced.

The 1980s The 1980's moved the personal computer to new grounds in terms of user interactions although paradoxically, this had not, initially, result in improved usability. Several major breakthroughs contributed to a new paradigm of HumanComputer interaction: •

The GUI (Graphical User Interface)

•

The Mouse (Direct Manipulation)

•

WIZIWIG (What-You-See-Is-What-You-Get)

The Graphical User Interface: Born out of the pioneering work at the now legendary Xerox PARC, iconized by the Apple Macintosh, and much later popularized by Microsoft Windows, the GUI offered a new and exciting user experience that was much less dependent on keyboarding and memorization of key combinations and codes. Instead, representational metaphors such as the Desktop, the Trash, folders and icons provided new cognitive facilities to bridge the gap between the user's mental model of the steps involved in performing a task, and the way the task was modeled in the software. The smaller the gap, the more intuitive the software is perceived to be. Another invention, a small device fondly named 'the mouse,' further empowered users through the concept of Direct Manipulation: The ability to control the screen without the arbitration of a keyboard. Terms such as Point-and-Click, Double-Click and Dragand-Drop, became an inseparable part of our daily lexicon. Another groundbreaking innovation of the era was WIZIWIG: What You See Is What YOU Get. The profound idea that the screen representation of a document, which the user sees and edits, is almost identical, in terms of size, positioning and color, to a paper output.

[ 94 ]

Chapter 4

For the first time since the beginning of computing, programmers were stepping into an unfamiliar territory—the 'graphic' part in Graphical User Interface. Numerous decisions must be made on issues such as layout and organization of information, colors palettes, typography, positioning and alignment of UI widgets, choice of graphics for icons, and many others. And as new features were added to a software, a good programmer would look for the most logical place to add them, while others would be satisfied with any empty piece of screen real estate. Over the life cycle of a product, the user interface would become increasingly bloated, expensive to extend or support and very difficult to use. Software further maintained its reputation as being complex, confusing, and not intuitive. Software publishers and organizations had to increase their spending to develop extensive training and customer support. And yet very often, attempts to improve the software by changing the interface encountered great resistance—from users. Even when the usability of software was simply atrocious, the users invested considerable efforts in mastering the beast. A class of 'Power Users' emerged in every organization. These were the people who figured how to 'work' the system and knew its obscure and undocumented features. They internalized numerous key combinations, codes and shortcut and felt in complete control. These people taught themselves and others how to be productive using an unproductive tool. With this mastery often came power and a sense of job security. An offer to change the software to improve it implied a real loss of investment and power. The 'User' part in Graphical User Interface emerged. But it would take another decade and a half, and the introduction of a dramatic new invention in commuting, before the term User Experience would become synonymous with a discipline that plays an integral role in the life cycle of software development.

The 1990-2000s The World Wide Web, as it was known in the early days, initially meant a great setback for user experience. For example: •

Narrow bandwidth facilitated via slow dialup connections meant that pages could take long minutes to render.

•

The entire page had to be refreshed upon clicking any hyperlink, leading further to poor performance.

•

Competing and slightly incompatible flavors of web browsers meant that a page, designed for viewing on one browser, was not likely to render correctly on another browser.

•

The comforts of having familiar conventions for a GUI desktop client were gone, replaced by numerous user interfaces, as each website has its own design. [ 95 ]

Interactivity 101

These inconveniences were simply the unavoidable growing pains of an unstoppable progress. Innovations such as the Amazon Checkout and Google Search introduced new paradigms of powerful simplicity and turned the Internet from a somewhat naïve democratic virtual environment to a fiercely commercial one. The Internet proved to be the great equalizer, immortalized in a 1993 New Yorker cartoon by Peter Stiener, showing a dog using a computer telling another dog: "On the Internet, nobody knows you are a dog". In the context of our discussion, two aspects of the reality depicted by this cartoon are especially relevant: 1. Compared to traditional software development, creating simple websites was and still is lighting-fast and it does not require programmers, although programmers remain essential for more complex applications. Consequently, "everyone and their grandmothers" began creating websites. 2. Whereas in the commercial world, the cost of changing software vendors was often prohibitive, website publishers soon found out a bitter reality: The abundant availability of alternatives meant that the competition was only one click away. Moreover, it could be difficult to distinguish between a site created in someone's bedroom, and one created by a global company. If the first was better, users flocked to it. These two factors paved the way to effectively associating usability with revenue. The fledgling, disjointed, and little understood practice of user interface design began to emerge, sprouting methodologies such as Joint Development and User Centered Design. An argument emerged, that an investment in understanding users' needs may in-fact yield better software.

The 2000s The discipline of user experience has matured since the beginning of the new century. The Web was transformed in the last decade, shedding many of its early stage problems with user experience. Several factors played a role: •

The advent of high speed internet

•

Fast, inexpensive computers

•

Browser compatibility

•

Data interconnectivity via web services

•

The Semantic web and increased decoupling of data from the way it is displayed

•

Data updates without page reloading

[ 96 ]

Chapter 4

Users developed much higher expectation for ease of use from commercial applications, and user experience has been placed front and center. Businesses began to see the user interface not as eye candy but as a strategic asset. New terminology, specifically addressing measurement of website effectiveness, has been introduced: •

Analytics – The tools and methodologies to quantify the traffic of users on a site.

•

Conversion – How many visitors actually complete a transaction.

•

Retention – How many users are loyal to the site and return with more business.

More trends quickly emerged, most importantly, social networks, emergence of cloud computing and mobile devices. The shift towards placing the user at the forefront of software development, and the focus on measurable, result oriented design, helped push the industry towards a formal recognition of user experience as a potential revenue generator instead of a cost center. In practical terms— – actual line items in the budget for user experience services and usability testing— – unheard in an earlier decade.

The Present, Future, and Axure Interactions If you read this book and the year is 2020, chances you are doing some anthropological research into ancient UX methods, or perhaps there is nothing better to do. On a more serious note, there is no doubt that we are seeing amazing advancements in user to user experience. We have moved from user experience that is defined by and limited to computer screens and input devices, to interaction with all kids of devices using our body gestures, flick, etc. The current decade is shaping up with new hardware, especially, tablets such as the iPad and powerful smartphones. 3D offers some intriguing opportunities for truly immersive user experience and undoubtedly, new user interface conventions. Considering the history and evolution of user experience, it is clear that we are in a midst of enormous transition, and that our ability to simulate current and upcoming experiences is critical. Axure's interactions are a game changer with respect to enabling UX designers to gain independence in the creation of high-fidelity prototypes. Over the years Axure has expanded the vocabulary of building blocks that make up its interactions features. A delicate balance has to be maintained. On the one hand, Axure should not be too complicated or too similar to programming so that not to undermine the core idea of the tool. On the other hand, Axure needs the capacity to simulate complex interactions, such as drag-and-drop, animation, etc. So far, Axure has been able to maintain a good balance between these two seemingly competing needs.

[ 97 ]

Interactivity 101

Understanding Axure Interactions As a generalization, software has two types of Users or Actors, as most modeling methodologies refer to them: •

Human actor (the user)

•

System actor (the software and other components that make it work)

The two are engaged in a constant dialog. The human actor interacts with the system actor by providing direct inputs via keyboard, mouse, touchscreen, and other input options. The system responds by displaying or requesting contextual and appropriate information. Axure's basic interaction model is made of the following triad: 1. Events – which are essentially triggers for actions. Events are contextual to the widget types and can be also be used on pages and masters. 2. Cases – Organizational buckets for interaction paths. Each event may have one or more cases. 3. Actions – The outcome of an event. Each case may have one or more actions.

Anatomy of Axure Interactions Let's look at a very simple example of a widget with an interaction. Suppose you have a button widget on the Home page. In the HTML prototype, clicking the button takes the user to Page 1. And this is how it looks like behind the scenes, in Axure: 1. The button (A) has a little Footnote icon on its upper right corner (B). The footnote is numbered, in this example, '1', which indicates that the widget has some annotation or interaction assigned to it. Also worth knowing is that Axure automatically numbers widgets according to their order of appearance on the page – from the upper left to the lower right. So, if you add a widget above and to the left of this button and renumber the footnotes (Wireframe > Renumber All footnotes) the footnote for this button will be '2'. 2. You access widget interactions from the Widget Properties pane (C). The Footnote and Label fields (D) are where you can edit this information. Note that you can override Axure's default assignment of the footnote number by typing into the footnote field. The information in these fields applies to the three tabs of the widget properties page. 3. You create, edit and view widget interactions in the Interactions tab (E). The asterisk on the tab is a visual indicator that appears on the tab only if there is an interaction there. This is convenient when you are looking at another tab of the Widget Properties pane. [ 98 ]

Chapter 4

4. The Interactions Menu (F) allows you to Add, Edit and Delete Case. The menu is contextual, so the various options are available only when a widget is selected. Edit and Delete Case options are active when you select a particular case for the widget. 5. The event that is available for the widgets (G) is listed below the interaction menu. A widget may have one or several possible events. In our example below, the Button widget has only a single possible event, OnClick. Doubleclicking the event brings the Case Editor window, which is where you create and edit cases. You can expand or collapse event nodes. You can right-click an event to see a contextual menu with the following options: °°

Add Case

°°

Copy All Cases

°°

Paste Case(s)

6. As these options suggest, you can copy a case or all the cases from one widget to another. The events do not need to match, meaning that you can copy a case you created for an OnClick event and paste it into a OnMouseOver event on the same or another widget. 7. Creating an interaction for widgets is optional and without the interaction a widget is merely a graphical shape. When you drag a widget from the Widget pane to the Wireframe pane, no cases are associated with it. Once you create the case (H), it is nested under the event for which it was created. Double-clicking a case opens the Case Editor Window. You can have one or more cases for each event. You can expand and collapse case nodes. You can right-click a case to see a contextual menu with the following options: °°

Edit Case

°°

Move Case Up

°°

Move Case Down

°°

Delete

°°

Copy Case

°°

Paste Case(s)

°°

Toggle IF/ELSE IF

8. When you have two or more cases, they are listed in a menu that appears when you interact with the widget in the HTML prototype. This is how you demonstrate the possible interaction paths planned for the widget. Notice the ability to change the order of cases. This is why you can control the order of appearance on the menu. You can also use drag-and-drop to change the order. We are going to discuss the use of conditions in chapter 5. [ 99 ]

Interactivity 101

9. Nested below each case is the action associated with it (I). Each case may have one or more actions. Double-clicking an action opens the Case Editor Window. You can right-click an action to see a contextual menu with the following options: °°

Move Action Up

°°

Move Action Down

°°

Delete

10. Axure executes actions in order, and you can control the order from this menu, or by using drag-and-drop. We discuss later in this chapter how to troubleshoot interactions by changing the order of actions.

Axure Events In Axure we can create interactions that respond to two types of events, or triggers: 1. When a page (and masters on a page) are loaded in the browser. This happens when you first open the prototype in the browser and when you navigate from one page to another. 2. When a user directly interacts with a widget.

[ 100 ]

Chapter 4

Event Triggered By Pages and Masters Think about this concept as a staging setup, an orchestration of actions that take place behind the scenes and are executed just before the page gets rendered in the browser. Moreover, it is a setup that can use conditions and variables to deliver a different rendering of the page depending on the user actions in previous steps. In short, the OnPageLoad event, which can be applied to pages and on masters, is likely to become one of your frequently-used methods to control you prototype.

Changing the Default Landing Page When you generate the prototype, it always loads the top-most page. In our example, it is the Use Case page. However, as you move from modeling flows to wireframing, testing and presenting the prototype, it becomes desirable to start on the home page, or some other page, depending on your needs. This is an opportunity to demonstrate an interaction that is triggered when a page is being loaded in the browser. It is always good to clarify to yourself the interaction objectives you are trying to simulate. The Objective: As soon as the first page of the prototype loads in the browser, it redirects to load the page you want. That page is the one that will be displayed in the browser: 1. Open the Use Case page for editing, and in the Page Properties pane switch to the Page Interactions tab (A). 2. The OnPageLoad (B) is the only interaction available. Click it to open the Case Editor window (C). 3. For our demonstration now you can skip Step 1, the Description field, as we will be discussing naming conventions shortly. Instead review Step 2, which lists all the possible actions for the interaction. The Links group of interactions is the one that handles navigation and is the most relevant to what we are trying to accomplish. 4. Of the Links actions, Open Link in Current Window, (D) which happens to be the first action of the group, it the most appropriate. Click the action and it will be added to the Step 3: Organize Actions column (E). 5. When you click the action in the Step 3 column, all the pages in the sitemap are listed in the Step 4: Configure actions column. Click the Home page there (F), to identify it as the target page to load. 6. This is it for what you want to accomplish now. Click the OK (G) button to close the Case Editor window.

[ 101 ]

Interactivity 101

7. The new case (H) is now listed under the OnPageLoad interaction. Reading the interaction is easy: because it is using natural language to describe what should happen: When the page loads open Home in the current window. 8. Notice the asterisk that was added to the Page Interactions tab (I). This is visual marker indicates that the page has interactions., and is a useful reminder when the Page Properties pane is completely minimized and only the tabs are visible. Generate the prototype. The first page to be the Use Cases page, but, before it renders, the browser will see the redirection action and load the Home page instead.

[ 102 ]

Chapter 4

Selected State and Contextual Navigation There are currently three masters on the prototype Home page, and they are listed in the Dynamic Panel Manager: 1. Header 2. Footer 3. Global Nav The Global Nav is the only object that needs changes from page to page. Since the main starting page for the prototype is the Home page, we want the Home tab on the Global Nav be in its 'selected' state when the page loads. (See chapter 3 where we created navigation states). Such a visual clue helps orient the user by clearly answering a basic question: Where am I on this site? The Objective: When the Home page loads, switch the Home tab of the Global Nav to from its Normal state to its Selected state. 1. When generating the Home page (A), the browser (B) renders all four tabs of the Global Nav are rendered at their Normal state. The Home tab (C) does not reflect which page we are on. 2. Switch to the Page Interactions tab in the Page Properties pane and click the OnPageLoad interaction. The Case Editor (e) window will open. 3. We want to effect the Home tab which, construction-wise a Tab-Left widget. The Widgets and Variables group of interactions is the one that handles widget interactions. 4. Of the Widgets and Variables actions, Set Widget(s) to Selected State, it the most appropriate. Click the action and it will be added to the Step 3: Organize Actions column (F). 5. All the widget we currently have on the page are listed in the Step 4: Configure actions column. Find the Global Nav section, and select Home (Button Shape) to Selected button. (G) 6. A new case, Case 1 has been added to the OnPageLoad interaction in the Page Interactions tab (H).

[ 103 ]

Interactivity 101

7. Generate the prototype and in the browser, the Home tab (I) will be set to its selected state when the page loads.

[ 104 ]

Chapter 4

More Context with OnPageLoad Events In chapter 3 you created the Global Tab master and assigned the tabs to a Selection Group. Consequently, when you now mouse-over the other tabs, each will show its selected state. You also set each of the navigation tabs to link to their corresponding page in the sitemap. This should work now, however, the navigation bar, with the exception of the Home page we just worked on, does not switch to their selected state. For example, from the Home page, click the Books tab to link to the Books page. The Books tab will not switch to its selected state. But, you know how to fix this based on our earlier discussion on making the Home tab switch to selected state. State of the Prototype: The global navigation works nicely, with the appropriate tab switching to its selected state on the relevant page. However, the Media Left Pane is still showing the categories for books. The Objective: Get the Media Left Pane to change in context to the page it is on. The Media Left Pane is master that is constructed of a dynamic panel with three states, each corresponding to one of the main media categories. The easiest method to get the dynamic panel to load the appropriate state is to use the OnPageLoad event for each of the three media pages. Because a dynamic panel will, by default, display the first state, we don't need to worry about the Books page. So let's do the Newspapers & Magazines page: 1. Open the Newspapers & Mags page for editing. The asterisk on the Page Interactions tab in the Page Properties pane indicates that we have some interaction for the page: Case 1 sets the Global Nav to display the relevant tab in its selected state. We want to edit this case and add another action to the same OnPageLoad trigger. 2. Click Edit Case or double click Case 1 (A) to open the Case Editor. In the column Step 2: Add actions, we look at the Dynamic Panel group of actions (B). Since we want to change the state of a dynamic panel, the action Set Panel State(s) to State(s) is the one we need. 3. When you click this action, it is added to Case 1 in the Step 3 column, just below the first action that sets the News tab in the Global Nav to its selected state (C). 4. The column Step 4: Configure actions lists the Media Left Pane master (D) which is on the page. This master has currently the only dynamic panel, All States on the Newspapers & Mags page. Select the relevant state from the lower section of the column (E). 5. Click OK to close the window. Now, the OnPageLoad will execute the two actions. [ 105 ]

Interactivity 101

6. Repeat these steps for the Movies & TV page and generate prototype.

Page and Master Event Flow Here is a detailed look Axure's page and master level OnPageLoad event: 1. The browser gets a request to load a page (Step 1), either because it is the first time you launch the prototype, or, as a result of a navigation from one prototype page to another. 2. If your page (Step 2) is constructed of widgets that need to change in context to the page, you want to orchestrate how the page will render by creating the relevant OnPaheLoad trigger. For example, a dynamic panel that needs to load in a particular state. 3. The page may also have one or more masters (Step 3) and each of these may have an OnPageLoad trigger of its own. A good reason to do so is when you want to control the way a master renders, regardless of the page it is on. OnPageLoad on the master will spare you the need to recreate the interaction on each page the master is used.

[ 106 ]

Chapter 4

4. The browser first checks for OnPageLoad interactions (Step 4), If none exist, the browser renders the page. 5. If OnPageLoad exists, the browser first evaluates page level actions first, and then, master level. As we will see in the next chapter, one of the benefits of this order of operations means that you can set the value of a variable on the page's OnPageLoad trigger, and use that variable for the master's OnPageLoad trigger. More about variables is discussed in chapter 5. 6. If the OnPageLoad trigger includes a condition (Step 5) the browser will evaluate the code accordingly and execute the action (Step 6) or set of actions (Step 7), otherwise, if the OnPageLoad event does not include a condition, the browser will execude the action(s) (Step 8). 7. The requested page is rendered (Step 9). You can apply this trigger to both pages and masters and the actions taken prepare a new page to be displayed.

User Triggered Events Like the real application, the prototype will respond to user actions. The closer the prototype simulates the systems' response, the easier it is for stakeholders and for user participating in usability testing of the prototype to predict how the application is intended to work in production. We achieve a higher fidelity in the prototype by making widgets respond to user-initiated events such as click, rollover, drag, and so on. [ 107 ]

Interactivity 101

Back to the Requirements Before we continue with our discussion on widget level events, we should iterate on the prototype a little because we need more depth in our demo in order to explain new interaction concepts. With a basic navigation system in place, and an initial solid support for a Browse path, let's move to integrating the Search into the framework. In discussions with business stakeholders, a couple of implicit business requirements for Search came up. These may not necessarily end up in the formal Business Requirements Document (BRD), but are an example to tactical requests that are important to the stakeholders that you will want to consider and incorporate into the design: 1. Pre-Search: While we want to provide the most successful search experience to help the user easily find what they are looking for, the search feature should NOT be too prominent. The site wants to interest the user with new offerings and avoid the 'tunneling' effect that is inherent to search—one that focuses the user only on the item they want. 2. Post-Search: If the user did use search, we want to offer related alternatives in Item Detail page, and interest the user to these items. The feature, first popularized by Amazon.com's social recommendation system turned out to be exceptionally effective, and has become standard on many ecommerce applications. You also have the more formal requirements for Search, which include the need to support: •

Simple and advance search

•

Search across all media types

When considering where to place Search, you are also aware of the need to add other typical elements to the prototype, they include but are not limited to: •

User Sign In and Sign Out

•

Profile & Setting

•

Help

•

About Us

•

Contact Us

•

Legal Stuff (Such as Privacy Policy, etc)

[ 108 ]

Chapter 4

At the early stages of the project you may not have any requirements for some of these and many other features. It is typical that the requirements are created in parallel to the design and feed each other, or that there is no organized process of formalizing the requirements. So it often rests on the shoulders of the UX designer to introduce various features and functionalities that support and enhance the user experience.

For scalability and modularity reasons, you make the following design decisions: •

User 'Sign In' and 'Sign Out', 'Profile', 'Contact', and 'Help' will be on a header bar above the site's logo. Since at this point the site's logo is not ready yet, it is probably best to leave the entire row open.

•

'About Us' and 'Legal' Stuff will be in the footer.

The new additions mean adding a new master 'Top Header Bar' to the file. The footer text can be updated with the relevant item. At this point, the prototype Home page and the three main media pages that share the same layout, should look something like this:

Simple Events: Adding OnMouseOver State Let's start with a simple widget event. At this point, you have the high level navigation framework working. What's missing is a bit of refinement when moussing over the categories on the Left Media Pane to enhance the visual feedback to the user.

[ 109 ]

Interactivity 101

Adding the interaction for this is straightforward. 1. Open the Left Media Pan master for editing and proceed to open the first state. 2. Select the first note (A), and right click. In the contextual menu select the Edit Rollover Style option (B). 3. In the Set Rollover Style dialog (C) set a style for this state. For a Tree widget. Changing the font properties such as size, color or appearance. Having the background color is not recommended because it is applied only to the width of each tree cel. Because the width of cells differ, the resulting effect in typically too jarring. 4. Check the Preview option (D) to help you tweak the desired appearance of the rollover effect (E).

[ 110 ]

Chapter 4

Construction Considerations Another section of the interface where you want to consider using the rollover interaction is on the Top Header Bar. A couple of paragraphs ago you created a section that facilitates user sign in, access to profile, help and contact information. This appear a trivial task and I did not provide specific construction directions for a reason. Which is getting you into the habit of thinking ahead about which widgets to use when constructing the prototype wireframes. For example, in the case of the Top Header Bar, the quickest approach would seem to use the Text Panel widgets. However, you can not create rollover effects for this widget. Thus, if you plan to simulate a rollover effect, use the Rectangle widget instead. You typically want to set Fill to transparent and Line width to none for the normal state, and apply some variation to the rollover state. A typical use my be to keep the background as is, but make the font bold and add an underscore. Do we really need this level of detail in the prototype that early in the process? This becomes a relevant struggle on each prototype: What kind of details should be introduced at which stage of the prototyping process?

Widget Event Flow Below is a detailed look Axure's widget level event flow: 1. The user actively interacts with a widget on an application page by initiating an event (Step 1) that is associated with that widget (Step 2). 2. The type of widget constrains the possible response the user can expect (Step 3). For example, before clicking a button, the user may move the mouse over it, and the visual appearance of the button will change in response to the rollover event. 3. The browser will check if conditional logic is tied to the widget event (Step 4). For example, you may have created a interaction in which a rollover event will display different states of a dynamic panel depending on a some variable. The browser will evaluate the condition and execute the action(s) (Step 5). 4. If no conditions exist, the browser will execute the action(s) associated with the widget (Step 6).

[ 111 ]

Interactivity 101

5. Based on the actions tied to the event, the browser will update the screen as needed. (Step 7).

Contextual Widget Events Each of Axure''s built-in widgets, with the exception of the iFrame, can be assigned an interaction. No single widget can perform all possible actions, which is a good thing, because most widgets have inherent, well- established constraints. For example, a radio button can be selected or deselected, enabled or disabled and that''s about it. So events are contextual to the widgets they are bundled with. Place a widget in the Wireframes pane, as while you have it selected. Then, switch to the Interactions tab in the Widgets Properties pane to see the event or events that are associated with it. Note that you don''t have to create interactions for widgets. A widget without an interaction will appear as part of a static image when the wireframe is rendered in the browser. It will not respond to clicks, and mouse overs. The image below

[ 112 ]

Chapter 4

Axure Cases Use cases are among the fundamental elements of interaction design, with each use case providing a summary or an abstraction of a discrete path the user can take. A common formal methodology is to document all possible user cases and their alternativ, address the most important ones in the prototype and document the rest in the UI specifications document Another aspect of use cases is the fact that the user interface has to be contextual to the user. Most common situation is the differentiation between a visitor to the site, and a user that has signed in. Until the user signs in, some functionality is typically disabled. Once the system knows who the specific user is, that functionality can become available

[ 113 ]

Interactivity 101

Axure facilitates not only the documentation of use cases in diagrams, but also in the prototype. In principal Axure, cases are used for the following: 1. Simulate one or more interaction path(s) for a widget based on some condition. For example, Case 1 will show the first state of a dynamic panel, and case two will show another state of the same dynamic panel, depending on which button the user clicked. 2. Simulate one or more interaction paths for different type of users. For example, show one state of a dynamic panel when demonstrating the path of an Admin user, and another state for a standard user.

Demo Prototype Example Back in our demo project, the business stakeholder contemplate several revenue options, and are thinking to offer two types of accounts: A free account which provides limited access to content and is supported by advertising, and a tiered paid account, from basic, which provides metered access to content, up to premium, which grants unlimited access to all content. You want to present the differences between the free and paid layouts

The requirements 1. When the visitor enters the site, the Top Header Bar provides a link to create a new account and another link, to sign in. There will be NO third party banners or advertisements on the initial state Home page. 2. Upon clicking the Sign In link the user should be prompted to enter a username and password, and also have a''Forgot Passwor'' option 3. After a successful sign in, the""Create New Accoun"" link should be replaced a link to a profile management page. 4. If the user has the free account, show an ad banner above the header, and in other areas of the screen 5. No ads should be displayed for other account types, promotional materials could be used in various areas of the screen but not above the header. The Objectives: Demonstrate, using cases, the differences in the Home page between a free account and paid account users. Case 1

Show the initial Home page for visitors

Case 2

Show Home page for Subscriber with Free account

Case 3

Show Home page for Subscriber with Paid account [ 114 ]

Chapter 4

Construction Considerations The first set of questions is more strategic: Do we really need to create three copies of the Home page? It appears to be such a redundancy. If we do that, w''ll have toemanage these versions and keep them consistent. Why ca''t we just use interactions to show and hide various elements on the Home page depending on the sign in situation? These are valid options and indeed, it is possible to construct your prototype using a single Homepage, if you want. But the decision is typically driven not so much by the technical possibilities of Axure, as much as it is affected by the practical realities of the project. The situation described in this example is driven by business considerations and as such, it is most likely that future sessions with stakeholders will focus on the integration of advertising and calls for actions on the site and there is a high probability for big changes in the requirements. If rendering the appropriate page relies on interactions, you might find your self busy trying to get interactions to work instead of focusing on the interface. A second set of questions is more tactical: The Top Header Bar, which facilitates the login and account functionalities, and is visible on most primary pages of the site, is a master with four links (for now). Wireframing the bar would seem like a straightforward task. But let's review the construction options: 1. Place the four rectangle widgets in a single dynamic panel. The first state will be used to visualize the how the bar appears to a visitor, the second state showing how the bar appears to the signed in user. 2. Make only the Sign In rectangle widget as dynamic panel, with the first state showing Sign In, and the Second State showing Sign Out. 3. Decouple the Sign In rectangle widget from the other widget in the Top Header Bar master and convert it to another master, with a dynamic panel and the two states. 4. Convert each of the elements on this top header bar its own master. And so on. So many options! Indeed, it is not always easy to know in advance which construction path to take, often because you just don't know enough about how the widget you are wireframing will evolve in terms of its functionality. It is a combination trial and error and work experience that quickly gets you to mostly optimal choices.

[ 115 ]

Interactivity 101

The KISS Principle Stick to the design principle Keep It Short and Simple (KISS) – It is always possible to elaborate on the construction of a widget, but getting into complex structure too early in the game is an invitation to trouble because the design changes constantly, so the amount of re-work will increase.

Construction with UI Specifications Document In Mind Thinking about the Word output can help you determine your construction approach. It is never too early to think about additional deliverables that are dependent on your Axure work. In addition to an interactive prototype, a detailed UI specifications is a common deliverable expected from UX. In the very early stages of working on a prototype, especially if it is a vision prototype which are typically a throw-away, you focus most of your energies on coming up with a compelling concept. The goal is to get the buy-in for the concept and business stakeholders are interested in the interactive HTML visualization. But after the acceptance of the vision, the file becomes more and more focused on addressing real requirements, and the development team is eagerly awaiting the written specifications. The way you construct your wireframes has a major impact on your Word specifications document. I will address these considerations in discussing options in the demo project.

Adjusting the Wireframes First, we need to update the wireframes on order to visualize the visitor and the signed in states.

The Top Header Bar 1. Open the Top Header Bar master for editing. Select all the widgets there, right-click and use the Convert to Dynamic Panel option. 2. In the Dynamic Panel Manager pane, add a second state. And open both states for editing. 3. Select all the widgets in State 1, copy and paste them into State 2. 4. Back in State 1, re-label the rectangle widget 'My Profile' as 'Create Account'. As a result of this modification, your might have to widen the Top Header Bar dynamic panel because this state will be wider since the 'Create Account' widget is wider. [ 116 ]

Chapter 4

5. Switch to State 2 and re-label Sign In as Sign Out.

The Top Advertising Banner Next, we want to add the top advertising banner. Since it will be used on multiple pages we know it needs to be set as a master, so: 1. As a shortcut, duplicate the Footer master. This will ensure that the banner will be in the full width of your wireframe. Re-label the master "Top Ad Banner". 2. Change the widget from a Rectangle to Placeholder, and make it taller, say 80 pixels. 3. Convert the widget into a dynamic panel. We need three instances of the Home page: 1. Initial state for visitors. 2. The free account version, with advertising. 3. The paid subscribers version, without advertising. The simplest, fastest option to show the various versions of the home page is to duplicate the one Home page we already have: 1. In the Sitemap pane, right-click the Home page and select Page from the Duplicate option in the contextual menu. Repeat this twice. 2. Re-label the original as "Home [Initial]" and the first copy as copy as "Home [No Ads]" and the second instance as "Home [With Ads]". 3. With the "Home [With Ads]" page open for editing in the Wireframes pane, choose Select All from the Edit menu or alternatively, use the appropriate keyboard shortcut. 4. We want to shift the entire content of the page down to make room for the ad banner which is 80 pixels high. Switch the Widget Properties to the Formatting tab and set the value of Top in the Entire Selection section to 110. 5. Drag over the Top Ad Banner and place it above the Top Header Bar.

Creating Cases for the 'Sign In' Link Continue by enabling the 'Sign In' link on the home page. For now let's bypass the username and password prompt and just afford a method that will let you quickly demonstrate the two home pages: 1. Open the Top Header Bar master for editing and select the 'Sign In' widget (A). [ 117 ]

Interactivity 101

2. In the Widget Properties pane switch to the Interactions tab. 3. Click Add Case to bring up the Case Editor. In the field description, type in "Case 1: Free Account". Click OK to close the case editor. Note that yellow footnote that appeared on the upper-right corner of the widget is cut off and you can't actually see the footnote number. We'll revisit this later. 4. Back in the Interactions pane, click Add Case again, and label the new case: "Case 2: Paid Account". Click OK to close the case editor. 5. The OnClick event now has two cases associated with it (B). 6. Generate the HTML prototype and click the 'Sign In' link. A gray menu will appear (C), offering the two options. At this point nothing will happen if you select any of the options, but you've taken the first step towards.

[ 118 ]

Chapter 4

This type of a manual case selector is very handy when you present the prototype to stake holders and when you are considering several alternatives of the same screen. In chapter six we'll use variables and conditions in order to simulate an actual login flow that will switch automatically to the appropriate Home page. With cases in place, we can add the actions.

Axure Actions Earlier in this chapter we looked at Axure events, which trigger actions. We described Cases, which are the organizational units for one or more actions triggered by an event. As we now continue with our demo project, notice the richness of functionality we can simulate and the fact that no programming skills are needed, just a bit common sense. There are currently twenty five action, organized in four groups:

Links Actions These actions are parallel to the HTML target attribute, such as _self, _parent, etc. which specifies where to open the linked document. They are mostly self explanatory and used to facilitate navigation. The frame actions allow you to take advantage of the iFrame widget, and load a page within a page, or even multiple pages within a page.

Dynamic Panel Actions Dynamic panels are the widgets that are responsible for the prototype 'magic'. You control horizontal, vertical and depth position, visibility, and movement.

Widgets and Variables Actions Where applicable, you can enable or disable widgets. For example, fields, radio buttons, or checkboxes. You can set focus on a widget, which is great for placing the cursor in a particular form field when a page loads. As we demonstrated earlier, you can set a widget to a selected state and this will work as long as you create a selected state for the widget. Finally, there are some specialized actions for the tree and image map region widgets.

[ 119 ]

Interactivity 101

Miscellaneous Actions The wait time is self explanatory and extremely useful for setting up timed interactions. The other is basically a text place holder where you can articulate in writing some action that should take place. We are going to discuss the raised event action in great detail shortly because it is one of the most important actions, and one of the least understood.

Let''s look at how actions, cases, and events are tied together:

Back to Example: Wiring the Cases for the 'Sign In' Link For the first case, we want to show the Home page with the advertising banner. 1. Back in the Top Header Bar master, open the first state and double-click "Case 1: Free Account" for the OnClick event. The Case Editor opens.

[ 120 ]

Chapter 4

2. What we want is simply to link to the "Home [With Ads]" page, and the appropriate action is in the Links group, Open Link in Current Window. 3. Continue to add the same action to "Case 2: Home [No Ads]". 4. Switch to the second state and link the "Sign Out" widget to Home [Initial] page. Generate the HTML prototype and play around with the case switcher. It works nicely from any page whenever you click the Sign In link. An additional detail that needs to be added is to set the state of the Top Header Bar to the Signed In state for both instances of the logged in Home pages. You might think that it only makes sense to string a Set Panel to State action to the OnClick cases that we are setting for the Sign In button.

Taking a Wrong Turn… It is important to keep in mind that Axure does not prescribe a set formula for wireframe construction and for building interactions. This is good because only you can dream up the user experience for the application you are working on, and we all crave the technical flexibility that helps us express our creativity. There is also a bit of a cautionary note, because the flexibility means that Axure gives you enough rope to hang yourself with. Typically, it is not a big deal at all—we learn by doing, by trial and error, and by experimenting with the possibilities. So, let's continue with our demo prototype that has been going so smoothly so far. I am going to take a wrong turn here, deliberately. My next steps will appear logical and sensible, but something will not work quite as I expected. This will happen to you too every now and than. The key is not to get frustrated, but to work through the issue and come up with an alternative that works. 1. Open "Case 1: Free Account" (A) in the Case Editor. Since we want to change the state of a dynamic panel, click the Set Panel State(s) to State(s) action (B). It will be added to the Step 3: Organize actions column (C).

[ 121 ]

Interactivity 101

2. Only one option appears in the Step 4: Configure actions column, and unfortunately, it is difficult to figure out if this is the dynamic panel we need because the action is described as: Set Unlabeled (Dynamic Panel) state to State 1 (D). Below, in the Select the state droplist, our options are equally ambiguous: State 1 and State 2 (E).

What's In A Name? What to do next? How can we tell that this unlabeled dynamic panel is the one we need? Which of the state is the correct state? As the prototype evolves, it will be virtually impossible to figure out unlabeled widgets in the case editor. This situation underscores one of the most important housecleaning tasks when creating a prototype: Name everything. Like any form of documentation, it is a tedious task, but absolutely necessary. It is possible to get away with labeling in the very early states of wireframing, but as soon as you start creating interactions, unlabeled widgets become a frustrating liability. For teams, this is an even more critical concern, because you may be using a widget created by another team member and have no idea at all how it is constructed. [ 122 ]

Chapter 4

We are going to discuss naming conventions in the next part of this chapter, but let's try to put a Band-Aid around the current situation. Fortunately, since we are working on the Top Header Bar master, we are confined to a single dynamic panel and two states. 1. Open the Top Header Bar for editing. 2. In the Dynamic Panel Manager pane (A), rename the 'Unlabeled' dynamic panel "top header bar'—it is the same label as the master, but in lowercase. 3. Name 'State 1' as 'Before Sign In'. 4. Name 'State 2' as 'After Sign In'. The comparison between the unlabeled widgets (A) and the labeled widgets visualizes the importance and value of naming nearly any widget you add to the prototype.

More about naming soon, but lets try to finish with the case interactions: 1. Open "Case 1: Free Account" (A) in the Case Editor and click the Set Panel State(s) to State(s) action. It will be added to the Step 3: Organize actions column. 2. Only one option appears in the Step 4: Configure actions column (C) but this time it is clearly labeled as: Set top header bar (Dynamic Panel) state to Before Sign In. 3. In the Select the state droplist switch to the After Sign In state (D).

[ 123 ]

Interactivity 101

4. Repeat with Case 2 and generate the HTML prototype.

As you soon find out, choosing any of the cases when clicking the Sign In button works fine, with the exception that the 'top header bar' dynamic panel does NOT change states. You can double and triple check the case editor and all will appear to be set up correctly. What is wrong?

[ 124 ]

Chapter 4

Masters and Interactions Axure masters are self-contained units of the interface that you have created for the purpose of reusing on multiple pages and sometimes multiple times on a single page. A master has no idea where it is. Widgets within the master will interact among themselves reliably, but when the master needs to interact with the page it is on, you need to remember a couple of important items: 1. A masters can not directly affect the page it is placed on. For example: Suppose a page with a master and a dynamic panel. You want a button in the master to change the state of the dynamic panel in the state. When you try to create this interaction, you will find that the master does not list that dynamic panel and that you can not create this interaction directly. Instead, you can use the Raised Event action, which will be discussed in details in chapter 5. 2. Each instance of a master has no awareness of the existence and state of other instances of the same master. A master's state does not persist from page to page. We can use as an example the problem we just encountered with the demo prototype. Although the master is placed on both the initial Home page and on the target home pages, each of these masters is an independent instance. The instruction given to the button to change the state of the dynamic panel is lost when the new page loads.

Back On Track Fortunately, it is easy to resolve the problem by stepping back and reconsidering our interaction approach. Instead of changing the state of the Top Header Bar from within the master, we can use the OnPageLoad event on each of the target home pages and switch the top header bar dynamic panel to the signed-in state. 1. Open the Home [No Ads] for editing. This is a page you duplicated, and so it has maintained the original OnPageLoad interaction. We want to add a Set Panel state to State(s) action and select the After Sign In state. 2. Repeat for the Home [With Ads] page and generate the HTML prototype. Everything should work just fine—you can sign in and sign out effortlessly.

[ 125 ]

Interactivity 101

Devil in the Details When you show this early prototype, you get really good responses, overall responses are very favorable. But you note that a couple of stakeholders were not clear on how you sign into the site. Remember—you took a shortcut by making the sign in link go directly to the relevant pages. But what we find in practice is that shortcuts that make a lot of sense to us, are not always evident to our audience. This can be surprising at times, but there is no escaping the reality that, as the prototype get more and more interactive, the audience expects to see even the most minor details work interactively. Your challenge is to balance between the focusing on the most important items that need to be visualized, and the non essentials. At the extreme is the risk of ending up prototyping the entire application—which is contrary to what prototyping is about. You also realize that, since there are several options to tackle the Sign In process, you want a streamlined option that will make it as fast and easy as possible for an account holder to sign in.

The Username Password Popup You want to propose an inline sign-in prompt: When the user clicks the Sign In link, a popup with a user name and password field appears. In discussions with stakeholders, all agreed to allow the user's email address to serve as the username, and everyone prefers this to taking the user to a specialized sign in page. Modularity Should this popup be part of the Top Header Bar, and specifically, part of the Sign In button there, or an independent master? Whenever such a question comes up, try to anticipate if the objects will be used independently of each other. In this case, since the sign in popup can only be triggered by the link, it is safe to keep them together. In principal, however, you want to keep the construction as modular as possible to maximize flexibility and reduce redundancies.

1. Open the 'Top Header Bar' master for editing and switch to the first state: 'Before Sign In'. 2. Wireframe a sign in popup (A). Remember that you can simulate a text field to behave like a password field (B). 3. Select all the widgets that make up the popup, right-click and use the Convert to Dynamic Panel option. 4. Re-label the panel as "Sign In Popup". Since only a single state is needed for now, you can keep its label 'State 1' for now. [ 126 ]

Chapter 4

Copy and Paste Cases and Actions The addition of the Sign In popup means that clicking the 'Sign In' link first brings up the popup, and the option of which case to display should be triggered by the Sign In button in the popup. To save having to re-create the interactions, Axure lets you copy and paste entire case from one widget to another. 1. Click the 'Sign In' widget (A) in the "top header bar". In the Widget Properties pane right-click the OnClick interaction (B) in the Interactions tab and select Copy All Cases (C) from the contextual menu. 2. Open State 1 of the 'Sign In Popup' dynamic panel and click the 'Sign In button' (D) to select it. In the Interactions tab, select the OnClick event, rightclick, and select Paste (E) from the contextual menu.

[ 127 ]

Interactivity 101

3. The two cases are now added to the event associated with the sign in button in the popup.

For now we can skip the Forgot Password path, and just add an interaction to the 'Cancel' link, to hide the popup.

Change Panel Visibility Back to the 'top header bar' Sign In link, we want to remove the original cases that we just shifted over to the popup. Instead, clicking the link should bring up the Sign In Popup. 1. Right-click the Sign In Popup dynamic panel and select the Set Hidden option from the Edit Dynamic Panel in the contextual menu. 2. Click the 'Sign In Link' widget. In the Interactions tab select 'case 1: Free Account', and click the Delete Case link. Repeat for Case 2. [ 128 ]

Chapter 4

3. Double-click the OnClick event and in the Case Editor associate choose the Show Panel(s) action. 4. I recommend that whenever you use the Show Panel(s) action, you always add to it the Bring Panel(s) to Front action as well. The reason for this is that the widget may be obscured by some other widgets and just showing it will not be sufficient. Generate the HTML prototype and click the Sign In link to test the interaction. If you just followed my instructions, most chances are that the popup will not appear. A bit of troubleshooting, perhaps some frustration until the Aha! Moment: The problem is that we just forgot to adjust the size of the of the 'Top Header Bar' dynamic panel (A). As you recall, only widgets that are visibly within the boundary of the panel will render in the browser and Word specification. Fortunately, this is an easy thing to fix by adjusting the size of the panel until we can see the Popup in its entirety. Generate the HTML prototype again, and this time the Sign In Popup should appear (C). When you click the Sign In button there, you will be able to choose to which Home page to link using the case menu (D) that now appears there. Further refinement is probably needed, perhaps a better visual definition of he the Sign In Link when the popup is displayed, and so on. But remember that this is still a very early draft of the prototype and it is best to move on, as there is lots to do.

[ 129 ]

Interactivity 101

Naming Conventions What's in a name? As it turns out, a lot, when it comes to implementing a coherent naming convention for Axure prototypes. In the coming pages I will propose a well tested naming convention that I've used on a number of very large scale projects. Some of the ideas here were developed with my colleagues Elizabeth Srail, Katrina Benco and Alfred Kahn.

Benefits •

Standard, easy to follow convention that standardizes the naming of Axure element at every level of the prototype.

•

Avoid the "Unlabeled" plague that makes it extremely hard to create advanced interactions, or to make sense out of the specification document.

•

Quickly determine when reading the Word spec or CSV output if we are looking at a page, master, dynamic-panel or state—just by the ID.

•

Consistency, which is critical for large shared project with multiple designers working on a shared project file. Eliminating 'Tower of Babel' syndrome where each UX labels items.

•

Traceability – Many projects involve some sort of a traceability matrix, a list that ties the requirements to delivered wireframes. The ability to provide an explicit pointer up to a widget level becomes important and you can save countless hours by utilizing such a naming system.

•

Internationalize – Greatly improve the process of localization. Instead of relying on a label which may not be unique, these ids makes it easy for teams across the globe to make references to any item of the UI with confidence.

•

Productive – When used from the project get-go, save the UX team significant amount of time in downstream consistency enforcement and tons of reworking.

•

Transferable – These are domain agnostic id's and so, you can use them on any Axure project, and there is no need to reinvent the wheel.

The Anatomy of a Page ID Here are some examples of a page ID: •

FW-101 Home [Initial]

•

FW-102 Home [No Ads]

•

FW-103 Home [With Ads] [ 130 ]

Chapter 4

The ID of each of those examples is composed of the following elements: 1. Application Section or Workstream Prefix 2. Page number 3. Page Name

The Workstream Prefix

Most applications are divided into several sections. Large applications have multiple teams of designers assigned to those sections. Additionally, there is typically a common set of wireframes associated with the user interface framework, or a portal. So the idea to start each id with the section or workstream it is associated with. The prefix is made of two letters and a dash. The section prefixes in our demo project could be: •

UI Framework = FW-

•

Books= BK-

•

Newspapers & Magazines = NM-

•

Movies & TV = TV-

The process of coming up with the 2-letter prefix should be straight forward, although it is important to keep in mind: •

Domain nomenclature (For example, Pharmacy could be PR, but RX makes more sense).

•

Avoiding confusion in the future (another example from a medical records portal is that the patient section prefix could be PT but it may be confused with a Physical Therapy section (widely known as PT)

•

Naming conventions of other partners in the project that may have started their work before the UX team. Often, the business process team is in place early on. The goal is to gain alignment and reuse confusion.

Why 2 and not 3 letters? To make the overall id as short as possible. As you will see later, the id can become quite long.

[ 131 ]

Interactivity 101

Page Number Each application section or workstream is assigned a numerical range that will be used for issuing unique ID's for its pages and masters. Just by looking at the wireframe or widget number it becomes easy to associate the object to the workstream. I found that using the 900s range for framework pages and masters helps distinguish these wireframes from the rest, which can be useful when checking consistency of global elements. In our demo, let's use the following: •

FW = 900 to 999

•

BK = 100 to 199

•

NM = 200 to 299

•

TV = 300 to 399

Once the prefix is in place, the Sitemap panel should have the following top-level pages that will help each UX workstream organize their pages under the shared sitemap. Axure's sitemap panel does not support folders as the masters panel. Continue to create the corresponding nodes on the Maters panel—here we can take advantage of folders to structure the wireframes without creating extraneous pages. Note that we add "M-" to all masters to help distinguish between masters and pages.

Page Names Names should be meaningful and self-explanatory to provide maximal clarity to all stakeholders. Keep in mind that you need to communicate with others, so avoid shortcuts, ambiguous names. In the case of multiple instances, such as in our demo project we have not one but three Home pages. To avoid confusion, use square brackets around the attribute that associates the page. The page name is separated from the page number with a space. •

Home [Initial]

•

Home [No Ads]

•

Home [With Ads] Use proper capitalization and space words to maximize readability. Remember - the goal is effective communication.

[ 132 ]

Chapter 4

Masters ID Here are some examples of master IDs which we could use in our demo project: •

M-FW-900.1 Global Nav

•

M-FW-900.2 Header

•

M-FW-900.6 Top Header Bar

Master IDS begin with the letter M (for master) and a dash, followed by the same construct as a page ID. Master numbers should never be associated to a particular page number. That's because masters are placed on multiple pages, and using the ID of one will create confusion.

Dynamic Panel ID Here are some examples of dynamic panel IDs which we could use in the demo project: •

M-FW-900.5_1 all states

•

M-FW-900.6_1 top header bar

Dynamic panels inherit all but the name of the page or master they are on. Instead, an underscore is placed immediately after the page or master number. The first dynamic panel on the page or master will be one, and the rest, if any, will be number serially. A space will separate the number from the name of the dynamic panel, which should be in lowercase.

State ID Here are some examples of state IDs which we could use in the demo project: •

M-FW-900.5_1.1 Books

•

M-FW-900.5_1.2 Newspapers & Mags

•

M-FW-900.6_1.1 Before Sign In

•

M-FW-900.6_1.2 After Sign In

States inherit all but the name of the dynamic panel they are part of. Immediately after the number of the dynamic panel add a period. The first state will be one, and the other states, if any, are numbered sequentially.

[ 133 ]

Interactivity 101

Note that the IDs of masters and dynamic panels are very likely to change: Masters may often start with one of the workstream, but might later be used across other parts of the UI, and become part of the UI Framework. Dynamic panels may initially e used on a single page, but then converted to a master. It is important to rename those ids ASAP to reduce confusion.

Nesting Nesting is common to Axure wireframe construction. Dynamic panels within dynamic panels, masters within masters and so on. Here is an example of a nested dynamic panel that could be used in our demo project: •

M-FW-900.6_1.1_1 Sign In Popup

The state of this nested dynamic panel are: •

M-FW-900.6_1.1_1.1 State 1

The underscore is the visual separator that makes it possible to identify in a glance the nesting levels of a widgets. The number of underscore is always equal to the nesting levels. For example, three underscores in the ID mean that the widget is nested three levels deep. Lets analyze the following nesting example:

A

B

C

D

E

F

BK-

121

_2.1

_1.2

_2.1

State 1

Application section or workstream prefix

Page number

The 1st state of the 2nd dynamic panel on this page

The 2nd state of the 1st dynamic panel which is placed in C.

The 1st state of the 2nd dynamic panel which is placed in D

The name of the state E

[ 134 ]

Chapter 4

Here is an example of the id of a dynamic panel state that is associated with a nested master:

A

B

C

D

E

F

G

H

M-

FW-

900

.1

_1.3

_1.2

_4.8

Something

Master indicator


Application section or workstream number. This number is the same for all the masters associated with the section or the workstream.

A running serial number indicating how many masters are in a workstream or section

The 1st state of the 3rd dynamic panel on this master

The 1st state of the 2nd dynamic panel which is placed in E.

The 8th state of the 4th dynamic panel which is placed in F.

The name of the state G

Widgets IDs Widgets are associated with the page, master or dynamic panel they are placed on. If you are expected to deliver a UI specifications document, there is no escaping the need to ID widgets on your wireframes. If you don't use consistent and traceable IDs, the audience who consume your documentation, primarily the developers, will be at a complete loss when trying to figure out how widgets in the screenshots tie to the annotations. Here are some examples: •

M-TV-305-BTN.1 Submit

•

BK-111_1.3_1.1-DL.2 Quantity

[ 135 ]

Interactivity 101

The widget inherits most of its ID from the page, master or state it is on, except that element's name. Instead, a dash is used to indicate the start of the widget portion. Use a shortcut to indicate the kind of widget. A period and a running serial number indicate how many widgets of this sort are on the reference page, master or state.

A

B

C

D

E

F

G

BK

-111

_1.3

_1.1

-DL

.2

Quantity


Page number

The 1st state of the 3rd dynamic panel on this page

The 1st state of the 1st dynamic panel which is placed in C.

Widget type. In this example, Droplist Widget

A running serial number for this particular type of widgets. In this example, the 2nd droplist on E.

The name of the widget.

Use the following shortcuts when creating a widget ID or come up with your own. As long as you use these consistently, things should be fine: •

Image= IMG

•

Text Panel= TPNL

•

Hyperlink= LNK

•

Button= BTN

•

Table*= TBL

•

Text Field= FLD

•

Text Area= TXTA

•

Droplist= DL

•

List Box= LBX

•

Checkbox= CBX

•

Radio Button= RBTN [ 136 ]

Chapter 4

•

Horizontal Line= HR

•

Vertical Line= VR

•

Image Map= IMP

•

Inline Frame= IFRM

•

Menu Vertical= MV

•

Menu Horiz= MH

•

Tree= TR If you named widgets on a dynamic panel which later became part of a master, renaming will be required. While tedious, this effort will prevent confusion, especially in the UI specifications document. Keep everyone in the loop about your naming convention scheme. You will find that there is a lot of appreciation to this methodological approach.

Summary In this chapter we covered the fundamental aspects of Axure interactions. Each unit of interaction is composed of an action one or more cases and, for each case, one or more actions. Interactions can be associated with pages, masters and contextually, with widgets. It is up to you to determine which elements in a prototype should be interactive, and to what level of fidelity the interactions should mimic the actual applications. As a rule of thumb, focus on your deliverables and on the value that each interaction can provide to making the prototype communicate better your intention for the user interaction. It is also important to keep in mind that a highly successful and well received interactive prototype may not yield a clear and easy to digest specifications document. If a specification document is part of your deliverables, start experimenting very early with the output of your prototype as a Word document. In the next chapter we will cover more advanced aspects of Axure interactions. But don't let the word 'Advanced' scare you off. In fact, as you probably noticed by now, the learning curve for Axure is not that steep. It is how you construct your wireframes and interactions which require experience. But this is true in any professional tool.

[ 137 ]

Advanced Interactions Don’t let the word ‘advanced’ scare you away from this chapter! I am going to cover a set of features such as raised events, condition and variables, and terminology, which is usually associated with programming and suggests complexity. It is understandable if you are not interested in or intimidated by the requirement to write code. You may wish to avoid using this set of Axure features as long as possible. You should not. First, rest assured that no coding is involved. By now you are familiar with Axure’s Interactions and the Case Editor features, which require you only to select from a contextual selection of options and construct interactivity by pointing and clicking. The only typing required is labeling. You will find a similarly easy-to-use interface when you use features such as the Condition Builder or simulate ‘drag and drop’. Secondly, think about some of the terminology and methods we use in interaction design. We use branching logic to determine use cases, scenarios and how functionality responds to user interaction under certain conditions. Axure makes it fairly easy to model the logic we need, in order to visualize branching paths, and express it in the interactive prototype. Finally, not only will you maximize your investment in Axure, you will also enhance our own professional skills and have an opportunity to express your creativity. Much like learning a new language, the greater your vocabulary, the more expressive your communication. It is the same with professional tools; and like any professional tool, Axure more than anything else, is an enabler for your creativity. So let’s dive right in.

Advanced Interactions

Conditions When you incorporate conditional logic into your prototype, you save yourself from a great deal of overhead work. If you don’t use conditional logic, you are limiting your ability to simulate conditional interaction in your prototype. Let’s face it – we use logic all the time, even if the results are not always logical. And in computer science and interaction design, we must use conditional logic in order to accommodate variable situations and exceptions. Yet, there seems to be a general reluctance to deal with direct use of logic when it comes to using software. A good example is the so called ‘advanced’ search feature that most search engines, including Google, offer, and the reason why Google’s concept of a single search field and no operators, had become the standard search interface. Axure makes it very easy to use conditional logic in your prototypes. Let’s walk through a simple example in a ‘sandbox’ file. This is the fastest way to learn how to apply conditions in your work. Sandbox for Learning and Experimenting Sometimes, the most effective way to figure things out is by experimentation. In the course of prototyping, you will find yourself wondering how some feature works, or wanting to explore a new interaction. Create a blank new file, save it to your desktop, work through your exploration on this file, and then apply your learning to the production file. This will help you focus just on the mechanics of the feature you are trying to understand and will keep your production file free of unnecessary and unrelated overhead.

Example The Objective Our goal is to change the state of a dynamic panel based on a user input. This is a simplified example of a common construction method used, for example, for creating contextual forms. • In the initial state, the dynamic panel is hidden and the droplist is set to ‘Select from list’. • If the user selects the value‘A’ from the droplist, show the panel and set it to state 1. • If the user selects the value ‘B’ from the droplist, show the panel and set it to state 2. • If the user selects the value ‘Select from list’ from the droplist, hide the panel. [ 140 ]

Chapter 5

Preparation 1. Create a blank directory on your desktop and label it ‘Axure Sandbox’. The reason to create an entire directory is that we need to have a container to hold all the files that Axure creates for the HTML prototype. 2. Create the ‘sandbox’ Axure file: If you are using the Windows version and you have another project file open, Axure will prompt you to save it before launching the blank new file. If you want to keep your project file open while you work on the sandbox (or some other Axure file), launch a new instance of Axure. If you are using the Mac, Axure supports multiple files in a single instance. When you save the new file label it ‘Sandbox’. 3. In the Sitemap pane, delete Pages 1, 2 and 3 that Axure creates by default for every new file. You should have the Home page open for editing in the Wireframes pane. 4. Drag a Dynamic Panel widget over and open State 1 for editing. Drag over a Rectangle widget. Double-click the widget and type the letter A. Also, change its background color to Blue. 5. Add another state, open it for editing and drag over a Rectangle widget. Type the letter ‘B’ and change the background color of the widget to Red. 6. Set the visibility of the dynamic panel to ‘Hidden’, preparing it to the initial state. 7. Drag over a Droplist widget and create the three options needed: “Select from list’. ‘A’ and ‘B’. Label the droplist ‘User Selection’.

Setting the Interaction with Conditions We are ready to build the interaction. This step should be triggered when the user changes the value of the droplist. Given the selection, the dynamic panel is visible or hidden. If it is visible, either state 1 or state 2 should be displayed. 1. Click to select the droplist, and from the Interactions tab, create the first case double-click the OnChangeevent (A)to launch the Case Editor. The appropriate action is Set Panel state(s) to State(s). 2. In the Case Editor, click the Add Condition link (B) to launch the Condition Builder window (C). 3. The first condition row check for if the droplist selection equals “Select from list”(D). The condition row is contextual, which makes it very easy to build conditions, especially if all the widgets on your wireframes are properly labeled.

[ 141 ]


4. Close the Condition Builder. Back in the Case Editor, select the Hide action. Now, the browser evaluates the selection of the droplist, and if it is “Select from list”, it will keep the dynamic panel hidden. Your first case (E) is done. 5. Close the Case Builder, and add a new case to the OnChange event (F). Repeat the steps above to add a condition that checks of the value of the droplist is ‘A’ and an action that sets the state of the dynamic panel to State 1 (G). 6. Repeat to add the third and last condition to checks for ‘B’ in the droplist and an action that sets the dynamic panel to State 2 (H). 7. Generate the HTML prototype. The dynamic panel should respond to your droplist selection.

[ 142 ]

Chapter 5

Condition Builder Deep Dive The Importance of Labelling I’m going to use our previous example to walk you through Axure’s Condition Builder window, which provides a contextual and structured environment to construct conditional logic. I added a second droplist to help compare the use of the builder with labeled and un-labeled widgets. Since conditions are associated with widgets, knowing which widget you are using can spare you a lot of grief. Widget

Label

Dynamic Panel (A)

Options

Drop List (B) Values:

1stSelection

Select from list A

B 2nd Selection

Drop List (C)

Values:

Select from list 1

2

State 1 (D)

Blue

State 2 (E)

Red

[ 143 ]


The Condition Builder Window You trigger the Condition Builder from the Case Editor window. Axure allows you to create one or more conditions per case. Conditions are not required, but they open up significant opportunities for simulating complex interactions.

Satisfy All or Any This option, at the top of the window (A), is relevant if you create two or more conditions. All or any is a somewhat friendlier terms to use instead of the Boolean operators And and Or.All • The default is ‘all’ (of the following) conditions. Suppose you have two conditions. In this case, the interaction will happen only if both conditions are satisfied. In the example above, you want the dynamic panel to change to State 1, if: • The droplist “1st Selection” equals “A” • and • The droplist “2nd Selection” equals “1”. • Any • In this case, the interaction will happen if one or both conditions are satisfied. In the example above, you want the dynamic panel to change to State 2, if: [ 144 ]

Chapter 5

• The droplist “1st Selection” equals “B”or • The droplist “2nd Selection” equals “2”

Clear All conditions You will find yourself repurposing widgets frequently. It saves time. But when you copy a widget that has interactions and conditions attached to it, the pasted widget will inherit them. The Clear All (B) feature makes it easy to clean up all conditions tied to the widget and start from scratch, if needed.

The Condition Construct Each condition is a row made of four or five columns, depending on the type of condition you are testing. The importance of labeling widgets is underscored again because in each condition row (or condition construct), you need to identify widgets twice. This would be impossible if all the values in the Widget droplists are ‘Untitled’ (D1).

1

Condition [C]

Applicable to Widget or Variable [D]

Evaluation [E]

Value [F]

Widget or Variable [G]

is checked of

-Checkbox

-equals

-value

If you select value:

-Radio Button

-does not equal

-value of variable

-true

-is checked of

-false If you select value of variable: - variable name If you select is checked of: -Checkbox -Radio Button

[ 145 ]


2

Condition [C]


Evaluation [E]

Value [F]


selected option of

-Droplist

-equals

-Listbox

-does not equal

If you select equals through does not contain:

If you select value through selected option of:

-is less than

-value

-is greater than

-value of variable

-is less orequal

Choose from a list of variables or widgets

-length of variable value

-is greater of equals -contains

-text on widget

-does not contain

-length of widget value

-is

-selected option of

-is not

-text on focused widget If you select is or is not:

If you select text on focused widget,numeric, alpha or alphanumeric: N/A If you selectone of: Enter Options…

-one of

Clicking this options opens a small window into which you can type multiple values, each on a separate line. This enables you to qualify a condition as true or false if any one of several possibilities match.

-numeric -alpha -alpha-numeric

3

value of variable

Select from a list of variables or create a new one.

Same as 2

Same as 2

Same as 2

4

length of variable value

Select from a list of variables or create a new one.

Same as 2

Same as 2

Same as 2

5

text on widget

-Text Field

Same as 2

Same as 2

Same as 2

6

length of widget value

Same as 2

Same as 2

Same as 2

-Text Area -Text Field -Text Area -Droplist -Listbox

[ 146 ]

Chapter 5 Condition [C]


Evaluation [E]

Value [F]


7

state of panel

Dynamic Panel

-equals

value

Select one of the widget’s states

8

visibility of panel

Dynamic Panel

value

-true

9

text on focused widget

N/A

Same as 2

Same as 2

Same as 2

10

drag cursor

N/A

-enters

area of widget

-leaves

Select from a list of applicable widgets:

-is over

-Image

-is not over

-Rectangle

-does not equal -equals -does not equal

-false

-Placeholder -Button Shape -Image Map Region -Dynamic Panel 11

area of widget

-Image

-is over

-Rectangle

-is not over

Same as 10

Same as 10

-Placeholder -Button Shape -Image Map Region -Dynamic Panel

Adding and Removing Conditions You can easily add and remove conditions using the Add and Remove Conditions icons (H). Obviously, with two or more conditions, the choice you make in the Satisfy section determines the outcome of the interaction.

The Description The description area (I) provides a natural language reiteration of each of the conditional rows. It is a little easier and faster to read, especially when you have several conditions.

[ 147 ]


Troubleshooting Conditions • Check the Satisfy droplist if you have multiple conditions. Depending on how you want the logic to work, the setting may be wrong. • Have you selected the correct Widget? Axure presents all the widgets that are placed on the page (or master). The list can be long; picking the wrong widget is understandable. • A simple copy and paste issue might explain inexplicable behavior of a widget – the problematic widget may have inherited the interactions and conditions of the original widget. Clean up when needed.

[ 148 ]

Chapter 5

Raised Events Can a tiger change its stripes? Can an Axure master change its size or shape from one page to another? The answer to both is no. But, you can control the behavior of a master, so that each of its instances, across multiple pages, would have a different behavior for the same event. Raised events greatly extend the usefulness of masters and once you learn this feature (easy, I promise), you will find yourself using it often.

Raised EventsDeep Dive There are only two things you need to remember about raised events. First, that you can create raised eventsonly on masters. As you know by now, regardless of which page a master instance is placed on, you must open the master for editing, in order to make any changes to it. The changes you make automatically cascade to all of the instances of that master. So when you create the raised event in a master, this event will be available on all the pages that an instance of this master is placed on. The second thing to remember is that creating a raised event is a two step process: Create the raised event on the master. Create the interaction for the raised event on the page where an instance of the master is placed. Why do we need raised events? Masters are autonomous. This means that when you edit the master, that master has no awareness of widgets that are placed on pages. As a result, you cannot create on the master an interaction that affects widgets that share a page with an instance of the master. Let’s walk through creating a raised event in a ‘sandbox’ file. It will be the fastest way to learn this great feature:

ExampleThe Objective Our goal is to use a button widget, constructed as a master, to control the state of a dynamic panel. This is a simplified example of a common construction method used, for example, for navigation widgets. • When the user clicks the button, and the dynamic panel is on state 1, switch to State 2. • When the user clicks the button, and the dynamic panel is on state 2, switch to State 1.

[ 149 ]


Preparation You can re-use the sandbox file that was created for the conditions example above, but I highly recommend that you create the file from scratch as an opportunity to reinforce your learning. If you reuse the file, skip to step 6 and delete irrelevant widgets and interactions as needed. 1. Create a blank directory on your desktop and label it ‘Axure Sandbox’. The reason to create an entire directory is that we need to have a container to hold all the files that Axure creates forthe HTML prototype. 2. Create the ‘sandbox’ Axure file: If you are using the Windows version and you have another project file open, Axure will prompt you to save it before launching the blank new file. If you want to keep your project file open while you work on the sandbox (or some other Axure file), launch a new instance of Axure. If you are using the Mac, Axure supports multiple files in a single instance. When you save the new file label it ‘Sandbox’. 3. In the Sitemap pane, delete Pages 1, 2 and 3 that Axure creates by default for every new file. You should have the Home page open for editing in the Wireframes pane. 4. Drag a Dynamic Panel widget over and open State 1 for editing. Drag over a Rectangle widget. Double-click the widget and type the letter A. Also, change its background color to Blue. 5. Add another state, open it for editing and drag over a Rectangle widget. Type the letter ‘B’ and change the background color of the widget to Red. 6. In the Masters pane create a new master and open it for editing. Drag over a Button widget and type the word ‘Switch’ to replace the default enter text… that is on the widget. 7. In the Home page, drag over the master button and place it below the dynamic panel.

[ 150 ]

Chapter 5

Let’s try without using a Raised Event: The interaction seems straight forward – If the dynamic panel is on state 1 (“A”), clicking the button will show state 2 (“B”), and clicking “B” switches the user back to “A”. So let’s try to apply this to the button on the page: 1. Click the master button widget (A) and look at the Interactions tab in the Widget Properties tab (B). There are no events there, no ‘hooks’ to hang the interaction on. There are no built-in events for master instances This makes sense because a master is constructed from one or many widgets and events are widget-contextual. From the perspective of the page an instance of a master on the page is like a black box. When you click to select the master on the page, Axure cannot tell which widget inside the master is selected. Axure has no context, and therefore it cannot show you a list of events in the Interactions tab.

[ 151 ]


2. Let’s look into the master itself. With ‘New Master 1’ open for editing (typically, there is no need to bother with naming pages and masters in a sandbox). Click the ‘Switch’ button and in the Widget Properties pane, select the Interactions tab and double-click the OnClick event (A). 3. Select the Set Panel State(s) to State(s) action (B). Alas, the column Step 4: Configure actions is empty (C). This is not an Axure bug. As noted above, when you edit a master, the master has no context of which widgets are associated with which page.

[ 152 ]

Chapter 5

Your only option is eliminate the master button, and instead, place a button widget on the page next to the dynamic panel. But remember—this is a simple example intended only to help illustrate raised event. Once you understand it, applying it in your own prototype should be a breeze.

Creating Raised Events, Part 1 – On the Master 1. Remember that setting a raised event is a two-step process. Step one happens on the master, and step two occurs on the instance on the master, on the page where the instance is placed. 2. Have the master tab open for editing in the Wireframes pane and click to select the button widget (A). The OnClick event is the only option available in the in Interactions tab of the Widget Properties pane. Double-click it to open the Case Editor dialog. [ 153 ]


3. From the actions list in the Step 2: Add Action column, scroll all the way down and select the Raise Event option (B). 4. The column Step 3: Organize actionnow shows Raise Event under Case 1(C). 5. The column Step 4: Configure actions includes a brief description of what raised events are (D). Since you are going to create the first check event for this master, the column is blank. Click the Add icon (E) and the first row will be added to the list, with the default label NewEvent1 (F). 6. Always label raised events!The name must be: Alphanumeric. No spaces between words. 7. In the sandbox file, labeling the raised event is not really important, but in your production file, and especially in shared projects, try to come up with a meaningful name that describes what the action does, for example “SwitchStatesFromAtoB” (G).Now comes the most important part: Make sure to check your new event. As soon as you check the box next to the event, Case 1 will change from a generic “Raise Event” to “Raise SwitchStatesFromAtoB” (H). 8. Click OK to dismiss the Case Editor. Now, when you click the Switch button widget (J), Case 1 in the Interaction tab should show “Raise SwitchStatesFromAtoB” (K). This is the confirmation you need that clicking the button in the HTML prototype will fire the event. Troubleshooting Raised Events After you generate the HTML prototype, test the raised event you created. Well, it does not work. The most common problem, and the easiest one to fix, occurs when you create a raised event but forget to select it.

[ 154 ]

Chapter 5

[ 155 ]


Finally, an alternate way to create raised events on the master, is by starting from the Wireframe menu (A) and selecting Manage Raised Events (Masters Only)… (B). This menu option is contextual, and you do not see it on the Wireframe menu when you work on pages or dynamic panel states (unless those are part of a master). The Manage Raised Events dialog (C) pops up and it is identical to the one that appears in the Case Editor.

Creating Raised Events, Part 2 – On the Page Switch over to the home page tab in the Wireframes pane and click the Switch master (A). The event, ‘SwitchStatesFromAtoB’, which you created in part 1, is now listed in the Interactions tab. You have the ‘hook’ to create a case and build the interaction you want.

[ 156 ]

Chapter 5

From this point, completing the interaction is straightforward; use condition to check the current state of the panel and switch to the alternate state.

Raised Events in Action Now that you have a firm grasp on raised events, it is time to apply your knowledge to our project. Home page will promote new titles Ability to filter by featured, popular, date Accordion All types of media Mouse over will provide information about the title with ability to Buy or View More information Click takes the user to the detail for extended info and purchasing rename pages and masters naming conventionHome – convert body to master (because it will be used on all instances of the home page Create accordion master which will be used for the 3 media – it will be placed 3 times on the body [ 157 ]


Master will have a dynamic panel with each state per mediaRaised events will make it possible to activate info panels, and linking actions

Variables and Functions Overview About two thousand years ago, the Greek philosopher Epictetus said that “The materials of action are variable, but the use we make of them should be constant”. The ancient Greeks loved deep concepts like atoms, so it is not surprising that they invented information architecture, and the notion of separating a reference to data from the actual data it contains. Wikipedia has a good definition for a variable. In the context of computer science, it is “A symbolic name given to some known or unknown quantity or information, for the purpose of allowing the name to be used independently of the information it represents.” We use variables all the time. For example, when we think (or perhaps prefer not think…) about our account balance, the term ‘account balance’ is a name for a variable. The actual dollar amount of the balance changes, but our way to reference it does not have to. As Epictetus said, the variable is constant, its value changes. In addition to storing data, variables are used to pass this data around, from one event that sets their value, to another event that consumes that value. As a result, variables are very useful when you have conditional logic, because it is possible to check the value of a variable in order to determine which path to take. We can also control the scope in which variables can be used: • Local variables are limited to a certain function in a certain area of the application, and are not available to other functions in other areas of the application. • Global variables, which are ‘visible’ or available to all functions across the entire application. A simplified analogy is human memory. We are equipped with a ‘working’ or ‘short term’ memory, a limited storage capacity that enables us to complete specific tasks. For example, it helps us remember that we put water to boil, or where we left out phone. There is no need to store this information after the activity ended and the information is replaced by new transient information. We also have longterm memory, which enables us to retrieve information on demand long after its acquisition. [ 158 ]

Chapter 5

Create and Manage Variables Manage Variables Dialog Axure makes it convenient to manage variables—create, delete and rename them. The first option is to create variables, while in the process of setting up your interaction. 1. From the Set Variable and Widget Values window (A), select the option value of variable from the first droplist. In the next column, select the option Add new…(B). 2. In the Manage Variables window (C) that appears, click the plus icon (E), and a new row will be added below your last variable in the list (F). If this is the first variable you create, it will appear under the built-in OnLoadVariable.(D) 3. Rename the new variable according to Axure guideline and click OK (G), to close the window. 4. Now, whenever you click the 2nd droplist in the Set Variable and Widget Values window, the variable will be listed there (H). The other option to access the Manage variables window, is to select the Manage Variables… option from Axure’s Wireframe menu (J).

[ 159 ]


[ 160 ]

Chapter 5

Set Variable and Widget Value Window Once you create your variable, setting its value is facilitated by the Set Variable and widget Values window.

Initializing, Passing and Resetting Variables The bad news about variables is the fact that you are responsible for ensuring that they function correctly. The good news are that there are basically only three steps to remember about proper handling of variables, and as long as you keep those in mind, troubleshooting should be easy, or unnecessary:Step 1: Setting and Initialization I realize that there are two items here where you probably expected just one, but rest assured, these are variations on the same principle:

[ 161 ]


Setting Variables Remember that when you create a variable, you are only creating an empty container, so it is important to ensure that some event, triggered by some widget or OnPageLoad, actually populates it with a value. This is the step of setting the variable. For example, suppose the following:AText Field widget called ‘User Name’ on page 1. 1. A variable called UserName.AText Panel widget on page 2. An OnPageLoad event sets the value of the text on this widget is ‘Welcome [[UserName]]!’ 2. A Button widget on page 2 with the action Open Link in Current Window associated with the OnClick event. 3. Immediately after the prototype is generated, only the word ‘Welcome’ is displayed on page 2. That’s because our variable,‘UserName’ has no value in it.You need to make sure that an event will populate UserName with data. In page 1, add an OnLostFocus event to the text field, with a condition that checksif the field is empty. If the field is not empty, the variable UserName will be equal to the field User Name. 4. When you click the button after typing a name into the ‘User Name’ text field on page 1, the text panel widget in page 2 will show “Welcome Alfred E Neuman”. If your variable based interaction is not working for some reason, one of the first places to check, is whether the variable was actually set.

Initializing Variables It is common to mistakenly think that some value, like zero, will be automatically placed in the variable by the software. The meaning of “no value” is ‘Null’, which is different from zero. Zero is an actual value. Null is not a value, it is just a empty. In the case of Axure, and empty variable is noted by two quote marks with no space between them: “”. There are circumstances where it is helpful to set the value of a variable immediately at the time of prototype generation. For example, when a variable can be assigned one of several values by widgets that are positioned on multiple pages. In such a case, if a widget that is supposed o use a variable is empty, it can be difficult to figure why exactly it is empty. It is easier to troubleshoot changes in variable value when you can track its value from the start. When you use this approach, you are initializing the variable. Remember that the value of the variable impacts the conditional logic that is evaluating which path to take based on that value, and it is easier to look for something than for nothing. [ 162 ]

Chapter 5

Think about your variables as a herd of sheep: You want to know their condition at all times. Maintain a running list of variables you use in the file, their possible values and the resulting path based on the value. One method is to keep such a list in Axure, as a dedicated page on the Sitemap pane. This is especially beneficial in shared project files because all team members can easily share and learn about the variables used in the file.

Step 2: Passing Variables The use of variables is often asynchronous. In other words, the value of a variable can be set by one event, and the variable can be consumed in another section of the prototype during some other event, not directly tied to the seeding event.Once you populated the variable with a value, you want to make sure that the event(s) that consume that value are properly set.

Step 3: Resetting Variable Value Finally, it is common to repeat interactions during the demonstration of the user experience. Consequently, in order for variable-dependent interactions to work properly, you may need to reset their value to its initial state. This can be done in several ways: • Refreshing the prototype in the browser will wipe out the values in all variables.If you want to avoid a refresh, create a hidden ‘reset’ button on the page that is dedicated to resetting the value of the variables that control the interaction you want to repeat.

Variable Types Axure supported variables in previous versions, but Axure 6 has some significant enhancements that improve the practical use of variables in your prototype, and open up new possibilities for creating high fidelity prototypes. Axure now offers three types of variables:

Global Variables As their name suggests, global variables, once set, are available to any page throughout the browser session. In other words, they will expire only when you close your browser tab or window.Built-In Variable

[ 163 ]


Axure comes with one built-in variable: the OnLoadVariable. It is a very useful container because each page in the prototype loads. Since page load is a guaranteed event, you can use this variable to initialize, set or reset the value of widgets and other variables. One think to keep in mind is that, just because the variable is called OnLoadVariable, it will work even if not used exclusively on a page load event. It will work anywhere. However, in keeping with the principal that variable names should be meaningful and relevant to the event that triggers them, it is not a recommended practice.

Your Variables Axure supports unlimited variables, but like everything good in life, there are some limits. First, if you are using Internet Explorer to test and socialize your prototype, you are up to what initially looks like an unpleasant limitation, as I.E can support up to 25 variables. But in practice, 25 variables can satisfy a great number of advance prototype files. If you use Firefox, Axure’s recommended browser for viewing HTML prototypes, sky is the limit if you want to use variables to the max. Variables are passed via URL, and the limit of Firefox URL is 64,000 characters. In other words, when you add up the characters that make up the names of your variables, and their values, the sum total should be 64K or lower.Special Variables Displaying the current day, date or page name in the prototype is a valuable capability and another welcome enhancement to Axure 6. Like other topics discussed in this chapter, don’t let the terminology hold you from using this function. Think about special variables as the ‘Insert’ feature in Microsoft Word. You can insert today’s date into a document or display the page number in the footer. Similarly, Axure provides a form of built-in access to useful parameters you can incorporate into the prototype when relevant.Currently these built-in variables include attributes of the current day, or the name of the current page. Most likely, items such as current time and others attributes will be added to Axure in the future. Below is a list of the special variables offered in Axure 6: Variable Name

Description

Example in Editor

Result in Prototype

PageName

Name of the current page as it appears in the Sitemap pane.

This is the [[PageName]] page.

This is the Home page.

Day

The numeric value of the current day. A range of 1 to 7.

Today is day [[Day]] of the week.

Today is day5 of the week.

[ 164 ]

Chapter 5

Variable Name

Description

Example in Editor

Result in Prototype

Month

The numeric value of the current month. A range of 1 to 12.

This is month [[Month]] of the year.

This is month 5 of the year.

MonthName

The name value of the current month.

This month is [[MonthName]].

This month is May.

DayOfWeek

The name value of the current day.

Today is [[DayOfWeek]].

Today is Friday.

Year

The current year. 4 digits.

The year is [[Year]]

The year is 2011

GenDay

The numeric value of the day in which the prototype was generated. A range of 1 to 7.

Generated on day [[GenDay]].

Generated on day 15.

GenMonth

The numeric value of the month in which the prototype was generated. A range of 1 to 12.

Generated on month [[GenMonth]].

Generated on month 8.

GenMonthName

The name value of the month in which the prototype was generated.

Generated in [[GenMonthName]].

Generated in January

GenDayOfWeek

The name value of the week in which the prototype was generated.

Generated on [[GenDayOfWeek]].

Generated on Tuesday.

GenYear

The year in which the prototype was generated

Generated in [[GenYear]].

Generated in 2011

Quick Usage Examples Here are some examples of combinations you can make: In the Editor

Result in Prototype

Today is [[DayOfWeek]], [[MonthOfYear]] [[Day]] [[Year]]

Today is Thursday, August 24 2011

Prototype generated on [[GenMonth]]/ [[GenDay]]/[[GenYear]]

Prototype generated on 12/28/2011

[ 165 ]


Local Variables As their name suggests, local variables have a limited scope and lifespan. You can use Axure’s local variables to store the value of widget or other variable on a particular page. The value on those variables will not be passed on to other pages.

Naming Variables Axure Rules Axure variables have basic naming rules. A variable name must be: • Alphanumeric. • Less than 25 characters long • Contain no spaces

[ 166 ]

Chapter 5

Variables Naming—Best Practice • Because you cannot use spaces, and are limited to alphanumeric characters, use the ‘CamelCase’ convention, which makes is easy to parse words within the variable string. Basically, you need to capitalize the first character in each word. For example, use ‘WishListCount’ instead of ‘wishlistcount’.Use descriptive names so that you or others who work on the file will understand what the variable stands for. Avoid names such as Var1, Var2 and so on, because I can guarantee that within days or weeks you yourself will not remember what these names stand for. • If you are working on a shared project file, each team member should add their initials at the end of the variable name, in all caps. For example, ‘WishListCountES’.

Functions Functions are a very welcomed enhancement to Axure 6. Again, don’t let the scent of Math scare you off because the ability to perform simple arithmetic operations, or manipulate text strings is very handy for prototyping. Function Type

Description

Example in Editor

Result in Prototype

Arithmetic operations

The four basic operation you can apply to numbers.

[[5+5]] ,

10

[[VAR1*VAR2]]

25

Add (+)

(where VAR1 =5 and VAR22 = 5

Subtract (-) Multiply (*) Divide (/) Text (String) operation

LVAR.substring(from,to)

Text (String) operation

LVAR.length

Text (String) operation

LVAR.toFixed(decimalPoints)

If you wonder why you should bother with variables in your Axure prototypes, I you are concerned about increasing complexity, or the learning curve involved in figuring out how to implement variables, here are a few aspects to consider:

[ 167 ]


Variables and Usability Testing One of the key attributes of any high-fidelity prototype, is the degree by which its look and feel mimics the ‘real’ thing. In UX prototyping, in addition to the visual treatment, it is the responsiveness to user input that makes a big difference in reducing the gap between the mockup and the actual software.The higher the fidelity of your prototype, the higher the quality of feedback you get participants in usability studies. Historically, however, prototyping has been limited to hard-coding data to the wireframes, thus inherently reducing the responsiveness and dynamic qualities of the simulation. Short of hiring a programmer to code a prototype, and effort that introduces its own massive problems, there was no practical way to easily demonstrate true dynamic responsiveness and how data changes from one screen to another in response to user input, under varying conditions.As a result, usability tests are often rigid, and require a great deal of scripting, without the benefits of true experimental variety. For example, if the user needs to select several items from a list of products and add them to a shopping cart, we have to guide the participant to select the products we wire framed the script for. Since the shopping cart wireframe is dependent on the user’s selection, it is not practical to have wireframes of the cart that depict several possible permutations. Additionally, rapid, iterative design process often leads to an opposite problem of inconsistencies across wireframes. In the movie industry this problem is called ‘continuity’. A lot of effort is taken to maintain the illusion of the movie, and avoid a blatant disruption in the believability of the film. For example, moviemakers go to a great length to ensure that in a shot (our wireframe) taken on location, the actor getting into a taxi at the airport, would have the same appearance he had in a shot taken days or weeks earlier (another wireframe) , in the sound stage, showing the actor at the lost and found counter. In a prototype, however, it is not uncommon to have a bit of information, which is supposed to stay consistent, change from one wireframe to another, and break the continuity. This is a construction issue, typically due to the fact that it is really hard to keep tack of changes and iteration in the data across all the wireframes that show that data. As a result, usability studies were, and still are often hindered by the fact that we need to ask the participant to ignore hard coded information or continuity issues. In other words, we ask user to ignore the ‘brains’ part of the user experience: The data and context associated with task flows. At least in my experience, I find that most participants get the fact that they are looking at a mockup, and understand why the data does not really reflect the flow they were supposed to follow, or why they are restricted to a script.

[ 168 ]

Chapter 5

But it can be difficult to distinguish between valid usability issue in the design, and ‘noise’ that is a result of the participant getting confused by mechanics and data presentation limitations of the prototype itself. This is a serious concern which can place you in a bind.

Example: Closing the Identity Gap Most applications require users to sign in to a system in order to render the appropriate functionality for the user. In our demonstration project, for example, users sign in as basic or premium subscribers. In usability studies we often resort to asking participants to assume a fictional identity. One of the steps in a typical script would require the participant to enter a username and password of some fictional character that is hard coded into the prototype. We can personalize the experience for the participant and by doing so, reduce a possible sense of awkwardness and believability gap. Variables allow us to capture the participant’s name and use it throughout the application.

The Objective Personalize a usability test session for the participant, by using variables.Create a special page for entering participants’ information • Store the information in variablesUse the variables throughout the session, where ever a user name is used (prompts, confirmations and so on)

Preparation & Interaction 1. Create a new page and label it ‘Usability Preferences’. 2. Place three text field widgets to capture the participants’ First, Middle, and Last name. Make sure to label the widgets. For example ‘Name F [UT], where the UT suffix identifies the field as associated with the usability study, not the actual prototype. 3. Add a button widget and label it ‘Initialize Participant Variables’ [A].Assign the button an onClick event, and in the Case Editor (B), select the Set Variable/Widget value(s) action. 4. From the column Step 4: Configure actions, open theSet Variable and Widget Values windowand from the first column select value of variable (C). 5. From the second column (D), select the variable you created for storing the participant’s first name. [ 169 ]


6. To determine what the value of this variable should equal to, select text on widget from the third column (E). 7. Finally, from the fourth column (F), select the matching field, in this case, the first name field. 8. Click the Plus icon (G) to add a new variable value equation row, and repeat steps 4 to 7 for the other fields you want to capture (you are not limited to the name information of course.). 9. The Description area (H) provides a natural language recap of the variables that will be set, and their value, which helps you confirm you got everything right.

10. The next step is to use the variables in the prototype. For this example, we will add the participant’s first name in the Top Header Bar Master. 11. Widen the dynamic panel (A) so that it can accommodate the new widget. 12. Open the second state‘‘After Sign I’’ (B) for editing. Make the necessary modification to add the Text Panel widget‘‘Welcome Fiel’’ (C) to the left of the existing bar

[ 170 ]

Chapter 5

13. Back on the master tab, we want to add an OnPageLoad event that will set the value of the text panel‘‘Welcome Fiel’’. We will use the action Set Variable and Widget value for that. 14. Click the button Open Set Value Editor (E) in the column Step 4: Configure actions.

15. In the Set Variable and Widget Values window (A), we want to pass the use’’s first name to the‘‘Welcom’’ text panel on the Top Header Bar. From the first column, select text on widget. Identify the Welcome Field in the 2nd column (C). 16. Now we set the value (D) of the field, when you click the Edit Text button in 4th column (E), Axure presents the Enter Text dialog (F). [ 171 ]


17. The text string““Welcome”” (G) appears in the text area. This is the text that on the‘‘Welcom’’ text panel widget. From the Insert Variable or Function droplist (H), select the variable that stores the use’’s first name, UtNameF. 18. If your design may call for highlighting the user’’ name in the text string, you can change the text color and style. 19. The new value of the‘‘Welcom’’ text panel on the master now includes the variable: Welcome [[UtNameF]].

Testing & Tweaking When you generate the HTML prototype, a couple of issues come up: • When you enter the participant information in the Usability Preference page (A) and press the‘‘Initialize Participant Variable’’ button, it will be nice to get a visual confirmation that indeed the variables were set

[ 172 ]

Chapter 5

• When you switch to any of the pages that use the Header Top Bar, such as Home [No Ads] (B), you notice that the master has shifted to the right (C), and is way off the intended right margin of the page. Tha’’s because it is now wider. To fix, we just need to adjust the maste’’s position on all those pages. This example underscores a common situation, where a relatively minor change to the layout of a master, requires updates to many wireframes. While in this case, the actual repair takes a couple of minutes to complete, make sure to consider the impact of master change on your wireframes, and make sure to go over all pages that use the master, to check their layout.

After adjusting the layouts, we move to add validation, that the variables with the participan’’s name are indeed populated. 1. Open the Usability Preferences page (A) for editing. In the current setup, values of the name fields (B) is passed to the variables upon clicking the button‘‘Initialize Participant Variable’’ (C). You can validate this in the Set Variable and Widget Values (D) and (E). 2. Add three Text Panel widgets (F) next to the text fields. These widgets will serve for confirmation, so label them accordingly, for example,““Confirm VAR (UT Participant L””. Also, change the default text on the widget ““enter text”””) so it is not identical to the default text in the text fields to the left. 3. In addition to setting the variables, clicking the button will now also set the text panel values to the value of the variables. Add relevant three rows (H) in the Set Variable and Widget Values window. 4. Finally, you may add some layout cosmetics to the page, such as a frame and page title. Although it is a section of the prototype that only you will see, splurge a minute or two to make it look good. [ 173 ]


Generate the prototype and switch to the Usability Preferences page. • On screen entry (A), the confirmation widgets show the hard-coded text““confir””. • Enter a name into the field and lick the Initialize button. These values should appear in the confirmation widgets (B). Now you know that the variables are set correctly, and an additional bonus is that you get another opportunity to spell the participan’’s name. • Finally, switch to any page that is using that first name variable, to ensure that the‘‘Welcom’’ string on the Top Header Bar includes the name.

[ 174 ]

Chapter 5

Variables and Prototype Construction Variables facilitate the ability to reuse the same pages in different scenarios, instead of duplicating instances of those pages. Consequently, it is possible to gain substantial construction efficiencies which translate to fewer wireframes to update as you iterate through design changes. As an example,slet’s look at the approach we took in chapter 4 for handling the various instances of the Home page of our demonstration project. We ended up with three versions of this page: An initial stat A version with advertising A version with no advertising There are good reasons for taking this approach: • You are early into the design phase of the application, and the entire approach is fluid and changing rapidly. Duplicating and tweaking existing pages is simple and fast, and you can iterate at high velocity • You need to quickly compare versions of the page during stakeholder meetings, and it is easier if each permutation is accessible on the sitemap pane of the browser. • You need to generate a UI specifications document for the development team, and discrete pages provide a clearer documentation.

[ 175 ]


But you can also take a different approach, and build just a single instance of the Home page, and let variables and interactions handle the transformation of the page to its various permutations. This approach works well when you are ready for usability testing. At this point, it is most likely that the proposed user experience has been approved by stakeholders, and now it is time for extensive validation

Variables and Localization There are many circumstances for which a multi-lingual prototype needs to be developed. Multi-lingual countries need to develop and test instances in each of the official languages. In Canada for example, both French and English versions need to be tested. Corporations deploy multi-lingual sales, support and other mission critical applications for their subsidiaries world-wide, and finally, e-commerce, social media and other sites that aspire to capture a larger share of the global market When you work on an application that will be localized, you take into consideration the fact that the words in some languages are longer, sometimes up to 40%. We want avoid degradation of the layout, when the application is viewed in another language. Text wrapping is a common issue when the width of fields, set to fit the English version, is too narrow to accommodate the equivalent translated value. These practices are common and are applicable to any wire framing tool you use. The question is, which strategy to take when it comes to your Axure prototype? Should there be a separate RP or RPPRJ file for each language? Should the pages in all languages be in the same file? It gets complicated the larger and more complex the application, and the prototype are. An approach to consider is to use variables to support localization. The benefits of this this method are: • Use a single Axure file for all languages. • Use a single instance of pages for all languages. The prerequisites are: • You must use Firefox to view the prototype • Keep the names of the variables and their values short enough – below 64,000 characters combined.

Example Due to space limitations, I will use as an example a localization of the global navigation bar we use in our demonstration prototype. [ 176 ]

Chapter 5

The Objective Create variable-based widgets that support localization in French and German, in addition to English.

Step 1: Preparation – Translation Table 1. Create a new folder in the Masters pane and label it““Translatio””. 2. The first widgets we want to localize is the‘‘Global Na’’, so create a new master in the Translations folder, and label it““Trans Table [Global Nav] and open it for editing. There is going to be a translation table master for each widget that we want to translate. 3. The Global Navhas 4 tabs, or, 4 items that need translation. Drag over a Table widget and set it for 4 columns and 5 rows. 4. The first column will identify the widget where the word is used. Each of the following columns will support a language, starting with the default language. In our example, English. List the other languages in the other column headers, the order is not important. Adding languages later is easy – just add a column. 5. Populate the table. Initially use an online translation service such as Google Docs. The actual translation will be provided later in the project. At this point the goal is to demonstrate multi-lingual support. 6. Next, we want to label each of the cells in the languages columns. The convention is simple. For example, the label containing the word‘‘Hom’’ in English will be““T1-C2-R””, where““T”” references the first translation table, C2 is the 2nd column in the table, and R2 is the 2nd row in the table. This simple coordinate reference provide pinpointed referencing on a work level. Make sure that in all tables, the sequence of languages is consistent.

[ 177 ]


Step 2: Preparation – A Language Switcher We want to add a widget that will facilitate the switch from one language to another

Pros and Cons of Using Variables Be strategic! Always keep in mind the phrase““Just because I can, does not mean I should”” In previous sections of this topic we discussed many of the pros for using variables, and the value of integrating them into the prototype. But if you plan to use variables extensively, it is important to understand how the use of variables willtaffect your work, and in a case of a team, everyone who is using the file.

What Was I thinking? Axure makes it fairly easy to figure out the construction of a prototype and the interactions involved. Events, cases and conditions are presented in a natural language that shields you from the obscurities of programming language code. As long as you label your widgets in a meaningful way, any Axure user should be able to open up your file and understand how you wired it. In fact, of you open a file after several weeks or months, you might need a few minutes to remind yourself what it was about.iIt is not uncommon to forget which variable value meant to trigger which path. Thus my advice is to document how you use the variables.

Specifications

The use of variables enables you to gain considerable construction efficiencies. Instead of redundant instances that show variations of a page, you may use just one page and manipulate its layout with variables. For someone who looks at the HTML version of the file, how you constructed the file may not make a difference. But when you generate the word specifications, the issue you will face is how to document and accompany with screen captures, the various instances of that single page? Also, you can create very sophisticated interactions, you end up using variables and events extensively. One of the options of the Word specifications generator, is to include the interactions information. The question is: Is there real value in this information, or will it add bulk to the documentation but confuse the developers.

[ 178 ]

Chapter 5

There is a difference between the way we construct a simulation, and the way it is actually coded. Some of the interactions we create in Axure, serves only to make the prototype work. For example, a‘‘raise even’’ will be completely foreign to a developer. Some variables we may use will also makes sense to us, from an Axure perspective, but will not be used by developers. Some basic interactions appear to be valuable, typically, the navigation related actions, such as open link. If you are expected to deliver a development grade specifications, as well as a highly interactive prototype, you may need to consider having two files, one for each target delivery. Obviously, there is overhead in this approach, but it gets you the best deliverable for each medium. It is possible to find a middle ground, where the interactions are constructed such that the Word specifications still provide a meaningful output, but you will have to experiment with the output often until you and the teams who consume the specifications are comfortable with the result.

Summary In chapter we covered a set of Axure functionality that is responsible for creating truly interactive prototypes. Conditions, raised events and variables extend our ability to move beyond the basics of navigating from one wireframe to another. We can also create relevant context in response to inputs. The use of these capabilities, while not too complicated, does require a higher level of discipline and focus. We are not engaged in coding, by far. But, conditional logic and variables involve formal evaluation of possibilities. As long as you document the values of variables, and the possible actions that should take place given each one, you should be able to reduce interactions that do’’t work, and save time on debugging. Finally, do’’t hesitate to experiment, to try interactions that may help you communicate to stakeholder and users, your vision for the user experience you plan for the application. In the next chapter we are going to cover change management. As the prototype stabilizes and the schedule tightens, there are often many dramatic modifications, requirement changes and other situations that require changes to the prototype. We will look at Axure functionality and best practice, that help apply changes quickly, and efficiently.

[ 179 ]

Managing Patterns with Widget Libraries After the user interface framework, navigation systems and general layouts are socialized with and accepted by the project owners, the next phase is to define how the design will addresses business requirements and technical constraints. With the progression of the design from quick initial sketches to more concrete wireframes, design patterns move to the forefront of the prototyping process. The concept of design patterns is a deeply grounded principle that is fundamental across disciplines, from arts to computer science. The use of patterns in user interaction design is commonplace and complements the paradigm of object oriented programming and application development Within the user experience context, a pattern is a template for an application-agnostic group of widgets, which solves a specific interaction requirement in a generalized way. Patterns are considered to be a good thing: The adoption of a pattern within and application and across applications improves skill transference and reduces the learning curve for the user Some UI patterns are as old as the Graphic User Interface (GUI. Remember this term? Sounds so 9''s…) and have been usually dictated by the operating system. Take for example the ubiquitous Menu Bar. It appears only once in an application, but the overwhelming majority of applications running on all modern operating systems have one. The majority of computer users are therefore very familiar with and accustomed to having the topmost horizontal bar in every application provide access to generic functionality (File, Edit, View, etc.) as well as application-specific functionality (Wireframe, Object and Generate, etc.).

Managing Patterns with Widget Libraries

However, the Windows and Mac menu bars are slightly different, and the differences in terminology used for some menu items (Preferences on the Mac, Settings on the PC) are sufficient to disorient a user accustomed to only one of the two platforms. This and similar examples underscore the power of patterns. Inconsistencies in a pattern can cause real and long lasting confusion for the user

There is not much we can do about cross-platform consistency; but the fundamental principles regarding use of patterns are: •

There should be a single pattern for an interactio

•

When a pattern has been established for an interaction use, it should be used consistently throughout the application

So, patterns work only when they are consistently enforced and used. Some examples of interaction categories where patterns play an important role include: •

Navigation

•

Data Entry

•

Grids and Lists

•

Search

•

Message and Error handling

•

Shopping

•

Sign-In/Out and Authentication

[ 182 ]

Chapter 6

Do''t enforce or lock into a pattern library too early in the design process. Remember that your ultimate goal is to design an application, not a pattern library. In other words, do''t try to force an interaction flow into a pattern you already have if this compromises the interaction.

With Axure you can approach the creation and management of patterns using the masters and/or widget library features.

Masters and Widget Libraries There are two important differences between widget libraries and masters. Depending on the circumstances, you will determine which type of widget collection is appropriate for your particular design environment. The first difference is in usage. Think of masters as identical clones. An instance of a master can not be customized or tweaked in the context of the page in which it is placed (the only exception to this is page specific master interactions). The visual appearance of all instances is identical to their source. This means that edits to the mater will immediately apply the changes to all instances of the master, wherever they are used throughout the entire file. Frequently this is exactly what you need in order to save time and complexity in a rapidly evolving prototype. Remember that masters should be created when you intend for the same interface pattern to be used on multiple pages. The Global Navigation bar, which you created in the previous chapter, is a good example: You generally want all navigation elements to remain consistent across all instances. A master that is only used on a single page or on no pages at all, probably should not be a master, unless you plan to use it in the future. What if you want to change only a certain aspect of the master, such as its width or height? This ca''t be done without breaking the connection between the master and the instance. As I said before, a pattern is a generalized template. The term""generalize"" conveys the idea that modifications to the pattern are sometimes required in response to the specific context of usage. This is where custom widgets become relevant The persistent linkage between the master and its instance does not exist in widgets. Once an instance of a widget is placed on a page, it is no longer connected to its source. Changes made to a widget in the library do not apply to its instances. The downside of this is that the responsibility for ensuring that an instance of a widget is consistent with its parent falls on you, the designer. [ 183 ]


The second difference between widget libraries and masters has to do with distribution. Masters are local to the specific file on which you are working. To use a master that was created in an Axure stand-alone file (.RP) you have to use the Import function. If you want to use a master that was created in a shared project file (RPPRJ), you need first to export the shared project to an RP file, and then import the master from there. For most of us, the thought of dealing with imports and exports does not sound very appealing, especially when we are pressed in time. Although Axure provides an easy and simple method to import pages and masters, I have found, in my discussions on this topic with other practitioners, hesitation and reluctance to use the import/export features, especially when the prototype file includes many masters After an update of a master that had been earlier distributed to a team, the import process needs to be repeated. Moreover, if the update involves modification to the size of the master, the updated master can actually''brea'' some wireframe,. When you work on your own, you can assess the impact of the change in the master by looking at all the wireframes where the master is used. When you are using a master that has been distributed, it is not possible to verify that the revised master is not breaking the pages where it is placed. In contrast, import is not required in order to add a widget library to an Axure file. Each widget library is stored in its own file, and it can be loaded and unloaded with ease from the prototype file at any time. When an update to a library becomes available, Axure provides a method to refresh it within the prototype file Master of Masters For prototype projects that relay heavily on masters, a good strategy is to create a''Master of Master''. This is an Axure file that contains only masters. If you are part of a team, you can create a masters file as a shared project file in order to facilitate access, collaboration, and distribution. However, updates to masters should be considered carefully

Built-In Libraries Out of the box Axure includes the Wireframe (A) and Flow (B) widget collections. Together, these collections provide the basic building blocks for developing an extended user experience vocabulary. The built-in libraries cannot be altered it is not possible to add or remove widgets from these collections. It is quite possible to prototype an entire application, even a complex one utilizing only a portion of these built-in widgets.

[ 184 ]

Chapter 6

Community Libraries The Axure website provides links to a growing number of widget libraries that have been created by UX practitioners for fellow UX practitioners. (See community libraries, http://www.axure.com/communityLibraries.aspx) The generosity of people within the UX profession goes back to the days when Nick Finck, Henrik Olsen, Peter Van Dijck, and others offered free Visio stencils and Omnigraffle palettes. This culture of generosity also flourishes in Axur''s active user community in the form of freely shared tips, techniques, and custom widget libraries. The types of widgets you can find in the community libraries include iPhone, iPad and OS-X user interface components, various icons and social media elements and much more Most of these community libraries are free of charge despite the substantial amount of thought and labor that was invested in creating them. One such example is the work by Loren Baxter, an accomplished user experience designer and Axure expert. Loren authored the''Better Defaults Widget Librar'' (A), which has added thirtyfour widgets to Axur''s twenty two. His library includes elements such as an error popout, stylized popouts, date picker, and many other very useful items His other creation is the''Social Widget'' collection (B), which includes widgets such as a complete''Leave a commen'' form,''Share Thi'' popup, and animations for when you need to visualize a''Loading Thi'' feedback.

[ 185 ]


You can either use these libraries as provided, or tweak the widgets you want to make them fit your particular need. Either way, you can save a lot of time by not having to make some of these widgets yourself.

Of course, when you develop your own cool widget library, make sure that it is listed on the Axure site!

Your Own Widget Libraries Axure makes it very easy to create, manage, and distribute your own widget libraries. This is great news because there are several circumstances when you may find that you have to create your own widget library. 1. In the life of every project, there comes a time when you realize that the effort involved in creating your own widget library is well worth the time investment. This happens when you find yourself spending a lot of time frantically opening wireframes that you created some time ago, looking to copy from some pattern you now want to repurpose. 2. You design user interfaces for applications that use a specific UI widget library, which is based on a framework used by development teams such as Googl''s GWT, the Dojo toolkit, Oracl''s ADF, and so on. 3. You want to share with the world a set of widgets, which, you think would benefit others in their prototyping projects

[ 186 ]

Chapter 6

Create a New Widget Library The first thing to note is that a widget library has its own Axure file and file format. You initiate the creation of a new library from an existing RP or RPPRJ file, which is usually the prototype file on which you are working. The new library opens in a new specialized instance of Axure, and it is saved with the RPLIB suffix. In Axure 6 you can share widget libraries in the same manner as you would all Shared Project files. This makes team collaboration and usage of a library very convenient 1. In the Widgets pane, select Create library from the droplist. 2. The Save Axure RP Library window will open. 3. Name the new library and indicate where you want it to be saved. Axure offers to save it in a default location within the Axure directory labeled Libraries.

4. The library opens for editing in an entire new instance of Axure. A careful examination of the user interface reveals that this is not the standard Axure inference: °°

Note the icon next to the file name (A) – You will see this icon used to indicate Axure Widget library files.

°°

The Widget Library pane (B) – This pane is also unique to Widget Library files and it replaces the Sitemap pane of a regular Axure file.

[ 187 ]


°°

On the Widget Library pane you will see a new icon that launches the Widget Properties popup (C). The purpose of this popup is different from the Widget Properties pane. It allows you to define an icon and a tooltip for the widget. The icon is rendered in the Widgets pane when you load the library in an Axure file, and it helps the user understand the purpose of the widget

°°

You open the widget for editing in the Wireframes pane (D) just as you would when you work on pages and masters in a regular file.

°°

When the Page Properties pane is in a regular Axure file, the widget library has a Widget Note pane (E), which allows you to describe the entire widget. As you see, this pane does not have interactions or formatting capabilities. Consequently, you cannot create a custom widget that responds to OnPageLoad events

Example 1: A Lorem Ipsum Widget Le''s begin with the lowly text placeholder. Lorem ipsum, the reliable pseudo Latin text filler has been used, according to some accounts, since the sixteenth century in publishing and it is still going strong today.

[ 188 ]

Chapter 6

The use of text placeholders in wireframes is common because often we do not have the actual text that should accompany the page. Some argue that the use of lorem ipsum in hyper-realistic prototypes is problematic because it confuses participants in usability tests. The critics may have a point. On the other hand, using inaccurate text can also lead to misunderstandings. Use this element with caution—make sure that the placeholder makes sense 1. Drag over a Text Panel widget and paste the lorem ipsum text, which you can find in Wikipedia or on one of the 28,300,000 web pages Google identifies when you search the term. 2. Adjust the width and length of the text block as you see fit. There is no need to make specific definitions here. 3. In the Widget Library pane (A) rename the widget from New Widget 1 to Lorem ipsum. 4. With the widget selected in the Widget Library pane, click the Widget Properties icon (B). In the Widget Properties popup define the icon and tooltip. For the widget icon, which is displayed when the library is loaded in the Widgets pane, the default Use Preview should work fine. For the Tooltip, add a brief description and click OK to close the popup.

Congratulations! You have just created your very first custom widget! [ 189 ]


Example 2: A Vertical Scroll Bar Widget Another often-used widget is the vertical scrollbar. Here ''m referring specifically to a case where you want to visualize the fact that a section of the page is scrollable, but you do not want to simulate the actual scrolling. Even tough there is no real interaction, the visualization is valuable for stakeholders and especially for the development team, whose work requires the use of this widget. Another reason to include a vertical scrollbar widget is to simulate an OS specific screen. The scrollbar is a member of an exclusive club of user interface widgets that form the fundamental building blocks of a universal user experience vocabulary. Other examples are the checkbox or the radio button. However, the implementation of the scrollbar in various operating systems and development tools, such as Adobe Flash, can lead to variation in the pattern. The differences may appear to be minor, but they are significant for your prototype As the old saying goes:''God is in the detail''. For example, suppose you prototype an internal application that for various reasons is only supported on Microsoft Internet Explorer. If you create the prototype on a Mac and later use the prototype in a usability study with PC users, they may be confused by the unusual scrollbar. From their perspective, a basic element looks different from what they are used to see. As a result, you may find out that, instead of discussing possible improvements to the existing application, you need to spend valuable time explaining that the prototype was created on a Mac to clarify the scrollbar issue. Since Axure does not provide scrollbar widgets for the Mac or the PC, here is an opportunity to do it on your own: 1. Begin by taking a screen capture of a vertical scroll bar, or Goggling the term and picking a picture of one from some site. In this example, I am using a capture of a PC scrollbar I took myself and saved as a PNG file 2. Back in Axure, add a new widget to the widget library file in the Widget Library pane and label it Vertical Scrollbar. 3. Open the new widget for editing in the Wireframes pane and drag over an Image widget (A) from the Widget pane.

[ 190 ]

Chapter 6

4. Double-click the image widget, and in the Open File dialog (B) navigate to and select the scrollbar file. Click Yes when Axure prompts you to Autosize the image (C)

The vertical scrollbar will appear in the Wireframe pane ready for some additional edits. As it is now, there are some limitations to this widget, most notably its fixed height, which is derived from the size of the screen capture. The probability that this height will in fact be useful in your project is very low, but no worried! A simple tweak will make this widget work in most cases: 1. Right-click the vertical scrollbar and in the contextual menu select the Slice Image option (A) from the Edit Image menu. 2. Axur''s image slicing tool (B) is an easy to use mechanism in the form of a small panel that allows you to set the slicing option to vertical, horizontal, or quartering. In our case, use the horizontal slicing option. Notice that the curso''s appearance changes to a knife (C). Click it just below the scrollbar slider and now you have two images.

[ 191 ]


3. Click the lower image and slice it just above the lower scrollbar arrow to end up with three separate images. Now you can create taller or shorter scrollbars as required in the wireframe. By resizing the middle section of the bar (D), you maintain the scrollba''s visual fidelity. We will return to this a bit later in the section that deals with loading a library to your prototype file.

Our next example demonstrates the effectiveness of using a widget library to help enforce consistency throughout the prototype. The issue is especially important for UX teams collaborating on large projects.

[ 192 ]

Chapter 6

The image above provides a great illustration of a real issue with pattern consistency. When you close a document in a PC based application (A) and you have not save the document immediately before closing it, your options from left to right are: •

Yes (Default)

•

No

•

Cancel

Additionally, following the Windows pattern there is a""Clos'' icon on the upper right corner of the dialog box. Attempt saving a document in a Mac application (B) and the options, from left to right are: •

Do''t Save

•

Cancel

•

Save (Default)

Both dialogs facilitate the same three options but the order of the buttons and their wording is different. We have discussed before the significance of pattern consistency across computing platforms. In this example, the impact of pattern inconsistency is perhaps less dramatic because fewer users use both PC and Mac and would be affected by the variance. In the context of your own project, however, you want to make absolutely sure that consistency is maintained throughout and across platforms. In a project that involves collaboration between two or more UX designers on the same project file, each may develop a slightly different flavor within a pattern (for example, of a Save dialogue). A custom widget can prevent this danger from materializing.

Example 3: A Dialog Box Widget This example will demonstrate a simple yet important aspect of widget libraries: A method of facilitating consistency of widget and interaction patterns during the construction of the prototype. The method is especially beneficial for a team of UX designers who collaborate on a project, but it can certainly benefit you as a single practitioner as well.

[ 193 ]


Define the pattern

You want to create a dialog box similar to the one in the illustration abov), which will be used to prompt the users during various interactions. You settled on a pattern that has the following attributes: •

The Save button should be on the Righ

•

The Save should by the default butto

•

The Save button is the primary action button

•

The Cancel button should be on the Left

•

The Cancel button is a secondary action button

•

There is no 'Don't Save' button

•

There will be no 'Close' icon on the upper Right corner

•

There will be a horizontal bar at the top of the dialog for the message header

•

There will be a brief text description of the message

When you put pattern rules on paper you realize why it is so easy to break patterns and so difficult to maintain consistency. Even this simple dialog box has nine rules, and I did not even list its styling rules!

Construction So let's create this widget, for now avoiding the visual treatment: 1. Create a new widget in your widget library, label it 'Save Dialog Box' and open the widget for editing in the Wireframes pane. 2. One way to assemble the wireframe of the dialog box involves two Rectangle widgets, two Text Panel widgets, and one Rounded Rectangle widget (A), but you may come up with a different construction mix to come up with the dialog (B). 3. In the Widget Properties popup, add the Tooltip text, for example: "Use this pattern for alerts that require a choice between a primary and secondary actions." Note that the description is generic. Since this dialog is a generalized pattern, it should be used not only for a Save case but for any alert that provides the users with two options to continue their flow.

[ 194 ]

Chapter 6

You may consider adding a couple more widgets to your library that are based on this dialog. For example, a pattern for a Primary action button and the other for Secondary action button. Our final example for the topic is a little more complicated, but it involves an extremely popular interaction pattern, the incremental search field.

Example 4: An Incremental Search Widget According to Wikipedia, the incremental search feature, also known as "search as you type", "typeahead search" and so on, has been around since the late 1970s. On the Web it has been popularized by Google, and has now become a standard requisite feature in modern applications regardless of the device for which they were made. There are two good reasons for why this feature has earned such an overwhelming adoption. From a user experience perspective, this is a wonderful, easy to use and time saving feature. As the user types into a searchable field, the system immediately provides the user with a list of potential matches. As a result, the user can select one of the suggested terms with high confidence of finding relevant data. The second reason is that, from a technical perspective, it is possible to implement this capability on the Web with little impact on performance.

[ 195 ]


You are very likely to use incremental search in your prototype at one point or another and on more than one page. Because the simulated suggestions must be contextual to the field in which the user is typing, a master is not going to work. Consequently, the effort involved in adding an incremental search pattern to the widget library will pay off handsomely.

Define the pattern

We are going to create a typeahead search field that has the following behavior characteristics: •

Suggested words or terms will appear in a droplist after the user types three characters into the search field.

•

The style of the matching characters in the list will be normal.

•

The style of the characters that follow the matching characters in the list will be bold.

•

Each row in the list should respond to rollover by changing its appearance: The text will have an underscore styling, and its background color will change.

•

When the user clicks a row, its content should populate the search field and the list will be dismissed.

•

The user should be able to ignore the recommendations and keep typing in the search field. When no matches are available, the droplist will close automatically.

Construction To create this pattern, follow the suggested steps below. As you become more fluent with Axure, you will come up with your own construction methods. 1. Create a new widget in your widget library, label it 'Incremental Search Field' and open the widget for editing in the Wireframes pane. 2. Drag over a Text Field widget from the Widgets pane and label it 'Search Field'. 3. Delete the default text "enter text" from the text field widget.

[ 196 ]

Chapter 6

Our next step is to create the suggestions list. In order to present a clear example, we will simulate a user typing in the word 'Axure'. When you create a list of recommended words and terms, you can save time by using Google or Bing instead of developing one on your own. The lists we create will have the following recommendations: After 3 characters

After 4 characters

axum

axure

axure

axure libraries

axum ethiopia

axure tutorial

axug

axure widgets

axutla publa

axure review

Now, we need to create a dynamic panel with the minimum of these states: 1. The suggestion list that should be generated after the user types in the first three characters. 2. The suggestion list that should be generated after the user types in the first four characters. There are a couple of ways to approach the construction of this dynamic panel. Since one of our requirements is that each row in the list of recommendations should change background color and font style on mouse-over, it is a good idea to utilize Rectangle widgets for the rows because rectangle widgets have a Rollover style. 1. Drag over a Rectangle widget and resize it to 260 by 25 pixels. 2. Assign a Rollover style to this widget: Change of background color and add underscore to the font (B). 3. Type in the word Axum, which happens to be the first recommendation on the list. According to the requirements, the font style of first three characters should be normal and the last character should be bold.

[ 197 ]


4. Duplicate the widget four times and stack them in a vertical column. Change the text in each row according to the list. Also, you can change the Rollover style while you have all of these widgets selected, because this function can be applied to multiple widgets at once (C).

5. Convert the recommendation list, the group of five Rectangle widgets, into a Dynamic Panel: °°

Label the panel 'Recommendations Lists'.

°°

Label the first state '3 chars' (or something similar)

6. Create a second state and label it '4 chars'. Open both states for editing and paste the content of the first state into the second. 7. Modify the text in the second panel according to the list of values. Remember that in this state the font style of the first four characters is normal, and the remaining characters are bold. 8. Finally, set the visibility property of the dynamic panel to hidden, and position it under the search field.

[ 198 ]

Chapter 6

Define Interactions

You just created a compound widget. The search field and the recommendations list have an interesting co-dependency: When the user types in the field the list changes and when the user clicks a row in the list, its values appears in the field and the list disappears. An easy method to approach the task of adding the interaction is to determine which interactions are actually possible for each of the elements, and to identify the triggers that get the action going. Let's start with the search field. When you click the search field in the Wireframes pane, the possible interactions are listed in the Interactions tab of the Widget Properties pane. 1. The user interaction with the widget begins with the user clicking into the field. Should anything happen at this point? No.

[ 199 ]


2. The user types the first three characters. Should anything happen at this point? Yes! After the third character but before the forth, the recommendations list, which has been hidden until now, should appear. Of the possible interactions Axure offers for the Text Field widget, OnKeyUp is the one that can capture the typing action in the field. 3. Do we need a condition? Yes! If the user types three characters, show list in the first state of the dynamic panel and if the user types four characters, show the second state. We just defined the behavior we want to simulate for the search field. Don't try to save time by not writing down the such lists. Although documenting behaviors for your own use will become less important as your expertise increase, the value of writing it out for others, especially for developers, in the form of UX specifications will not diminish at all. To wire the interactions for the field in Axure: 1. In the Wireframes pane click the search field widget. In the Widget Properties pane's Interactions tab double-click the OnKeyUp and add a new case. 2. The Case Editor window (A) opens up. Label the new case '3 chars'. Before applying the actions, we need to define the first condition: Does the length of the text in the search field equal three characters? Click the Add Condition link. 3. The Condition Builder window (B) opens up. Complete the first row. Because we want to evaluate the length of the text in the field, length of widget value (C) is the appropriate condition to check. Close the condition builder. 4. Back in the case editor, the two actions we want to use are: 5. Show Panel(s), because we want to make the recommendations list visible. By default the first state, which shows the 3 chars option will be presented. 6. Bring Panel(s) to Front, because we want to make sure that the recommendations panel is not obscured by other widgets placed in the vicinity of the search field. 7. Close the case editor. In the Widget Properties pane (E) create a new case for the '4 chars' case. You can either copy and paste the first case (F) or create it from scratch. The only modification needed here is to set the dynamic panel state to show the second state.

[ 200 ]

Chapter 6

That's it. We are ready to test this widget; always an exciting moment. Generate the HTML prototype, and type any three letters into field. The first suggestion list will appear and immediately following the forth letter, the second list of recommendations will show. As you move your mouse over the list, individual rows will change their background and the font will be underlined. Of course, you can type any three characters, number or symbols, and the droplist will show recommendations that are hard coded to the match the explicit case we are modeling. Remember, we are creating a prototype, a simulation; we are not coding the real application.

[ 201 ]


So the field interaction is working. Now you want to close the loop by adding the interaction that goes with the recommendations list: When the user clicks one of the recommended lines, it populates the search field and the list closes. Extra Credit—Enhance this widget so it can simulate the following scenario. Let's suppose that you want to refine this custom widget in order to visualize a case where the user types the first three characters, but the third letter is a typo. The user then deletes the wrong letter and types a new letter instead. For example, the user types the letter i instead of the letter u (a common typing error because i and u are next to each other on the keyboard). The final step to finalize the incremental search widget is to add a description in the Widget Properties popup, for example: "Show search recommendations list after the user types 3 and 4 characters into the search field. The user can select a term and it populates the field.".

Managing Widget Libraries You just created your first widget library. It has four very useful widgets, and it is very likely that you will use this library in you Axure work. Perhaps you also downloaded a few community libraries. Now you are ready to use them in your prototype file. The Widgets pane is the hub for all activities related to widget libraries. Using the libraries droplist in the Widgets pane, you can initiate the following tasks: •

Load

•

Unload

•

Edit

•

Refresh

When you choose the Load option, Axure presents the standard Open dialog box (B) which allows to identify the .RPLIB file you want. Select to load the custom library you just completed with the help of the last few pages. It is always a satisfying experience to recognize your work in the thumbnails and to see how text descriptions you included would help others determine what a widget is all about. When you want to use a custom widget, drag it just as you would do with the built-in widgets. If the widget includes variables or a custom style, the Import Wizard dialog (D), would flag such dependencies. If you want to create your own interactions or to avoid importing styles that are incompatible with your project, use the Cancel button to import only the widgets, or click the Finish button to import the entire package. [ 202 ]

Chapter 6

We will continue using the example of the incremental search widget. Now, drag over the incremental search field widget. When you click the field (E) you see that all the cases are preserved, including dynamic panel states and the various interactions (F). Once you create an instance of the widget in your wireframe, that instance is no longer attached to the widget library. Thus, when you make modifications to a widget in the library, the changes are not applied to any of the instances. Remember that the widget library is stored in a discrete file, completely separated from your prototype file. When you add more widgets to the library or make improvements and modifications to existing widgets, these changes are not reflected in a library loaded into your prototype file. In order to update a loaded library, use the Refresh option (G).

[ 203 ]


Masters and Widget Libraries Revisited The widgets we have created thus far are simple and quick to make. In fact, they are so easy to make that in the normal atmosphere off project work pressure, you may decide that it would be faster to create 'one-ofs' as needed, rather than creating a custom widget library. In fact, the time lost to fumbling around repeatedly, looking for a wireframe or for an old project that contains the type of custom widget you need, may end up exceeding the one-time investment required to create a widget library. But if you are not convinced, Axure provides a method to use masters instead of a widget library. Keep in mind that the distribution may be an issue. However, if distribution is not a concern, this technique is handy, especially in very rapid prototyping situations. As an example we will use the Lorem Ipsum widget, and for speed and simplicity sake we will create a blank new RP file. 1. Create a new master and label it Lorem Ipsum. 2. Drag the new master over to the Wireframes pane and open it for editing. 3. Drag over a Text Panel widget and paste the Lorem ipsum text, which you can find in Wikipedia. 4. Adjust the width and length of the text block as you see fit. There is not need to make specific definitions here. You created a master of the Lorem ipsum widget (A), which you can drop on any page. Let us place it on the Home page wireframe. Note that when you mouse over a master, Axure provides a thumbnail view of the master wireframe (B). Also note that the master now appears in the Dynamic Panel Manager pane. Remember, this pane is contextual to the active tab in the Wireframes pane. Place the master also on Page 1 and Page 2. Now, suppose you want to change the width of the Lorem ipsum widget just on the Home page. You know hat if you modify the master, all three instances will change. Axure's provides a solution to this situation: 1. Right-click the master on the Home page 2. In the contextual menu, select the Flatten option (D) from the Master menu When you flatten an instance of a master into the wireframe, you are breaking the link between the parent master and the instance. What you now have on the wireframe is no longer a master. Instead you have a widget or a collection of widgets that are local to the wireframe on which they appear. In other words, future updates to the master will not be applied to a flattened instance. And as a proof, the flattened master instance no longer appears in the Dynamic Panel Manager pane (F). [ 204 ]

Chapter 6

Managing Visual Design Patterns Change is inherent in user experience prototyping projects. Fundamentally, the project exists because of pressures from one or several business drivers, such as response to competitive pressures and changing needs, dissatisfied customers and sales force, high support costs or a window of opportunity to increase market share with innovation. As a result, often the user interface effort is accompanied by a major branding effort. Company and product logos, new or extended color palette, new visuals including photos and icons, are all a part of what should become a master style guide for the project, and all are expected to become part of the prototype.

[ 205 ]


From Low to High Fidelity Prototypes— Strategies Integrating visual design into the prototype poses some challenges for us. It is a common best practice to begin the prototype with rough grayscale wireframes. Axure 6 allows to present initial concepts in a Sketchy style, further reinforcing the tentativeness of the design. The goal in the early stages is to get the 'important' things right: The information architecture of the application, global and intra-page navigation, high-level functionality, critical task flows and so forth. The assumptions is that visual design is premature in the early stages of the project, and can often unnecessarily shift discussions from matters of substance to more superficial topics of colors and graphics. This approach is becoming quickly outdated. User interfaces are becoming the forefront of innovation as they provide immersive environments that engage the user in the most trivial of data entry and data consumptions tasks. The boundaries between gaming and serious applications are also blurring as direct manipulation capabilities on all computing platforms, and especially on handheld devices such as smartphones and tablets, transform interaction with data into a seriously engaging activity. Prototyping a rich user experience that involves data visualization and manipulation is becoming as much about visual design as it is about the data. Regardless of the approach you favor, it is important to remember a fundamental principle: Data and the presentation of data should be separate. It is the only way to create device agnostic interfaces, facilitate easy integration of data, and sharing it with other applications. This principle should be reflected in the user experience design, which falls under your domain, just as it should be clear in the application's technical design, which falls under the developer's domain.

Prototype with Existing Visual Design There are situations in which you are restricted to an established design pattern. This happens when an application has to comply with the look and feel of other applications produced by the company, be consistent with the branding guidelines of a corporation, and in other similar situations. The application you are asked to design can be new, or perhaps you are asked to extend the functionality of an existing application. The user experience you develop may represent a departure from the company's existing or legacy assets, but the visual design must match. You may have access to the master files of the visual assets in the form of Photoshop, Illustrator or PNG files. However, often all you have to work with are the graphics that are used on an existing site or application. These you can extract and modify for use in your own prototype. [ 206 ]

Chapter 6

Axure provides an exceptionally fast method to create interactive prototypes that are based on an existing application. The following example demonstrates how to use screen captures of an existing site to create a custom widget library that becomes the source of building blocks required to design an extension to an existing application. For our example here I am using the Packt homepage at packtpub.com: 1. Take screen captures of the page. PNG Format is best. 2. In Axure, use the Slice Image option to carve out repeating visual patterns (A). You can also refine the various widgets in an image-editing tool such as Fireworks or Photoshop, or a screen capture tool such as Snagit. 3. Create a widget library and add all the graphic assets (B).

[ 207 ]


Further refine the library by remaking the widgets in Axure. This may be easier than you think. For example, the Packt Home page has content panes on the left and right side of the screen. The content of each pane is different, but the widths and shades are identical. 1. Open the capture-made widget (A) for editing in the widget library file (RPLIB). 2. Since this is a rectangle field made of a header and body, let's begin with the header. Drag over a Rectangle widget and click the Fill Color option (B). 3. Apply a Linear Gradient fill using the color dialog. Set the angle to 90 because we need a vertical gradient. 4. To get the matching colors, use the color picker. To select the lower range of the gradient, click the right arrow on the color range bar (D) and then click the More button. 5. In the Colors popup E click the magnifying glas. This is the standard Mac picker. . Your cursor will change into a larger magnifying glass (G). Move it over the lower range of the widget to get that shade. 6. Repeat for the top color to complete the gradient for the pane header bar. 7. Duplicate the header bar and change its color gradient to fit the shades of the body part of the pane.

[ 208 ]

Chapter 6

The final touches include resizing and adding the header and body texts to the widget: 1. Set the width of the bars to be the same as the capture-made widget. 2. Set the header widget text to approximate the original in terms of font family, weight, size and color. 3. For the body section it is a great opportunity to use the Lorem Ipsum widget you created earlier! You will notice that once it is on the wireframe, you have to increase the line spacing and trim the length of the text.. Use the Formatting tab in the Widget Properties pane to get the line spacing to match or approximate the original. 4. When you compare the original visual pattern that you used as a source to the one you replicated using Axure's built-in widgets, you will find that they look identical (C). The recreated widget is absolutely customizable and you can easily utilize it to create additional new panes for the prototype of this website.

[ 209 ]


Apply Visual Design to an Existing Prototype In many UX projects, the visual design, which typically falls under the responsibility of Marketing stakeholders, is developed alongside the new interface but not necessarily in perfect sync. You will frequently find that elements of the visual design generate significantly more heated debates among stakeholders than deliberations around aspects of user flows. This is not surprising because it is easier to respond to aspects of visual design such as colors, images and graphics; passionate arguments on the virtue of one color over another have been taking place since people started to create images. When a visual design has been approved and a style guide developed, there is an expectation to see it reflected in the prototype. And this is where planning and wireframe construction become very important.

Summary Axure allows us to extend the visual and interactive vocabulary of prototypes. This is important for a number of reasons. •

With new operating systems and mobile devices such as smartphone and iPads, the language of user experience is quickly expanding. The basic standard widgets, which were the staples of software user interfaces for nearly half a century are no longer sufficient and require frequent reinforcement.

•

Your project may have very specific visual and or interaction patterns that serve as construction guides but often require slight modifications.

•

You find yourself using the same custom patterns repeatedly and in multiple projects. It makes sense to aggregate these into a single file that can save time.

Widget libraries are a form of plugins and extensions that are very common in other development tools. Their capabilities strengthen the product and extending the range of users. Utilitarian or commercial motives drive companies and individuals to distribute their work to the community, and companies can focus their development efforts on delivering more functionality. It has been proven that openness can play a key role in the lasting power of a software product; it is often the factor that turns a product into a platform.

[ 210 ]

Managing Prototype Change Most UX projects are subject to two major drivers of change, that often place the design effort at some risk, due to conflicting approaches. On the one hand, UX work is inherently iterative. It is driven by the notion that rapid cycles of design, review, validation and revision, are likely to yield successful results. On the opposite, are typical constraints of schedules and budgets. This is the source of pressure to both reduce and add scope, eliminate usability features that threaten to complicate coding, and limit the number of user validation opportunities. Additionally, there is the sort of change that is tied to our design tool. As you shift from sketches and high-level wireframes to detailed design and interactivity, you are constantly changing the Axure file. New pages, masters and dynamic panels are added rapidly and wired with new interactions. You copy-and-paste sections of wireframes and often duplicate entire pages and masters, to quickly create alternative paths and possible states. You also keep old wireframes, just in case you may need to use or repurpose them at a later point. Before you know it, you will be looking at a fairly bloated Axure file. It may take longer to generate the HTML prototype, locating wireframes you need.In this chapter, we look at Axure feature and construction strategies that will help you avoid bloating, and facilitate your ability to implement rapid changes to the prototype, for whatever reason.

Managing Prototype Change

Transition to Reality UX projects tend to follow an unfortunate, predictable path. We begin with a project launch fuelled by excitement, high aspirations and a bucket full of critical strategic goals. We follow with an intense and stimulating, high-level conceptual explorations phase, in search for a ‘killer’ user experience. The outcome – a polished high-fidelity vision is presented to the decision makers, who, impressed and excited, bless the ambitious project with the ‘Green’ light, allocate a meager budget and issue a directive for delivery – yesterday. The organization immediately shifts into scramble mode, and your prototype needs to address the nuts and bolts of low-level requirements, technical constraints and pragmatic compromises that need to be made in order to meet the timeline and budget. Perhaps this description is bleaker than what you have personally experienced so far, but there a good chance you will. According to the2010 IT Project Success Rates survey by Scott W. Ambler, Chief Methodologist for Agile and Lean for IBM Rational1: • Less than 55% of IT projects, on average, are successful. • About 32% of IT projects, on average, are challenged. • The rest, about 13%, on average are failures. Hopefully, we all get to work on the 50% of projects that are successful. But there is a high probability that requests for changes in scope and direction of our design will require re-thinking and compromise. A positive driver of changes is built-in to all UX projects, is the iterative process. As we translate business and technical requirements into user experience features, we are dependent on stakeholder and user feedback to validate and tweak the design.

Align Expectations What exactly are you expected to deliver, and what is the impact, from an Axure construction perspective? These are tricky but tightly coupled questions, especially for medium and large projects. The answers to the first question underscore the relationships and agreements between yourself and the stakeholders of the project. The answers to the second question impacts your ability to deliver successfully on the agreements made. It is important, however, that you and stakeholders on the project will develop a shared understanding of, and agreement about, the level of work and detail expected from UX deliverables in general, and Axure related deliverables, in particular.Before you can come up to an agreement, however, you

1

See Dr. Dobb’s: http://drdobbs.com/architecture-and-de-

sign/226500046

[ 212 ]

Chapter 7

need to estimate the requested work so that you can develop a reasonable estimate of time and budget. There is a tendency to come up with overly optimistic estimates. The reasons might be competitive—you are bidding on the project and want to come ahead of the competition. It might be a lack of previous experience in developing an application for a specific domain, or, lack of experience due to distortion of scale: Something that worked in a small startup project may not work for a large enterprise project. In any case, bad estimates will put the entire project at risk. There are three major elements that influence the ability to estimate the UX effort: • The software development model of the project. • The expected granularity level of prototype. • The expected detail level of the UI specifications document(s). The implications of those elements on your ability to manage the budget, schedule and quality of deliverables, such that they are always in alignment with the project, is critical. Not to be under-estimated, is also the impact on your well-being. There is a high probability that you might find yourself working impossible, crazy hours, just to keep up with an endless stream of demands and changes that you did not estimate for, but stakeholders expect you should deliver. This situation is not uncommon, but it can be avoided, or at least, minimized.

Development Models We are working on software, and traditionally, UX has been weak on integration with Development organizations and methodologies. In many projects, UX is being recruited by the business side, and imposed on the development organization, which does not lead to healthy relationships. Although the trend seems to be improving, it is important to get familiarized with the prevalent development methods in general, and the development flavor of your projects, in particular.

Waterfall Just a few years ago, the acceptable practice was to estimate the effort based on the number of wireframes needed to visualize an agreed upon set of screens and user flows. Common development model followed a fairly linear path, known as ‘Waterfall’, in which requirements were developed first, followed by software and interface design activities, software build, testing, release and from then on, to maintenance to support and enhance the software until the end of its life cycle.

[ 213 ]


The traditional waterfall model did not require much collaboration or iteration, and being the dominant method of software development, it contributed greatly to the creation of a ‘siloing’ effect, in which business partners, analysts and developers each worked in isolation from each other, handing off deliverables ‘over the fence’. There are a lot of drawbacks to this process and unfortunately, covering the topic at length is beyond the scope of this book. But to touch on an important shortcoming from a UX perspective, too many assumptions were made by stakeholders and analysts, about how the interface should be designed, and nothing or little was done to validate these assumptions with real users before the requirements, and later the actual software, were built and released. But one minor benefit was the relative ease of planning and estimating the user interface effort, because so much of the planning was done up-front. Of course, once UI work actually started, the actual deliverables almost always deviated from deviations from the original estimate. But keeping track of change was also relatively easy, as long as you and the stakeholders on the project established a clear change process.

Agile These days, Agile development is all the rage. The Agile model shares fundamental values and principals with the well established UX approach to User Centered Design. In fact, the first value listed on the ‘Agile Manifesto’ (see agilemanifesto.org) is: “Individual and interactions over processes and tool”. This is a value that any UX practitioner subscribes to. The Agile software development model is a highly collaborative, iterative, and follows four key phases: Requirements, architecture and design, development and finally, testing and feedback. Without iteration and emphasis on delivering working software, these phases may remind you the Waterfall model. Instead of establishing both high and low level requirements before development begins, as is the case with traditional Waterfall model, Agile starts with high level requirements as input for immediate coding but also considers requirements in a flexible way, which supports rapid adaptations and change as the iterative process moves on.

Jargon There are, however, some pitfalls to keep in mind, from a UX perspective. To start with, Agile is fraught with technical jargon and terminology such as Scrum, Sprint, Timebox, Backlog, Burn Down, Team Velocity, Planning Poker, DoD and on and on. Fortunately, there are also plenty of good resources online that can help you sort things out. [ 214 ]

Chapter 7

Jargon heavy practices are always problematic, because there is an increased risk of communication failures due to misinterpretations of key terminology. Always remember not to take anything for granted, and make sure that you, and those in charge of the Agile process, are on the same page regarding the definition of various Agile terms. This can reduce the risk of problems down a project, due to inconsistent application of the same term, by yourself and other team members. If you are not familiar with the meaning of a term, don’t hesitate to ask. If you are embarrassed to ask, or worried that not being familiar with terminology, will have a negative impact on how others in the team perceive your competence, research the term first and then discuss.

Agile Flavours There are several agile methodologies that share the basic principles of the agile model, but differ on implementation and sometimes also terminology and practice. These methodologies include Scrum, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD) and Lean Software Development. The profusion of methodologies can be daunting for UX professionals, who in general, tend not to be well versed in the arcane of developers. Agile is practiced in many flavors, and differences between implementation nuances of the model at various organizations, can be substantial. Make sure to get a solid understanding of the particular Agile process that is planned, or is being practiced on your project, as early as possible. Your previous experience with Agile may lead you to make assumptions about the process, so remember – when you are part of a larger interdisciplinary team, don’t make assumptions, and don’t be shy about asking for clarifications.Sometimes, the project plan has been outlined by the development team well before the UX resources join the project, especially when the UX effort is outsourced. This plan may not take the full impact of specialized UX tasks into consideration. For example, usability testing activity may be included, but none or few of the activities that support the effort are accounted for. For example, allowing enough time for recruitment, creating the scripts, and preparing the Axure file to match tested scenarios. Reviewing the plan and ensuring that you are comfortable with the plan is important.

[ 215 ]


Estimating Your Axure Work It can also be difficult to estimate the amount of Axure work that will be involved in an Agile or Waterfall flavored projects. A few years ago, agreements could be easily made around the number of wireframes and the number of iterations that were to be the basis for acceptance of work. If an interactive prototype was commissioned, it was a separate deliverable, typically coded by a front-end developer. But with Axure, the boundaries are blurred. The most fundamental of questions need to be considered.For example, what is a wireframe? Suppose we agree that the Home page is an example of a wireframe. Before Rich Internet Applications (RIAs), back in the days of static wireframes produced with a tool like Visio, the Home page wireframe would be considered a single wireframe, for the purpose of estimating and delivery. Today, we still have a Home page, but when it is constructed for an RIA, in a tool like Axure, it is a composite of widgets, masters and dynamic panels. Each master is an independent wireframe, itself made of widgets, dynamic panels and perhaps other masters. Each dynamic may be a set of unique states sometimes composed of with other dynamic panels and masters. And, the wireframes also include interactions. So, a single Axure wireframe, can translate to a lot more work, compared to what a traditional wireframe used require. That’s not because Axure is inefficient. On the contrary, it is because: • Axure enables UX designers to visualize rich internet applications, at a level of fidelity that is generally on par with developer-produced prototypes. Modern applications are asynchronous, which means that data can be sent to and from a single page without having to reload the page. Which means that modern pages are a composite of widgets that can operate independently from other sections on the same page, while maintaining contact with the entire page. A page in an Axure prototype can model personalization, context and local. The level detail and complexity that UX designers can visualize has increased tremendously, but not the allocated schedule and budget of the typical project plan. When it comes to the Agile model, UX can become tricky. In each sprint, the developers produce code that supports the work in the upcoming sprints. Similarly, the Axure file gets more and more detailed, as the prototype elaborates flows and interactions that were developed in earlier sprints. But the efficiencies that come from writing code do not translate efficiencies in your Axure file.Instead, the files grow as more pages, masters and dynamic panels are added, old drafts get mixed in with new proposals. Interactions, variables and raised events increase the complexity of the file. In an environment that requires rapid iteration, estimation and change, the importance of constructing your Axure file in a disciplined way becomes important. What appears as a minor requirement change might cascade to you having to modify [ 216 ]

Chapter 7

any number of widgets and interactions. This can impact your ability to move at the velocity (jargon alert!) of the development team.

Calculate Your Time The schedules of many projects still fail at the most fundamental of all project realities, by falsely equating a day’s eight hours block, to eight hours of productive work. Many UX practitioners, either from inexperience, optimism or desire to be good team players, tend to gloss over this severe problem, when reviewing the schedule. Here are some of the key culprits that require time that it is typically not accounted for in the plan: • Analysis and Synthesis:UX is about creative problem solving. And to come up with good UX, especially for complex task flows. You need time to digest the information that you collect during discovery and requirement development, to analyze and synthesize the material and emerge with a concept or an approach. In short, you need time to think, and thinking takes time.Exploration and iteration take time – It is rare to hit the appropriate solution at the first draft. You need to come up with a solutions that is complete and works at the first go. • Meetings:UX is face-time heavy, meaning that face to face meetings with stakeholders and team members will consume a significant of your day. At some points of the project meetings can account for over 50% of your weekly schedule. • Elaboration: Despite Axure’s efficiencies and ease of use, wireframing and interactions take time, especially if you are modeling multiple use cases, conditional flows and exceptions. You will be generating the html prototype frequently, reworking masters and states and so on. This is all time consuming. • Snags: Sometimes you will get unexpectedly stuck on a wireframe or interaction. You may have to reconstruct a wireframe previously considered finished, as a result of a required change. Don’t assume that each Axure session will go absolutely smooth and fast. • Communication: Phone calls and conference calls, responding and writing emails, creating presentation, reading and creating support documentation – These activities will quickly add up to a substantial amount spent daily on project related work which you cannot postpone much.Downtime: We are not machines yet, although in some projects you may feel the expectation to act like one. Taking food, coffee, snack and washroom breaks are fortunately still allowed, and should be encouraged, because productivity, creativity and motivation suffer, as a result of work pressures. Taking a break every [ 217 ]


50 minutes or so is also encouraged, in order to rest your eyes, stretch and improve your circulation. Finally, even if you are in a progressive environment, a quick visit to the washroom turns into half an hour spent listing to a colleagues’ stories. • Health Issues and personal emergencies: We all get ill at some point or another. Flu, allergies and other normal, seasonal maladies will require us to take a few days off work in order to recover, not to mention avoiding getting the entire office catch your bugs.There are no absolute answers to estimating both the amount of Axure work needed, such as wireframing and interaction, or the amount of real time it will take to produce. But you can apply common sense and experience, to the any of the following formulas: • The Optimist: 8 hours – (25% meetings and communications + 15% other project related stuff + 20% downtime) = 40%. In other words, plan to be productive work of about 3 hours of actual work. • The Realist: 8 hours – (40% meetings and communications + 20% other project related stuff + 10% downtime) = 30%. In other words, plan to be productive work of about 2.5 hours of actual work. And that is why, dear reader, you most likely will find yourself working well over eight hour days, including weekends, and sometimes through holidays. If your experience does not agree with my description here, please let me know! Sometime, software projects, including those that started with the best of intentions, but a weak project plan, degrade into a dreaded ‘death march’, in which the entire project team is made to follow an impossible schedule in order to meet an unrealistic goal.

Align Expectation with Education You may not be able to impact the entire project plan of a large project, of even a small project. But you can take corrective measures to align stakeholders with the UX work. The most important aspect to keep in mind is that most people have no idea about the work UX designers do. Stakeholders and team members from other disciplines consume our deliverables and work products, but often will underestimate the amount of effort that is invested into producing them.Make sure explain the UX work process to other teams. This may not be necessarily something you should bother top executives with, but you can get substantial cooperation and understanding if you meet with key members of the business and development teams, explain the work process, a bit about the value of using Axure, but also about the amount of work you need to do in order to create those great interactions and contextual flows. Most people get that, and will begin taking into account the leg time that UX requires. [ 218 ]

Chapter 7

In fact, it is becoming a common practice in Agile project to have a UX sprint ahead of the main sprints, in order to prepare the wireframes and interactions needed to support the work of developers and analysts. If this is not planned for the project you are joining, do the research and make a proposal to do just that. Armed with relevant reasoning, you might be able to reduce the UX risks on the project.

Align Expectations for Prototype Granularity The prototype will be consumed everyone by involved in the project. You will use it throughout the project to demonstrate to stakeholders how the requirements and flows are fulfilled in the design and for usability validation and testing activities. By what level of granularity is expected for the prototype? Propose a practical approach: not every interaction can be simulated

Align Expectations for Detailed UI Specifications

The primary audience for UI specifications is the development team. Following the general approach in this chapter, don’t assume that your understanding of what a UI spec is, matches that of the development team. We dedicate the next chapter to the process of generating high quality UI specifications document with Axure. But in the context of aligning expectations, there are a few steps you can take to make sure that you end up satisfying the team.

From Concept to Detailed Design The first phase of most UX projects can be considered as the ‘honeymoon’ phase. The period is characterized by the following attributes: • Excitement: It is period of exploration, during which you have an opportunity to understand the goals of the project, develop and validate a concept with stakeholders, and end users. • Team building and familiarization: Like the honeymoon of a newly married couple, everyone is in their best behavior, but some cracks may open here and there. If you are a consultant, you may also start getting a sense of internal politics. If you are an internal resource, you may already know many in your team, which might help you make fast assessments about the level of collaboration you can expect, from others. [ 219 ]


• High-level requirements: People often travel for their honeymoon to some remote, romantic destination such a Paris, for example, or some tropical island. It is an opportunity to be away from the grind of daily routine. Similarly, the vision prototype is a high level concept, built to address strategic, high-level goals. It is unnumbered by the constraints of low-level business and technical requirements. You can explore and propose cool user interactions, highly efficient contextual presentation of information and user flows.. Typically, your transition from concepts to detailed design will be impacted by the work products and deliverables you created, and the expectations around the level of detail and elaboration in following phases.From Vision Mode In the vision prototype you covered high-level UI framework, navigation and layouts of the application. You demonstrated key interaction flows and interactivity features. Using Axure to wireframe and build the concept file, your progress rate was probably high, and so was your ability to respond to feedback and requests for modifications. Stakeholders and management embrace the concept, and you are good to go, move on to the detailed design phase.You need to resolve the following question at the start of the project, or, if that is pre-mature (for example, the project has only been approved after the vision’s acceptance). • Are you expected to continue and deliver such level of detail of interactivity in during the detailed design phase? If the answer is yes, then, for what purpose with this prototype serve? • Do you have to time and or UX resources needed to sustain a full-fledged prototype throughout the detailed design phase?

From Sketch mode If you were using the sketch mode for initial explorations of the user experience, there is a point at the process when the ‘sketchy’ styling becomes extraneous. At the conceptualization phase, the sketch effect can help communicate to stakeholder and reviewers, the rawness of what they are looking at. This is important, because most people tend to respond to what they see, and the sketch look helps mitigate the risk of taking early drafts as actual design. There is a potential for an opposite situation to occur, in which stakeholders and participants in early validation sessions might assume, that the sketchy design IS the intended design. After all, it is subject to the same potential tendency to consider a visual presentation as a finished, or close to finished approach. After all, we live in times of great variety and innovation in user interfaces, so the viewer may not realize that the sketch effect is meant to communicate a draft. Sketch effects are new to Axure, and it is not yet clear how useful it will be. In any case, if you find that it creates confusion instead of helping out, cancel the effect: [ 220 ]

Chapter 7

Toggle sketch effect in the html prototype: 1. In Axure, click the Prototype Icon to show the Generate Prototype dialog. 2. Uncheck the option Do not apply sketch effects. 3. Regenerate the prototype, and the browser will render the wireframes without the sketch effects. 4. You can always re-generate with the sketch effect by checking the option again.

[ 221 ]


Hide Sketch Effect on the Page: Once set on a page level, the sketch effect is also visible in the Wireframes pane, which can become a visual destruction. You have two options to remove the effect: 1. Page level: If you used a page style to control the sketch effect, open the page for editing, and change the option in the Page Style droplist (A) under the Page Formatting tab back to Default (B). This will require a page by page modification.

2. Global level: To hide the effect from all wireframes, when displayed in the Wireframes pane, select the Show Sketch Effect option (B) from the Wireframe menu (A) and uncheck it (C). The current wireframe open for editing (D), as well as all others, will from now on be now displayed without the effect.

[ 222 ]

Chapter 7

Foundations and Scaffoldings Determining Wireframe Width Axure wireframes have a fixed width, which you determine. A fixed width means that the wireframe will not resize dynamically to fit the available screen width, when generated. To determine the total width of your page wireframes, you need to consider: • The target device • The screen’s resolution While the evolution of display resolution for desktop and laptop computers evolved in standard leaps, literally inching its way from 640x480 pixels to today’s hi definition screens, Tablets and other mobile devices are all over the map when it comes to screen size and resolution. Unless you are designing an application for specific device, it is impractical to create a wireframe layout for each possible target display. But there are some practical approaches to consider. If you are developing a web application that will be viewed on a computer screen, it is advised to select a lower common denominator, such as 1024 pixels. This number increases every few years, as the quality and screen resolution improves. Many UX designers work with very large screens, because the larger the screen, the more productive you can be. It is common to use multiple displays, to further increase productivity. But it is important to remember the target audience for the application we are designing. Many users may be restricted by much smaller screens. Typical examples are a sales people whose primary monitor is a small laptop. [ 223 ]


Another benefit of designing with 1024 pixels in mind, is that a number of tablets, including the iPad and the Samsung Galaxy, use a screen resolution of 1024 pixels horizontally. This means that with minor modifications to page construction, you can design for both computers and some popular tablets. The actual width of page wireframes should be less than 1024 pixels, for a number of reasons: • If you present the prototype on a screen with a resolution of 1024 (A), a projector for example, the wireframe will extend the entire width of the browser. • If you need to show the Sitemap pane, you will no longer be able to show the entire screen and have to scroll horizontally (B). • With the Sitemap pane collapsed, but vertical scroll bar on (C), about 20 pixel on the right will be lost, which may be a problem in a presentation. • At higher horizontal resolution setting, for example, 1280 pixels (D), an entire wireframe set to 1024 pixels will fit, leaving a wide margin on the right. • This margin will be eliminated when you turn on the Sitemap pane (E), and moreover, a vertical scroll will cause a loss of about 20 pixels on the right, requiring use of the horizontal scroll bar.

[ 224 ]

Chapter 7

There is no set standard for setting the width of a wireframe. It is common to use 960 pixels, but 1000 pixel will also work without triggering the horizontal scroll bar. If you are working on a data-intensive application with grids that require many columns, even extra 40 pixels can make a difference.

[ 225 ]


For applications that are intended for localization, especially into languages such as German or French, you may want to consider placing an even tighter restriction on the design, by using an overall width of 900 pixels or less. If you can fit the English version into the page, there is a very high likelihood that the translated content, which can be up to 40% wider, will fit without wrapping.

Guides The concept of page guides has been around for centuries and the most common use can be seen in newspapers. While the width of the page is obviously fixed, an invisible set of guides make it possible to organize and align contents on a page, in a verity of ways. For example, some pages may use four text columns of equal width, while other pages, two of the four columns are used for text, and the other two are merged into a single column, for a picture. The idea, that the contents of a page can be organized in a flexible, yet standard arrangement of columns, is ancient. The overall effect helps to create good page layouts that are pleasing to the eye, due to the fact that, the width of all columns is based on the same ratio. If you consider the guide early in the design process, you are likely to gain efficiencies of construction, because widget widths will be set to a standard ratio, allowing you the flexibility to mix and substitute widgets across pages. The most common use of guides, however, is casual. Typically the guide is needed to align objects across a horizontal or vertical line. Most users of drawing and painting applications are familiar with the convention of creating guides by dragging them over from the vertical or horizontal rulers. Guides are a welcome addition to Axure 6, and the same convention applies: 1. To add a horizontal guide to the page, click the horizontal ruler and drag down to the page area. A thin green line will appear. The Y coordinates will be displayed to assist with exact positioning. 2. To remove a guide, you can either click and drag it out of the page (B), or right-click it and use the Delete option from the context menu. 3. To lock a guide to the page, right-click and select the Lock option from the context menu (C).

[ 226 ]

Chapter 7

With Axure, it is possible to move beyond the casual use of guides as a temporary alignment aid. You can also take advantage of guides as scaffoldings that support the consistency of layouts and patterns across multiple pages of your prototype. Axure supports both page level and file level (global) guides.

Global Guides Think of global guides as an extension to the concept of a master – Both maintain their physical properties across pages. Need to make a modification – Do it only one, and all the instances will be updated.Axure comes loaded with two global guides based on the 960 grid system that was created by Nathan Smith. (See http://960. gs). His idea was “to streamline web development by providing commonly used dimensions, based on the width of 960 pixels”. Note the terminology mix-up here—Axure has decided to keep the term ‘grid’, which is used by the 960 system, despite the fact that in Axure, the term grid is used elsewhere. But the global guide functionality is basically about applying a guide-set master. To access and apply the grid to your pages: 1. Select the Grid and Guide Option (B) from the Wireframe Menu (A), and from the sub menu, select the Create guide… option (C). 2. The Create Guide dialog (D) will appear. 3. From the Presets droplist (E), select one of the two 960 grid options you want to use, or at least to experiment with. 4. Check the option Create as Global Guide. (F). If you leave the option unchecked, the guide will only be applied to the current wireframe. 5. Click OK to close the dialog box. A set of guides will appear on the page (G), and on any page you open from now on. 6. Global guides are pink. You can click to select and move any of the lines. A selected guide line is green. You can also lock the guide to prevent the lines from shifting. [ 227 ]


7. At this point, the guide feature is limited, although we can expect Axure to enhance the functionality. For example, at this point you cannot save a customized set of guides and add it to the list presets. 8. You can change the settings in Presets dialog, and your custom grid will become the default guide-set applied to all wireframes. However, make sure to write down your custom settings: The Preset dialog will reset, and will not display your setting. As I noted earlier, we can expect this feature to work more smoothly in the near future. 9. Currently, only one set of global styles can be used. This means that you can use either the 12 column grid, or the 16 column grid across all pages.Each column of the 12 column guide-set is 60 pixels wide (H). The gutter (I), or, the space that separates each column from the next, is 20 pixels wide. There is a 10 pixels margin (J) on the left and right.Each column of the 16 column guide-set is 40 pixels wide (H). The gutter (I), or, the space that separates each column from the next, is 20 pixels wide. There is a 10 pixels margin (J) on the left and right.If you want to delete the global guide, select the Delete all Guides option from the Grid and Guide menu. Note that if the guide is locked, you will have to unlock it first, before the delete function can be applied.

[ 228 ]

Chapter 7

Page Guides Guides are available also on a page level. This means that each page, or set of pages, can conform to the alignment and spacing governed by guides that you dragged over from the horizontal and vertical rulers. Page guides are typically the casual guides mentioned earlier. Perhaps your design does not conform to the 960 grid, or you cannot use a global design because your application contains a variation of layouts. The ability to control guides per page provides flexibility for page level design.I mentioned that page level guides can be applied to a set of pages because [ 229 ]


you can copy and paste the guides from page to page. Currently you cannot save local guides and reuse them later, but it is likely that such functionality will be added at some point.

The Grid A grid is a visual tool that helps with organization of a page layout and is common to most drawing and illustration software. The grid is an infinite pattern of horizontal and vertical lines that are set to a pre-defined interval, and placed in the background. The grid lines can be directly manipulated on the wireframe page by moving the lines around, and this sets the grid apart from the guide feature. The grid is perhaps a trivial, little noticed feature of Axure, and many users don’t bother to display it, or ever to change the default ‘factory’ settings. But you can improve the construction quality of your wireframes by taking advantage of the grid. For example, help align widgets across a horizontal or vertical axis.

Customizing the Grid You can customize the Axure grid using the Grid Settings dialog, which you can access from the Grid and Guides option in the Wireframe menu. Alternatively, you can right-clicking anywhere within an empty space in the Wireframe area. You can toggle the visibility of the grid. Axure also lets you toggle the snap feature, which makes grid lines function like a magnet, as you drag a widgets across a wireframe, such that it aligns, or ‘snaps’ to the closest grid line. 1. From the Wireframe menu (A), select the Grid and Guide option (B), and there, continue to select Grid Setting… option (C). 2. The Grid dialog (D) open. The default Axure grid is set to a 10 pixel spacing. Intersection style. If you are using a Mac, the default DPI setting is set defaulted to 72, which is the Mac standard. If you are using the PC version, it is defaulted to 96 DPI. 3. You can modify any of the settings (E), although changing the dpi is typically not required. 4. If you switch the grid style to Line, keep in mind that it might be difficult to distinguish between grid lines and guide lines. Note that in the screen capture, the lines are Red (F) but this was done only to make it easier to see the otherwise fait blue grid.

[ 230 ]

Chapter 7

Page Templates Visual consistency is a fundamental principal of good software design. It does not mean that all screens in a given software need to have the same layout. Rather, the we expect a level of visual coherence that will guarantee an experience consistency across the application. There are a couple of important advantages to think about pages, as templates: • Advantage to you: Leverage design patterns across instances of the same screen, to simplify construction of your Axure prototype and specifications. We often need to create multiple versions of the same page in order to visualize variations, and, although a lot can be done using interactions, you may also need to have the explicit instances for the UI specification document, presentations and so on. [ 231 ]


• Advantage to the development team: Developers typically think about templates and code reuse since efficiency and reuse are native to programming. Developers will instantly understand and appreciate your incorporation of templates into the design. It is valuable to discuss your thoughts about structuring the templates with the developers, and tweak, if needed and possible, the way you structure and specify your wireframe pages.The concept of a template is very similar to that of masters, but in contrast to masters, templates are not a built-in Axure feature. But, while currently there is no template management functionality in Axure, you can still use the concept in your file.

Page Style Editor With the page style editor, a new feature introduced in this version, you can create custom page level styles, which you can apply to specific page in your prototype. Key benefits of this feature are: • Consistency across all pages the share similar properties. • Fast and efficient application of change during the detailed design phase: When changes to any of the page style properties are called for, you only need to make the modification once, to the custom page style We touched on the page style editor earlier in the book, in the context of the Sketch Effect feature. But there are additional properties you can control, which, similay to the properties listed in widget style editor, map to CSS properties. Axure shields you from having to know CSS, its terminology and syntax. But understanding the mapping can be useful when you discuss visual design with developers and designers Axure Page Style Editor

CSS

Page Align

Margin and Padding

Back Color

background-color

Back Image

background-image

Back Image - Import

background-attachment

Horz Align

background-position

Vert Align

background-position

Repeat

background-repeat

Overall, Axure lends itself easily to the concept of page templates, and Developers, as well as most visual designers, are very comfortable with the concept. As a result, as you construct your page, try leveraging the concepts as much as possible, which in return will help you apply global changes faster. [ 232 ]

Chapter 7

It is easy to identify several page templates in our demonstration project. For example, the home, category and item detail pages:

Home Page Template You might wonder how come the Home page should be considered as a page template, since there is only a single home page in the application. But as you think about your Axure prototype file, you realize that in fact, you use several instances of the home page. For example, it’s appearance to a casual visitor, to a registered user, localized, and so on.In the demonstration example, a lot has happened since the project kickoff. When you compare the initial sketch (A) to the iterated version (B), you note the change in the body area. The rest of the framework evolves as well, of course, but the use of masters help maintain the overall trajectory.

Category Page Template Although the site offers various kinds of media, it is desirable to present them using the same layout. This enables efficiencies of code, and from the user’s perspective, a consistent experience when browsing for items, regardless of their category. This is typical to experience in popular applications such as Tunes and Spotify. The template has evolved greatly since the initial sketch (A), primarily in the Body area, which initially was demarked as a place holder, and now includes a lot of the functionality needed to support browsing through various content offerings across categories (B). [ 233 ]


Detail Page Template For the page detail, we are also incorporating an example of design for multiple devices. In this case, the web-based layout (A), and an iPad layout (B).

[ 234 ]

Chapter 7

Widget Style Editor The widget style editor afford globalcontrol over the visual properties of a widget type. In other words, it is Axure’s user friendly way to apply CSS properties to widgets. Keep in mind that you cannot set, however, the height and width of a widget using the style editor. The Style editor is contextual to the widget and the properties that cannot be controlled are disabled. You can launch the style editor even if no widgets are selected, and in fact, before any wireframes have been created. This means that you can pre-establish and customize the default appearance of widgets before you start working on the file.Note that: • Not all the widgets that appear in the Widget pane are listed in the style editor. That’s because some widgets, such as the dynamic panel or iFrame, don’t really have independent visual properties of their own. • The Rectangle, Placeholder and Button Shape widgets are referenced as Button Shape widget in the style editor, so changes to the default of that style apply to these three widgets. Widget

Style Properties Font

Font Bold Italic Size

Under- Align- Vert Padding Line Font line ment Align Spacing Color Y

Image Box

Y

Y

Y

Y

Y

Y

Text Panel

Y

Y

Y

Y

Y

Y

Y

Y

Hyperlink

Y

Y

Y

Y

Y

Y

Y

Y

Button Shape

Y

Y

Y

Y

Y

Y

Y

Y

Button

Y

Y

Y

Y

Y

Y

Y

Text Field

Y

Y

Y

Y

Y

Y

Y

Y

Text Area

Y

Y

Y

Y

Y

Y

Y

Y

Droplist

Y

Y

Y

Y

Y

Y

Y

List Box

Y

Y

Y

Y

Y

Y

Y

Checkbox

Y

Y

Y

Y

Y

Y

Y

Y

Radio Button

Y

Y

Y

Y

Y

Y

Y

Y

Flow Shape

Y

Y

Y

Y

Y

Y

Y

Tree Node

Y

Y

Y

Y

Y

Y

Y

Fill Color

Y

Y

[ 235 ]

Line Line color Width

Tree Node

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y


Default Widget Styles When you start a fresh Axure file, all the widgets have a ‘factory’ default. By tweaking the default style of widgets in your project file, you can save time and enforce consistency across all your wireframes. The changes you make will immediately be applied to all the widgets for which you modified the default style, across the entire file: For example: 1. Each time you drag a Rectangle widget onto the Wireframes pane, its visual properties will be pre-set to the default setting. These include Black line and White Fill, The Font is Ariel, size 13 (On the Mac), and so on. 2. In the toolbar, click the widget style editor icon (A), to launch the Widget Style Editor dialog (B).Widgets that can be controlled by the editor, are listed on the left-hand column, under the Widget Defaults column (C). 3. When you click any of the widgets on the list, you can see its visual properties. 4. Modifications that you make to these properties (E), will be applied to all the widgets of this type across the entire prototype. For example, if you change the font, font size, background and fill colors of a Rectangle widget, the new settings will to all the Rectangle, Placeholder and Bottom Shape-based widgets (F) across all your wireframe in this file.

[ 236 ]

Chapter 7

If you change to the font family of one widget, for example, from Ariel to Verdana, make sure to apply the same properties to all the widgets listed in the editor, unless the font variation is called for by design. Also, make sure to review all your wireframes—some fonts are wider than others, so text wrapping may occur.

Style Painter The style painter is a welcome new addition to Axure 6, and a common feature of drawing and painting application. It allows you to apply the visual properties from one widget, to other widgets.For example, suppose you have a dialog box with a primary-action button, and four secondary-action buttons. Initially, all the buttons, [ 237 ]


made of Rounded Rectangle widgets share the default style for that widget, and all look the same. You want to style the action buttons in a way that distinguishes primary for secondary. 1. You start by applying the visual properties for the primary, and one of the secondary-action buttons (A). Your options to apply the style to these widgets included the toolbar, or, the Formatting tab is the Widget Properties pane. 2. You want to apply the styling of the first secondary button, to the other there instances. With the newly styled button selected (B), click the Style painter icon on the toolbar (C), or alternatively, on the Formatting tab in the Widget Properties pane, under the Style section. 3. The Style Painter dialog (E) appears. Click the Copy button (F). Don’t close the dialog yet. It will float above the work area, but you will be able to made selections on the wireframe. 4. Select the three unformatted secondary buttons (G), and then click the Apply button (H), in the Style Painter dialog. The desired style will be applied to the selected buttons.

[ 238 ]

Chapter 7

[ 239 ]


Of course, you could have selected all four buttons, during step 1 of the process. But the goal was to present the feature without complicating the example. The power of the Style Painter becomes more evident in the following real-life situation: You have a set of wireframes, and you start applying some visual styling to various elements, such as buttons. If you use gradients, and continue to manipulate several of the other visual properties, applying the same formatting on widget on other pages will be a tedious, time consuming task, potentially prone to mistakes. It can also be too time consuming to use copy and paste, in an effort to replace an unformatted widget on one wireframe with formatted ones from another wireframe. That is especially true when the widgets in both wireframes already include interactions, annotations, and have different labels.

Pros Easy and fast, the style painter helps you maintain visual consistency across widgets. It is a real time-saver when you have to apply a set of visual properties that includes gradients, from widget on one page, to widgets on other pages. This is especially convenient in cases where, using copy and paste to replace unformatted widgets with formatted ones, is not a productive option.

Cons There are a number of drawbacks for using the Style Painter as a systematic method for implementing style changes.You must apply the desired style to all like-widgets across all wireframes, which can be time consuming, especially if the style needs to be changed as a result of feedback. • Even when minor style changes are required, for example, changing one of the gradient values used for the fill of primary action-buttons, the task of change is still time consuming because you have to go through the entire file, and make the changes.It can be difficult to differentiate between widgets that have been updated and those that were not. Pressing the Apply button will be fast, but the rest is not. • If you started to apply the change to some widgets, and had to stop due to some reason, you may have a hard time figuring out which widgets have already be modified, and go through the entire file again and make sure that all widgets were updated.

[ 240 ]

Chapter 7

Don’t get me wrong – the addition of the style painter is a welcome addition to Axure’s widget editing capabilities. It is great when creating quick drafts because it greatly reduces tedious repetitive formatting steps. But when it comes to maintaining the consistency of an application’s style guide, I recommend you consider the approach I propose in the following section.

Integrating with the Project Style Guide and CSS The following technique promises to provide substantial efficiencies and speed in our ability to adjust of wireframes and prototype to the visual design. Axure still does not support explicit integration of CSS files, but I predict we will see this in coming versions.

The Style Guide A style guide is an extensive document that is produced by the visual designer on the project. A typical guide should cover the following aspects of the visual design: • Branding: °°

The color palette: Listing the HEX values of all the major colors, including gradients.

°°

Application logo: Including the all the allowed instances and sizes of the logo on various pages and display rules.

°°

A template anatomy: Labeling of all the layout elements that make up the structure of each major page template of the application.

• Design Elements: °°

Typography: The fonts and the styling of fonts across the applications.Graphics: The rules and styling for buttons and icons, including size, order, margin and padding.

• Structural Elements: °°

Covers the styling and sizing rules for data grid tables, windows, lightboxes, alert, message and error boxes and finally, forms.The visual design guide should be the document of record for anything related to visual design. The style guide is accompanied with a CSS style sheet that translates many of the properties listed in the guide, into CSS classes and IDs. [ 241 ]


Some elements that are listed in the style guide, such as the details of the page anatomy, may also be covered in your UX documentation. Make sure to synchronize with the visual designer about the names and labels of various elements to avoid conflicting references.

Axure Custom Styles Currently Axure does not support explicit CSS integration either in the form of linking with external CSS files, or by creating the CSS internally. But it is getting close. We have covered a number of methods that are available, to quickly modify the visual style of widgets. But using the Style Painter or default widget styles have their limitations when you have to reflect the latest visual design in your prototype. Axure custom styles get as close as ever before, to emulating the usage and behavior of CSS. The feature is far from perfect, but I expect to see enhancements in upcoming updates. As is, you can still gain substantial efficiencies in the maintenance and change of widgets style, and conform with the project’s style guide and at least a portion of the CSS.

From Style Guide to Axure Custom Styles We will use primary and secondary buttons in our demonstration project to illustrate how this can be done. An actual style guide is likely to be delivered by the visual designer as a PDF document. Keep in mind the current version of CSS does not support color gradients. But lucky for us, Axure does. As a result, we can implement gradients in the prototype, and the developers will figure out how to apply it to the application. Below is a section of the project’s style guide as it would pertain to the buttons:

[ 242 ]

Chapter 7

Widget

State

Style Guide

Image

Primary Button

Default

Fill Gradation: Hex#: FF6600 bottom, to Hex#: FFCC00 top

A

Border-Width: 1px Border -Color: 99000 Font-Family: Ariel Font-Style: Normal Font-Weight: Normal Font-Size: 16px Color: Hex#: FFFFFF Text-Align: Center Padding-Left, Right: 12 px Padding Top, Bottom: 6 px Primary Button

Rollover

Fill Gradation: Hex#: FFCC00 bottom, to Hex#: FF6600 top Border Width: 1px Border -Color: FF0000 Font-Family: Ariel Font-Style: Normal Font-Weight: Bold FontSize: 16px Color: FFFFFF Text-Align: Center Padding-Left, Right: 12 px Padding Top, Bottom: 6 px

[ 243 ]

B


Widget

State

Style Guide

Image

Secondary Button

Default

Height = 32 px

C

Fill Gradation: Hex#: FF9900 bottom, to Hex#: FFCC99 top Border Width: 1px Border color: 99000 Font-Family: Ariel Font-Style: Normal Font-Weight: Normal FontSize: 14px Color: FFFFFF Text-Align: Center Padding-Left, Right: 12 px Padding Top, Bottom: 6 px Secondary Button

Rollover

Fill Gradation: Hex#: FF6600 bottom, to Hex#: FFCC00 top. Border Width: 1px Border color: FF0000 Font-Family: Ariel Font-Style: Normal Font-Weight: Bold FontSize: 14px Color: FFFFFF Text-Align: Center Padding-Left, Right: 12 px Padding Top, Bottom: 6 px

[ 244 ]

D

Chapter 7

There are a couple of reasons why I recommend using the style-guide, instead of the CSS document. • Style guides are lot easier for non developers to read, in comparison. Reading a CSS document is like reading code. Not a complicated code, but still, class and id names can be very obscure, and there may be other properties and writing conventions that typical UX designers may not be familiar with. • Often the CSS document will not be available for quite sometime. While the style guide is created and handed over by the visual designer, converting it into working CSS is typically performed by a developer. The activity may take place later in the development process.

The Manual Methods There are two prevalent methods to implement visual design in Axure. In both, Each button will include a default and rollover state, to which you apply the styling using the fill, line and font tools in the toolbar or widget properties pane: 1. Add the buttons to the project’s widget library. To use, make sure the library is loaded, and drag a button over to a wireframe. 2. Constructs each button a master within your prototype file. To use, drag the master over to a wireframe, and flatten it, in order to modify the text and apply resizing. When it comes to managing changes of the visual design in your prototype, the major drawback of both these approaches, is that once applied to a wireframe, you can no longer make a global change in any of the button’s visual properties. You will need to go over each wireframe and apply the changes manually, which is a tedious and time consuming process. [ 245 ]


The Automatic Method The proposed approach takes advantage of Axure’s Custom Style feature. The idea is to capture the visual properties of all the elements listed in the project’s style guide, as custom style, and from then on, use only these styles especially in masters. Flattening masters will not remove the widget’s link to the custom style. Consequently, updating the custom style, will instantly update the master, its instances and flattened instances. Let’s continue with the example above, but change our approach to constructing the primary and secondary buttons. 1. In the Masters pane, create a folder and label it Widget Library. 2. Create two masters. Label the first Primary Button, and the other Secondary Button. 3. Open Primary Button for editing. Use a Rounded Rectangle widget to create a button with a width of 32 pixels, according to the style guide. Type the label ‘Primary’ on the button. (A) 4. That’s it for now, as far as styling the master goes! 5. Click the Widget Style Editor icon on the toolbar (B), to open the Widget Style Editor Dialog (C), and switch to the Custom tab on the left hand pane (D). Initially, this column will be empty. 6. Click the Add icon (E) to create your first custom style, and label it ButtonPrimary-Default (F). You can use spaces and other characters to separate the words in the name of a custom style, I recommend getting used to maintaining compatibility with CSS guidelines. If you have and understand the project’s CSS document, you can use the class name used there. Otherwise, keep in mind the W3C’s CSS 2.1 guidelines: “In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.” (See http://www.w3.org/TR/CSS21/syndata.html)

7. The style properties listed in the Widget Style Editor match the properties in your style guide, as well as the standard CSS syntax: Axure Widget Style Editor

Style Guide/CSS Syntax

Font

Font-Family

Font Size

Font-Size [ 246 ]

Chapter 7

Bold

Font-Weight

Italic

Font-Style

Underline

Text-Decoration

Alignment

Text-Align

Vert Align

Vertical-Align

Left Pad

Padding-Left

Top Pad

Padding-Top

Right Pad

Padding-Right

Bottom Pad

Padding-Bottom

Line Spacing

Line-Height

Font Color

Color

Fill Color

Background-Color

Line Color

Border-Color

Line Width

Border-Width

Line Style

Border-Style

Go through the relevant properties of the Apply the relevant styles: Font-Family: Ariel Font-Size: 16px Font-Weight: Normal Font-Style: Normal Text-Align: Center Padding-Left, Right: 12 px Padding Top, Bottom: 6 px Color: Hex#: FFFFFF Fill Gradation: Hex#: FF6600 bottom, to Hex#: FFCC00 top Border –Color HEX#: 99000 Border-Width: 1px 8. After you capture all the properties for the style (G), click the OK button to dismiss the Widget Style Editor. Remember to save the file, as a habit. Back on the Primary button master, comes the really cool part, with two options to apply the custom style to the widget: 9. Option 1. Click to select the widget the droplist (H) to the left of the Widget Style Editor icon. This droplist now lists the new style you just added: Button-Primary-Default. Select this value, and see your widget change to the that style! (K) [ 247 ]


10. Option 2: In the Widgets Properties pane, switch to the Formatting tab (I). The Style droplist also appears in the Style section there (J). The button will change to match the selected custom style (K).

[ 248 ]

Chapter 7

This, in a nut shell, is the method. Continue to add the other styles and build a custom styles library. As long as you style your widget using custom styles, you will be able to respond to changes in the style guide very quickly.In fact, you can start your custom style library fairly early in the design process. Suppose you want to start, as many practitioners do, with a grayscale palette. You can still define custom styles. When the actual style guide is provided, all you need to do is update the custom styles. This can save days of tedious manual updates.And a final benefit, when using masters. For the sake of illustrating the benefit, create a b such as the buttons in our example: 1. Create a new page in your file, and label it Sandbox Page (A). I find that, in addition to using Axure sandbox files to quickly test ideas in isolation from the entire project file, it is convenient to have a sandbox page in the file, for some quick tests and explorations. 2. Drag over the Primary Button master (B) and place it on the page (C). Notice that the Widget Style drop list on the toolbar (D) is disabled. That’s because changes to the styles are at the master level, not the page the master instance is placed on.Because you need to change the button’s label from “Primary” to “Move to Cart”, you need to flatten the master. Right-click the widget, and select the Flatten option (E) from the Masters menu. 3. The link that the master instance had to the master ‘mother ship’ has been severed. The button is no longer a master. You can edit the button’s label (F). This is identical to the way Axure handles widgets that are dragged over from a custom widget library. 4. But most importantly, and a significant benefit over widget libraries, is that although the master has been flattens, the widget is still associated with the custom style: Notice that the Widget Style drop list on the toolbar (G) is now enabled. Changes you make to the custom style when you update the master, will also update the widget that was based on the master well after the tie has been broken.

[ 249 ]


[ 250 ]

Chapter 7

To Sync or Not To Sync (with the Visual Design)? The issue, which is at the center of heated ideological debate, is, should wireframes, and the prototype incorporate the applications’ visual design? From a practical point of view, it does not really matter what the ideology is, if the client demands to see the prototype skinned about the topic. This is not Keeping in sync with changes to visual design can be a massive challenge. Often, the style guide is delivered before the design work is completed.

Change Control Question to reviewers: Are you interested in a more in-depth discussion on a methodology of using Axure in conjunction with a change control enterprise tool such as HP QC and others?Summary In this chapter we discussed the challenges that most UX practitioners face, when it comes to managing changes to the prototype. Many of these challenges have nothing to do with Axure. They are associated with the larger domain of software development, and the evolving integration of UX into various development methodologies. Additionally, change is inherent to UX. Consequently, it is in our best interest to figure out how to avoid the most tedious, time consuming chores that typically involve tweaks of layout and visual design.Axure provides a number of features that support change on a global level. Some are common to many applications, such as Find and Replace that help you modify text strings in the prototype, or the powerful, and still evolving Custom Styles. There are time-saving methods you should consider, such as using guides and grids, which will simplify the construction of your wireframes.The key to successful change, however, is managed expectations. You should assume that the stakeholders you work with and for, have no idea what is involved in your work. Your ability to estimate the level of wireframing and prototyping effort, should be combined with your ability to educate and articulate what’s involved in your work.

[ 251 ]

Functional Specifications If your deliverables for the projects include the UI functional specifications document, and there are only a few takeaways you get of this chapter, they should be: • Seek the development team’s input and approval on the format and scope of the specifications, as early in the project as possible. • Estimate early and correctly the effort involved with creating and generating the specifications. • Start planning and testing the specifications when you start your Axure file, and continue testing and tweaking the output throughout the project. The tendency to postpone dealing with the specifications until later in the project, is natural. After all, the document is typically due at the conclusion of UX activities for the project, and other, more pressing tasks on the UX plate take priority. Consequently, the UI specifications document is a bit like the iceberg that sunk the Titanic: It is big, mostly hidden, and if you don’t watch for it, it will hit you when you think all is going great. Axure provides an integrated specification creation and output environment. This feature addresses the iceberg nature of specifications head-on, in that it significantly reduces the labor and time involved in updating and producing the UI functional specifications deliverable. In other words, it translates to real value for UX practitioners who use the tool. The capability has been prominent on the long list of Axure’s ground-breaking features since release one back in 2004, and helped propel the tool’s popularity within the UX industry.To understand why, it is important to recall the workflow when using a non-integrated tool such as Visio. This flow was the de-facto practice just a few years ago: 1. Create first draft of the specifications: 2. Create wireframe in Visio.

Functional Specifications

3. Add annotation footnotes to the wireframe. This is a manual process: A footnote shape needs to be created, sized and formatted, then duplicated and renumbered, for each annotation footnote on the wireframe. 4. Create the UI specification document in MS Word. 5. Take a screen-capture of the wireframe.Label the captured wireframe such that you can recall later where it belongs in the specifications document. 6. Save the captured wireframe in the appropriate directory. 7. Import the captured wireframe into the Word document. 8. Write the annotations for the captured wireframe in the Word document, typically, in a table above of below the image. 9. Update and maintainthe specifications 10. In Vision, reorder and re-number annotation footnotes: This is often required due to iteration and updates applied to the wireframe since the first draft has been captured. Consequently, new annotation footnotes are added, and depending on their position, renumbering of existing footnotes is needed to maintain orderly sequence of top left to bottom right. This is a manual process. 11. Take a screen capture of the updated wireframe. 12. Label the capture: If you wish to maintain a new version of the previous capture for that wireframe (wise tactic), your naming convention for screen captures should also consider a serial version id, or date. 13. Save the capturein the appropriate directory. 14. Open the specifications Word document. 15. Find the appropriate section in the Word document. 16. Replace the previous capture with the updated capture. 17. Update the annotation table. You have to make sure that the footnote numbers in the wireframe match the sequence and numbers of table rows. You might think that I’ve deliberately bloated and exaggerated the list above, and if you do, you are absolutely correct. Each step in this workflow is manual, and often painstakingly so. Each step translates to seconds and minutes which add up to hours and days, since the entire process needs to be repeated for each wireframe included in the specifications. For medium and large projects, we may be looking at tens of screenshots. You do the math. And to make things even more complicated, coordinating the work among a team of UX designers can be a real challenge.

[ 254 ]

Chapter 8

Axure removes a great deal of the manual labor out of the workflow involved in the production of the specifications document, which translates to significant time and effort savings. In recent years, the landscape of UX prototyping tools has flourished with abundance of new products, and many offer integrated specification environments. However, as you will see, while most of the manual work has been removed, generating meaningful, comprehensive specifications is still time consuming, and is not a trivial effort. In this chapter, we cover the nuts and bolts of specifications creation and output process, and review best practices that will help you streamline the production of this deliverable into the complete, high-value deliverable.

Collaboration with the Development Team Let’s face it. Much of the UX work on the project is throw-away. For a brief moment in the development life-cycle, UX is bathing in the limelight: The creativity invested into conceptualizing the new user experience, the intensity of joint iteration and change cycles, the excitement of validating the interactive prototype with decisionmakers, stakeholders and end users. At the end of the day; however, developers need to translate the prototype into a fully functional application. The UI functional specifications is the document that binds the visualizations we’ve created throughout the project—the wireframes and prototype—with the technical details of the user interface.There are a couple of well-worn truisms that illustrate why the interactive prototype and the functional specifications document complement each other so well: The first is that “no one reads anymore”. In software, this is expressed pointedly by the famous abbreviation “RTDM”—“Read the Damm Manual”—which nobody ever does. This is true not only to consumers of software, but also to those who make it. Typical software projects generate an obscene amount of internal documents. Many of those that you are not responsible for authoring, you are expected to review and comment on. When crunch time sets in, even the best intentioned team member will find it impossible to read carefully AND to do their work.When it comes to UX-generated documents, the specifications document can be a substantial tome. This is where the adage “A picture is worth a thousand words” comes to play: Visualizing the intended interaction of rich Internet application is a significant time saver: The UX designer is spared having to write long descriptive verbiage, annotate multiple screenshots, and managing the updates. The developer can see the indented experience in an unambiguous way instead of following text aided only with static wireframe screenshots.In chapter 7, we reviewed various development methodologies, and their impact on the user experience track.

[ 255 ]


Although typically, UX has little influence over the choice and practice of the particular development methodology on the project, I emphasize the importance of communicating early with the development team, in order to align the work on the user experience, with the larger road map for the application. Very broadly speaking, UX practitioners, regardless of their employment model, whether consultants or in-house resources, find themselves in a flavor of one of the following situations: 1. Business ‘owns’ UX. In this setup, the UX team is most likely to be external to the firm, parachuted in to solve the particular need and is dismissed at the end of the engagement. The drivers for engagement are almost always strategic: Response competitive pressure, desire for market leadership, new product initiative and so on. There is some risk of possible friction with the development team over methodologies, approach and deliverables, but also an opportunity to influence a real change.Development ‘owns’ UX. In this setup, the UX team is part of the technology group. The UX team is more likely to be made of internal resources that are in better sync with the group’s goals and methodologies. The risk here, however, is that UX may be less inclined to propose bold new ideas that conflict with the goals and constraints of the development team, and resist change demanded by the business. Both scenarios are not ideal for UX, because the reposting structure places UX under the umbrella of one side of the organization, business or technology, and potentially, in a built-in conflict with other side. We know that UX is the glue that unifies a project’s wants and the need, the vision and the constraints. Ideally, UX would enjoy a reporting structure that would effectively provide it with both influence and independence across the entire business. But this situation may be too rare, and until then, remember that one of the most important factors for UX success, involves building solid relationships with all stakeholders on the project. A spirit of collaboration and communication leads to trust, and helps avoid problems down the road. Because the development team is the primary consumer of the functional specifications, achieving agreement on the format and scope of the document, has an impact on how you will construct your Axure file.Align Expectations The development team is typically the primary target audience for the UI functional specifications document. To be successful with this deliverable, you need to apply the same approach as you would to voting in Chicago: Meet with development early and often to determine the format and scope of the document. It will be a big mistake to wait with the specifications just because the delivery comes much layer in the project plan: At that point, your Axure file has matured, evolved, and is practically finished, from a construction perspective. Adjustments may be difficult to make. [ 256 ]

Chapter 8

Here are some concrete steps that can pave the road for a successful partnership. These steps are important if you have never worked with the team before: 2. Meet with development very early on in the project to explicitly discuss the specifications document. 3. Ask to see example of specifications the development team has been using for other projects. Don’t be surprised if you will not get much in ways of examples, however.Demo Axure’s specifications features to the development team. There is a high probability that the tool will be an exotic unknown to the team, which may lead to initial resistance to Axure. Old habits die hard, and if the team is used to looking at Visio documents.Whatever hesitations the developers may originally have, it is likely that education and review of the various possibilities for generation specification will help you build a compelling case. 4. Discuss with the team the attributes and level of details they would like to see. Schedule a follow-up meeting in which you will present a draft of the specifications, with all the attribute fields, as agreed. 5. Tweak as needed. At the end of this process, you will have established a good working relationship with development, and have their buy-in for the specifications deliverable. While they may not be the only consumers of the document, they will be typically those who will sign off. Later in this chapter, we discuss the details of various annotation fields, and how to assess the impact of added annotation fields to your workload.

Capture UI specifications

As mentioned at the start of this chapter, Axure provides an integrated, configurable specifications capture and output environment. But by no means should you assume that the process of creating the specs involves filling in the annotation fields and hitting the ‘Generate’ button. You will get a document, for sure, but it may not be something you want to hand over to your development partners. A good specifications document should provide high level description of the user experience across the entire application, continue to cover the structure and behavior of the application’s various screens, and conclude with the behavior of various widgetsdown to button-level elements. In other words, the document’s underlying structure should be composed of: 1. Global aspects of the applications, using the word template that is part of the spec Generator.

[ 257 ]


2. Page level description, using Page Notes. 3. Widget level descriptions, using Field Annotations. The following sections will describe in detail how to customize the various elements to best fit the document you want to generate for your project.

Global Specifications

There is a great deal of information about the user experience that applies to the application at its entirety, and the first part of the specifications should cover the principals, considerations and activities that led to the application that is prescribed in the specs. Also, keep in mind that readers of the specifications may not be fully versed in the nuts and bolts of UX. Concepts and terminology. No all the items listed below may be relevant to any given project, but in some configuration or another, these apply to any UX project: • Introduction: Purpose and target audience: What is this document, and who is it written for. • Guidelines and principles: • Screen Resolution • Devices support • Handling Date and time • Fonts • Colors • Browser support • Performance: The acceptable response time for various interactions, from a UX perspective • Error handling • User Assistance and guidance • Handling security • User Customization features • Localization features • ADA compliance • Interface Layouts • Key Patterns (samples): • Windows and dialogs [ 258 ]

Chapter 8

• Notifications • Error messages • Warnings message • Confirmation message • Informational messages • Miscellaneous • Calendars • Sign In • The Naming convention • Glossary of Axure terminology: What are masters, dynamic panels and so onDocument Control • Document versioning • Related document • Reviewers list • Approvers list It may be tempting to consider composing this section in Axure. After all, we are talking about test, screen captures, some tables, and formatted text, right? Well, remember that if you try to compose this on an Axure page, the output will be an image. That’s because the content of Axure’s pages, master and states, which you edit in the Wireframe pane, will be generated as screen captures of the application, in the Word output file. While this is an option for some type of information that you may want to keep within Axure, you really need a word processor to author and format this section effectively.

Generators and Outputs: Specifications and Prototypes Before we dive into the details of capturing the project’s global specifications, let’s clarify the relationship between Axure’s generators, specifications and prototype. Prototype: This always refers to an HTML output of your Axure file. Whenever you click the Prototype button (A) on the toolbar, you are presented with the Generate Prototype dialog (D). In the dialog you can specify various options of the default HTML output generator. You cancreate multiple HTML outputs, each tailored for a specific need – if you have such needs. The HTML prototype generates the contents of the pages in your sitemap. This means that, once you have some wireframes, you can start viewing your prototype in HTML. [ 259 ]


• Specification: This always refers to a formatted Word output of the Axure file. Whenever you click the Specification button (B) on the toolbar, you are presented with the Generate Specification dialog (E). In this dialog you determine the format and output options of thedefault Word output generator. Like the HTML output, you can create multiple Word generator for specific needs, which we will discuss in this chapter. As opposed to the HTML output, for the specifications to be meaningful, you need to annotate the wireframes: Pages, masters, dynamic panels, and widgets, which means that the effort involved in generating specifications extends will beyond the configuration of a generator. But more about this later in this chapter. • Generators: A generator is an output template. Axure provides three output options: HTML, Word, and CSV. Out of the box, Axure comes with one generator of each type. When you click the Generators button (C) on the toolbar, you are presented withthe Generator Configuration dialog (F), which lists all the generators you currently have in your project file (G). There, you can manage your generator collection (H): • Create new generators in one of the output formats • Edit a generator • Duplicate an existing generator • Delete generatorsSet the default generator for the HTML and Word outputs

[ 260 ]

Chapter 8

Why would you need multiple generators? Consider the following examples: • You may want to generate an HTML version with the footnotes visible, and another with the footnotes hidden. When you meet with stakeholders, you can have both versions available, and switch between one that is visually clean, and the other, which provides descriptive details about various elements of the interface. • For large projects, you may want to generate the HTML of only of subset of pages, the ones you are currently working on, in order to speed up the HTML generation.For large projects, you may want to divide the Word output into chapters, each corresponding to a workstream, or an application module. This works well when there are different stakeholders and development teams for each module or workstream. Each can review and respond to the relevant portion of the specs. [ 261 ]


Customizing the Word Specifications Generator

Let’s start with the first Word generator for the project. Although you can use the provided generator, I’d recommend creating a dedicated generator, and leave this one for experimentations. (See illustration 02 to follow the flow below) 1. Click the Generators icon (A) on the toolbar. Alternatively, select Specifications… from the Generate menu. 2. In the Generator Configuration dialog (B), select the Word Specification option (D) from the Add droplist (C). 3. Rename the new generator as relevant.Click the Set as Default button (E); the default generator is the one that is launched when you press the Generator icon on the toolbar. 4. Now you can click the Edit and generate icon (G), which will launch the Generate Prototype dialog. There you will set the various properties that determine the final output of the Word specification. We will cover this dialog in detail later in this chapter.

[ 262 ]

Chapter 8

Now that you understand the relationship between generators, specifications, and have a Word generator waiting to be configured, it is time to dive into the mechanics of capturing the specifications.

Page Notes Axure’s Page Notes provide the mechanics for capturing page-level description and other specifications. This is the place to provide: • High-level overview of the page • What can the user accomplish on this page • Important user experience principles • Key interface componentsOut-of-the-box, Axure provides a single page notes field called Default, which you probably should rename. You can add additional note fields, which will help you provide an organizational structure to the page note section in the specification. For example, you can consider adding notes for discussing key business requirements that are addressed by this page, functional specifications, localization and personalization notes and so on. Although the section is called Page Notes, you can use it for pages and masters.

The page notes you create in the file are available to all pages, although this does not mean that you have to fill all the notes sections on all pages. To customize the notes section: (follow illustration _03 for the flow below). 1. Open the page for editing (A) on the Wireframes pane. 2. Click the Page Notes tab (B) in the Page Properties pane. 3. You will see the Default note field (C) listed in the droplist.A good reason to rename this field is that you will have an option to use the note name as a header, in the specification document. Obviously, to the reader the word ‘Default’ will be somewhat vague.To rename the name of the note field, click the Manage Notes… link (D). 4. In the Page Notes dialog (E) that appears, click on the first item (F), and type the new note field name. For example, ‘UX Description’. 5. To add additional note fields, click the Add icon (G). Consider carefully the note fields you are adding: 6. Is the section going to be applicable to the majority of pages? 7. Who is the audience of this note? Developers or business people? [ 263 ]


8. It is a good idea to add a note field for you personal use (H) – a place to capture issues, ideas, questions for stakeholders and so on. You can generate a version of the specification that has only this field, which will provide you with a good issue management system. 9. Close the Page notes dialog when you are done adding the fields you need. You can always tweak this section, although, once you have started to capture information, be careful about deleting note fields. 10. From this point on, the renamed and new fields are listed in the drop list (I). Switch between fields using the droplist.

[ 264 ]

Chapter 8

One Note Section vs. Many In discussing this topic with colleagues, there seems to be an agreement that a lot depends on the nature of the project. As a result, there is no right or wrong answer here. However, evaluate your needs and approach in light of the folllowing: • Some developers are interested in very detailed specifications, while other want to focus only on the absolutely necessary details.The specifications may be consumed by a remote team, often overseas, and the developers will interpret your words verbatim, while in an Agile environment, the developers might barley read anything. • In some project the specifications are also going to be consumed and signedoff by business analysts, business stakeholders and other non-developers. Understand what they are looking to get from the documentation and tailor note field content for this audience. This will help getting their approval. • With multiple note fields, it is easy to make mistakes!Annotation Fields Think about a snapshot you take with your camera. The lens picks an incredible amount of details in addition to whatever was your intended subject and focus for the shot. Now compare this to a sketch you draw on a sheet of paper. Every single mark on that page is there because you placed it there. The analogy to a wireframe is that every element on a wireframe was place there for some reason – you started with a blank after all. Someone, a developer, will need to translate the wireframe to live code. In the UI functional specifications document you are expected to provide both descriptive and prescriptive information about any widget in a wireframe. We’ve discussed earlier in the chapter, the level of effort of manually creating the specifications. Axure takes care of many of the most labor intensive tasks and delivers profound time savings. Still, you must expect to spend significant amount of time on the specifications. After establishing your page notes, it is time to configure the annotation fields. Across the UX industry there is no standard for the UI specifications document. The deliverable’s format and depth of coverage depends on the practitioner, the tools used to generate the document, and what has been requested by the consumers of the document. Axure comes with a set of nine annotation fields. Some of these fields you will want to rename, or remove. You can easily add your own fields, and customize both their label and type. Annotation field types are: • Text • Select List [ 265 ]


• Number • Date Each UX project may be vastly different, but one can argue that across the board, there are generalized properties that can, and are applicable to any interface project. Now, I recognize that user experience is rapidly evolving and we need to address new interaction methods such as gestures and haptic feedback. This evolution is likely to expand the type of annotation fields, and information that has to be captured in the specifications. Below are listings of annotation fields. Those that come out-of-the-box, and ideas for those you could use in practice: #

Out of the Box

Possible

Minimal

1

Label (Built-In)

Widget ID (Built-In)

ID (Built-In)

2

Description (Text)

UX Description

UX Description

3

Status (Select List)

Widget Type

Behavior and Display Rules

4

Benefit (Select List)

Behavior

Type

5

Effort (Text)

Display Rules

Exceptions

6

Risk (Select List)

Required/Mandatory

Default Value

7

Stability (Text)

Exceptions

8

Target Release (Text)

Default Value

9

Assigned To (Text)

BRD Reference

10

Validation and Errors

11

Sort Order

12

Dependencies

13

Persistence

14

Content source

Is it possible to have a widely accepted ‘minimal’ set of fields that would work across most UX projects? It is a compelling possibility that could help achieve some level of standardization for the UX specifications delivery. Luke Perman pointed me to the AXLIB open source library that uses a set of ten fields, many of which have pre-set It is highly recommended that you firm up the list of annotation fields before you actually begin writing your annotations. To customize your collection of annotation fields: (see illustration _04) 1. From the Wireframe menu (A) select the Customize Annotations Fields and Views… option (B). [ 266 ]

Chapter 8

2. The Customize Fields and Views window (C) will appear, listing Axure’s out-of-the-box fields in the Customize Fields column (D). 3. To rename a field (E), click it, and type the new label. While you can change the label of the annotation field, you will not be able to change its type. (F) 4. If the field happens to be a Select List type field, the current values are listed in the Edit: ‘Field Name’ column (G). You can easily modify, add and remove values by typing in that area. 5. To add new annotation fields of various types, reorder them in the list and delete fields, use the controls above the list of fields (H). I highly recommend that you delete fields you don’t plan to use.

Alternatively, you can customize your collection of annotation fields: (see illustration _05) 6. Switch to the Annotations tab (A) in the Annotation Properties pane. 7. Axure’s ‘Out-of-the-box’ list of fields (B) is displayed in in the pane, initially disabled. Once you select a widget (C) in your wireframe pane, the annotation fields become active and you can type your annotations or select a value from a list.

[ 267 ]


8. To customize the list of fields, click the Customize link (D) to open up the Customize Fields and Views dialog (E). The dialog will be set to the Fields tab (F). 9. To add a new field to the list, click the Add droplist (G). you will have to decide what type the field will be, from the list of options (H). You will not be able to change the field type once the field is created. If you selected the wrong type, delete the field, and create a new one of the type you need. 10. The new field will be added at the bottom of the list (I). Make sure to rename all your fields in a meaningful way so that the reader understands what to expect there. Try to keep the labels concise – ideally, a single word: The output of the annotation fields is in tables, where each field label is a column header. 11. The Clear All function (J) is very handy for copy-paste situations. This is a common scenario: Well after you start annotating your widgets, you are likely to copy widgets either for use in the same wireframe, or on other areas of the prototype. Since the pasted widget inherits the contents of the annotations field, make sure to clear them if the information is not relevant for the pasted widget. Do this immediately after pasting, to avoid grief later in the project, when irrelevant information will appear all over the specification, potentially confusing reviewers and developers who consume the document.

[ 268 ]

Chapter 8

Annotation Views Annotations views is a feature that allows you to group your annotation fields. This is useful if you have a long list of fields, and want to organize them in smaller groups. For example, you may decide, together with your development team stakeholders, on a subset of fields that are mandatory, and the rest are optional. By setting your Annotation tab to the Mandatory view, the much shorter list of fields will be easier to scan as you go over your widgets and ensure that all mandatory information has been captured. To setup your views: (see illustration _06 below) 1. When you open the Customize Fields and Views window, the Fields tab (A) is selected by default and all the fields in your file are listed (B) in the Customize Fields column. All these fields appear when you switch to the Annotations tab in the Widget Properties pane (C). 2. When you initially switch to the Views tab (D), the Customize Views column (E) will be empty, because you still do not have any custom views. [ 269 ]


3. Click the Add icon (F) to add the first view and label it. For example, Mandatory. 4. In the Fields in Mandatory column, Axure makes this a contextual label, so it always references the selected view you have on the Customize Views column. 5. Use the droplist Add (G) to select the fields that will be part of the Mandatory view.Repeat this process whenever you want to manage your views. Close the window when you are finished. 6. Now, the view droplist in the Widget Properties pane shows your new views. Now, only the fields you need are displayed (I and J, in our example). You always have the option to view all fields.

[ 270 ]

Chapter 8

Specifications and Construction Methods iFrame vs dynamic panels Ghosts in the machine Change control

Generate Specifications

As mentioned throughout this chapter, it is important to experiment and test the output of the specifications early and often. You control all the output properties of the specification document in the Generate Specifications window. The window is divided into eight sections, and when you are done tweaking them, and press the Generate button, Axure will launch Microsoft Word which will open with the specification document ready for your review and edit.

The General Section In the first section (A) ((see illustration _07 below), you instruct Axure about two things: 1. Where you want to create the generated specifications. By default, the path (B) leads to the Specifications directory (C) that is created when you install Axure. This directory is located under the ‘My Documents’ folder, if you are using a PC, or in the Documents folder, if you using the Mac version. Use the Ellipsis button (D) to change the path to your own destination. For example, if you want to store the document in a special folder you have for all you project’s files. You can always use the default by clicking the Use Default button (E). 2. The name of the specifications document. By default, it is the name of your Axure prototype file.

[ 271 ]


The Pages Section In this section (A) you select which pages from the prototype’s sitemap will appear in the specifications. (See illustration _07 below) Option

Description

Include Pages Section (B)

This option supersedes the rest of the items below. If you uncheck this option, none of the pages in the sitemap will be generated.

[ 272 ]

Chapter 8

Option

Description

Section Header (C)

You can customize the name of the pages section. For example, instead of Pages, you may want to call the label ‘Screens’. If you check this option, don’t leave it blank. This label will appear in the Table of Contents of the generated specifications.

Include Sitemap List (D)

If you check this option, Axure will include a list of all the pages in your project’s sitemap. Keep in mind, however, that if you choose to generate some of the pages, the list will still show all of them, which may be confusing to the reader.

Sitemap Header (E)

You can re-label the default sitemap header from Page Tree to Application Screens, for example. If you check this option, don’t leave it blank. Your custom label, or the default, will appear in the generated Word document.

Generate All Pages (F)

By default, this option is checked. As mentioned earlier, it is most likely that you will want to uncheck it, however. The ability to segment pages is extremely useful. Not only can you have precision and select just the relevant screen you want to include in the spec, it opens up the possibilities to generate chapters and sections that are tailored for specific audiences. In large project, each work stream can generate its own set of specification. Useful in large projects with many pages and sub pages, is Axure controls to Check All, Uncheck All, Check All Children and Uncheck All Children (G)

[ 273 ]


The Masters Section In this section (A) you select which masters from the prototype’s sitemap will appear in the specifications, and how they will appear. (see illustration _09 below)

[ 274 ]

Chapter 8 Option

Description

Include Masters Section (B)

This option supersedes the rest of the items below. If you uncheck this option, none of the masters in the prototype will be generated. This can be useful if you want to create, for example, a Power Point presentation showing only key screens of the applications. Instead of manually taking screen captures of each from the HTML prototype, you can generate a specification of only the pages you need, and exclude the masters. All the screenshots you need for the presentation will be automatically generated, faster.

Section Header (C)

You can customize the name of the masters section. For example, instead of the default ‘Masters’, a terms which will expose readers who are not familiar with Axure’s terminology, you may want to call the label ‘Reusable UI elements’. If you stay with ‘Masters’ it is a good idea to aIf you check this option, don’t leave it blank. This label will appear in the Table of Contents of the generated specifications.

Include Master List (D)

If you check this option, Axure will include a list of all the masters in your project.

(E)

Master List Header

Only List Generated Masters (F)

You can re-label the default master list header from Page Tree to ‘List of Reusable Components’, for example. If you check this option, don’t leave it blank. Your custom label, or the default, will appear in the generated Word document. By default, this option is checked, and I recommend leaving it check – there is little value in listing items that do not appear in the document. Useful in large projects with many master, is Axure’s controls to Check All, Uncheck All, Check All Children and Uncheck All Children (H).

Generate All Masters (G)

By default this option is checked, and, kept checked, will generate all the masters in your file. You should consider unchecking it, especially if you are tweaking which pages will be generated. Typically, your file may include old version of pages and masters, various design candidates and even work in progress – there can be actually quite a bit of stuff you want to keep out of the specs.

Only Generate Masters Used on Generated Pages (I)

By default, this option is not selected, but I recommend you consider checking it, especially if you are generating only a subset of pages. Remember – masters are not independent elements – they are reused in one or more pages. If a master does not appear in the pages that are generated in the spec, it will make little sense.

Do Not Generate Masters Set As Custom Widgets (J)

Masters that are set as custom widgets are typically intended to be modified once they are placed on the page. This means that a Master set as a custom widget will actually not be easily recognizable as such, on the page. As a result, it will not be very valuable to the developers, and most likely create some confusion.

[ 275 ]

Functional Specifications Option

Description

Document Masters in Page Section (K)

By default, Axure generates the Masters section after the Pages section. The table of content looks like this: Page Section

Page 1 Page 2

Page n

Masters Section

Master 1 Master 2

Master n

This means that a developer working on a particular page, needs to jump from the page to the masters section and located a master mentioned in the page section - which can be inconvenient and sometimes – confusion, since not all the elements associated with a single page are in one place. By checking this option, Axure will generate the page with its associated master/s The table of content looks like this: Page Section Page 1 Page 2

Master 1 Master 2 Master 1 Master n

Page n

Master 1

Master 2 Master n

This organization packages all the information about a screen in one section.

[ 276 ]

Chapter 8 Option

Description

(L)

Only Document First Use

If you checked the previous option, one immediate downside will be a redundancy of masters – basically, each master will repeat on each page it is used on. Depending on the size and the project and the construction of your prototype, this redundancy may translate to hundreds of extra pages in your specification document – I am not exaggerating here. So – the option to generate only the first instance of a master – under the first page it is used on, can be a tremendous space saver. However, it does end up intensifying the original problem of spreading masters in the document, because this arrangement forces the reader to potentially hunt for masters all over the document.

Exclude Master Notes (M)

Like pages, you can add notes to masters. This is a very useful feature, especially if the master is a large, composite component that can benefit from its own set of notes. However – you do have an option to exclude those notes.

[ 277 ]


The Page Properties Section Axure’s 6 has significantly improved controls over how the organization and content of the functional specifications document. In the Pages section you selected which pages from the sitemap will be generated in the specifications, and here, in the Page Properties section (A), you offered a wealth of fourteen options to configure page information. These options will apply to all the pages in the sitemap. (see illustration _10 below) Option

Description

Include Notes (B)

With this option selected, page notes will be generated for each of the pages.

Show Notes Names as Headers (C)

As discussed earlier in the chapters, you can create multiple note fields. With this option selected, these note names will appear as headers, and the content of the notes below

Use Heading Basic Style(D)

If you checked the previous option, this option will become active. It is uncheck, and the style Heading 3 will be applied, giving page notes significant prominence. If you check the box, the basic heading will be Heading 5, which is gray, smaller font, making notes less prominent.

Select and order the notes (E)

This option let you govern the order in which the page notes will be generated within each page.

Include Page Interactions (F)

With this option selected, OnPageLoad interactions will be generated. Whether or not Axure’s interactions provide any value to the developers, needs to be discussed with the development team.

If you do choose to include page interactions, you can use the default section header or relabel it.

Section Header (G)

Use Heading Basic Style (H)

Similar to D, you have the option of making the interaction section more or less prominent.

Include List of Masters Used on Page/Master (I)

Since it is impossible to visually distinguish masters by looking at the wireframe on a page (unless you take a special effort to identify them manually), developers will appreciate the listing of all the masters, which makes it easier to locate them in the masters section.

If you choose the option above, which is highly recommended, you can modify the default label – given that you may choose to reference masters using a different term, this is a good option.

Section Header (J)

[ 278 ]

Chapter 8

Include Master Usage Report (masters only) (K)

This too, is a very useful feature. Each master will have a listing of all its instances across the entire prototype. This is incredibly helpful.

Section Header (L)

This is similar to J.

Pages Header (M)

This is similar to J.

Masters Header (N)

Include Dynamic Panels (O)

This is similar to J. If you are using dynamic panel in your prototype, you are likely to want to have this option checked in order to expose the various states associated with those dynamic panels.

[ 279 ]


The Screenshot Section One of the great timesaving features involved in producing the functional specifications document – automatic generation all wireframes screenshots. This means that each time you generate a fresh version of the specifications, your screen captures are up to date! Not only that, but the annotation footnotes will be created as well. The Screenshot section (A) in Axure 6 provides a wealth of screenshot customization options: (see illustration _11 below) Option

Description

Include Screenshot (B)

This option supersedes the rest of the items below. If you uncheck this option, none of the screenshots in the prototype will be generated. It is difficult to think about a situation in which you might not want to include screenshots, however.

You can modify the label of this section, for example, change the default ‘Screenshot’, to ‘Wireframe’.

Screenshot Header (C)

Show footnotes on screenshot (D)

With this option selected, the screenshots will include the little yellow numbered footnotes that reference annotated elements on the wireframe. You are most likely to want to have this option selected for the specifications document. But if you need to generate a set of wireframes to include in a PowerPoint presentation, the footnotes option can be skipped.

Exclude footnotes not in widget tables (E)

We discuss widget tables in the Widget Properties section, which comes up next. Basically, the idea is that you may have more annotation fields in your Axure file, that fields that you want to output. You organize the fields in widget table/s. With this option checked, footnotes that are associated with fields that are not part the widget tables, will not be generated. For example, you may have a field to capture internal issues, questions and other miscellaneous details. Typing content in this field will create a footnote on the wireframe. But – since you are not going to include this field in the widget table/s you don’t want the footnote to appear. This option takes care of the situation.

(F)

Put border on screenshot This option does exactly what it claims. However, you may want to consider if you want to use it – It might confuse the developer to think that perhaps the border is part of the wireframe – since visually it might be difficult to distinguish the Axure added border, from a frame around the widget. Something to keep in mind.

[ 280 ]

Chapter 8

Option with

Description Do not scale footnotes screenshot (G)

With this option, the size of the yellow footnotes stays constant.

Apply default OnPageLoad cases (H)

This may be an important option to check – There are many circumstances where the rendering of the page depends on the execution of the OnPageLoad event. This works well in the interactive prototype, but also, as importantly – happens when the specification is being generated.

Include Submenu (I)

This option will generate screenshots of expended menus – if you use Axure’s menu widgets in your prototype.

Include Expand Trees (J)

This option will generate screenshots of expended trees – if you use Axure’s Tree widgets in your prototype.

Show default pages in inline frames (K)

This is an incredibly important option to check if you load pages inside iFrames on other pages – it will insure that the entire wireframe – the parent page as well as the page that is targeted for the iFrame, will be generated.

Do not apply background styles (L)

If you use background effect for the prototype, for example, apply background colors, you can have these removed from the screenshot output.

Do not apply sketch effects (M)

Just what it means – while you can maintain the option of sketch effects on your prototype, you can choose to remove them from the output.

Max Width as % of Page/Column Width (N)

This option provides a measure of control over the width of the screenshot, in relation to the output page. For example, 60% of the a 7.5” width for a Letter size page set to Portrait (with half an inch margins to the left and right), we generate a screenshot that is 4.5” wide, leaving a 3” space for annotation information. Keep in mind, however, that in a typical project, the variation between wireframes is significant, and you’ll want to experiment and ensure the quality of the output.

Page

Similar to the section above, but control the max height of the screenshot. This is useful for long, scrolling screens. Keep in mind, however, that in a typical project, the variation between wireframes is significant, and you’ll want to experiment and ensure the quality of the output.

Max Height as % of Height (O)

[ 281 ]


Option

Description

Allow screenshots to split across pages (single column only)

This option is useful for very tall screenshots. If you limit the height of the image so that it fits onto the page, you will, by default, also reduce its width, potentially making it difficult to identify details. Bu splitting the screen capture across screens, you can keep the maximum width for best quality, without worrying about the height.

The Widget Properties Section We discussed in the first part of this chapter the macro and micro means to capture annotation in Axure. The Page Note fields are the macro option, a configurable space that allow you to discuss an entire page and provide the UX overview and context. The Widget Annotation fields are the micro option, allowing you to capture the UX properties of widget level controls.The Widget Properties section (A), provides [ 282 ]

Chapter 8

you with a number of controls that help you organize the presentation of widget annotations in the specifications document. (see illustration _12 below) Option

Description

Include Widget Tables (B)

This option supersedes the rest of the items below. If unchecked, none of the widget annotations will be generated. Axure lets you create any number of widget tables. Click the Add link (J)

You can change the label of this section. For example, if you add an additional table, the first can be labeled ‘Mandatory Annotations’ (K) and the second table, ‘Optional Annotations’ (M). you can switch between the table using the widget table droplist (L)

Table Header (C)

Select and order the columns (D)

All the widget annotation fields in your file are listed here. Each field is a column in the table. Obviously, the more fields, the narrow each table column. Axure provides an easy and powerful method to avoid the problem by allowing you to associate fields with multiple tables. As a result, each table has fewer, wider columns, and the result is readable and clear. Within each table you can control the order of the column, which will be their order in the widget tables.

with

This option will reduce unnecessary clatter from the specification, listing only widgets that actually have footnotes.

Only include widgets footnotes (E)

Remove rows with only This is a great space saving option that will filter Footnotes and Label data (F) out widget that have footnotes, but have no actual annotations.

Filter drop lists (G)

(I)

Remove empty columns Another space saver

(J)

Column Heading Label

Allow Rows to Break Across Pages (K)

The filter option is new to Axure 6. Expand in draft 2

Another space saver which will eliminate empty columns from tables, and by that increasing the width of column with data. This is a self-explanatory option, although you want to discuss with the developers – they may prefer to see the entire row in one place and avoid a potential error in case the developer missed the continued row.

[ 283 ]


The Layout Section The layout section (A) provides additional controls over the page layout of the specifications document. (see illustration _13 below) Option

Description

Columns (B)

You have a choice of a single column or two column layout. Keep in mind that in a two column layout the screenshots may be too small for an application page. However, if these are specification for an iPhone app, for example, this may be a perfect, compact format.

Order the content (C)

You can set the order of appearance of major content section in the specification. Use the up and down arrows (D) to organize the sections. [ 284 ]

Chapter 8

The Word Template Section Finally, the Word Template section (A), the last on the Generate Specification dialog. When you hit the Generate button on this dialog, Axure gets a Word template to open, with all the content organized per your selection in the previous sections. This panel provides you with access to edit the word template, import a template or create your own. (see illustration _14 below) Option

Description

Edit, Import, New Template (B)

These links allow you to edit the provided Word template, import a new template or create your own.

Applied Word Styles (D)

You can modify the default style names, if you want. You also have the option to use Word’s built-in styles instead. You will have to experiment and determine which you like better.

[ 285 ]


Create New Template (E)

If you click the link Create New Template (B), a popup window with the same title will appear, with options to customize the template.

Paper Size (F)

Choose between US formats such as Legal, Letter, Ledger, and the international A4 format

Orientation

(G)

Choose between Portrait and Landscape orientation

Numbered Headings (H)

Choose to have numbered or non-numbered headings. Here we encounter an interesting challenge: While it can be difficult, or nearly impossible to reference sections in the specifications document without numbered headings, these headings will most likely change between drafts of the document. This is because you may tweak the output, add or remove content and so on. This is way it is impossible to relay on page numbers, because each generated spec might have a different page count, and elements may appear on different pages. Only a consistent and comprehensive naming convention scheme can help maintain a reference mechanism that is reliable. See Chapter 5.

Columns (I)

Choose between one or two columns page layout.

[ 286 ]

Chapter 8

[ 287 ]


Summary Regardless of the tool you are using, generating UI functional specifications is a complicated affair. Think about model toys: despite the fact that each piece is labeled or numbered, it can be difficult to figure out exactly how the complete model will look like once it is assembled. Similarly, the organization, context and associations between various user interface elements on a screen and across screens, can be easily ascertained when looking at the HTML prototype. But delivering a document that maintains these relationships is not trivial. Most dedicated prototyping tools currently available in the market, offer some form of integrated specifications. Following the evolution of this Axure featureover the years, and recognizing the increasing complexity of user interface projects, the nontriviality of the effort is clear. In this chapter we looked at the two efforts involved in producing the specifications – Capturing them, and configuring the generator to produce a valuable, a highly polished and easy to follow deliverable.Finally, I feel that is is really important to conclude this chapter with the three key takeaways with which I started: • Seek the development team’s input and approval on the format and scope of the specifications, as early in the project as possible. • Estimate early and correctly the effort involved with creating and generating the specifications. • Start planning and testing the specifications when you start your Axure file, and continue testing and tweaking the output throughout the project. The next and final chapter in this book deals with Axure’s collaboration capabilities. Even if you are a ‘lone wolf’—an independent UX practitioner, your Axure skills are quickly becoming valuable as Axure’s establishes itself as the de-facto prototyping tool in the market. Familiarity with Axure’s shared project features will help you quickly join larger enterprise projects.

[ 288 ]

Collaboration Henry Ford once said that “Coming together is the beginning, staying together is progress and working together is success.” If you have some experience with UX projects that involve a team of UX designers, you can appreciate the challenge of “staying together”, or, in modern terms “staying in sync”. This has been, and continues to be an acute pain point for UX teams. There many good reasons for the difficulties. To begin with, a project has to be of a certain size and complexity, to warrant the extended investment an organization will have to make in a UX team. Each UX designer is usually assigned to one or several workstreams or modules, each with its dedicated business, and sometimes technology stakeholders. Add the constraints of tight schedule and budget, and you’ll end up in a fast paced environment with many a-synchronously moving parts. You may be in one of those right now. For a UX team that is using a traditional file-centric tool such as Visio, for example, an immediate concern is keeping wireframes in sync.Only one person can edit a Visio file at any given time, which means that each designer works on a separate file. To get a sense of the entire application, constant consolidation of the individual f files is needed. • The larger the team, the more accelerated the project velocity - the harder it is to manage the consistency of interaction patterns and widgets across the files each designer is working on. The UX team faces a similar challenge of collecting feedback from stakeholders. A common practice has each UX workstream, create PowerPoint presentations of the latest wireframes, add some verbiage describing the interactions and send out to stakeholders for written feedback. There are several drawbacks here: • Stakeholders need to respond to a static presentation of a dynamic interfaceRedundant, extra effort for the team, of creating the presentations

Collaboration

• A challenge to consolidating feedback from multiple stakeholder • A challenge of sharing the feedback with the other UX workstreams on a timely and on-going basisAxure 6 supports two forms of collaboration that help address major difficulties in both fronts mentioned above: 1. The Shared Project format, which enables a team of UX designers and others (BA’s, for example) to collaborate on the same project in real-time. 2. The Discussion tab in the HTML prototype, which facilitates review by stakeholder by enabling viewers of the html prototype to add comment for each page on the sitemap. Like other important Axure features, these capabilities translate to real time and effort savings for the UX team. For a UX team that is considering a prototyping tool that supports a collaborative environment, there are few other ‘industrial strength’ options at the price point and maturity offered by Axure. The Shared Project feature has been around since version 4.5, back in 2008. It is stable, reliable and is being continuously refined.The Discussion feature is new to Axure 6. It is an option integrated into the HTML prototype, where the entire team and stakeholders can share feedback and response to wireframe. Collaboration still continues to pose significant challenges, because it is the nature of the beast: Any project with many simultaneously-asynchronously moving parts is inherently a complex process to mange. This chapter focuses on Axure’s collaboration features, and the methods which will help you keep the UX team, stakeholders and prototype in sync.Shared Projects When you launch Axure, it always starts a new project, following the pattern of say, Microsoft Word. When you save the file, it will always be saved in the RP file format, which is Axure’s stand-alone format, which means that: 3. Only one person can access and work on the file at any given time. 4. Axure package the entire project in a single file which has the suffix .rp. For example, when you label a project My Project, and save it for the first time, you will find in the target directory, the Axure file My Project.rp. You can easily email that file to a colleague, much like you can send a PowerPoint or but – any work that person does on the file.You will have to convert an existing stand alone file (.RP) into a share project file (.RPPRJ). Once you do, the new project file will support collaborative work, version control and facilitated discussions on the html prototype.Even if you are a single practitioner, you might find it beneficial to create your Axure project using Shared projects. You will be able to work from your desktop and laptop computers, enjoy the peace of mind that comes from knowing that you can always revert to a previous revision of your work, and collect feedback from stake holders. [ 290 ]

Chapter 9

The Environment The Axure Shared Project environment is straight-forward. Illustration 1 depicts a typical setup. The project file is created on a server or shared directory (A). This is a done once, using the Create Shared Project from Current File… option. What’s on that central location, is in essence a repository of all the elements that make up the project – a very large collection of folders and files that are managed by the repository. It is highly advisable not to touch any of the files on the central repository, or on your local copy of the project. When a team member accesses the file for the first time using the Get and Open Shared Project… a local copy of the repository is created on the person’s computer (B) and (C). Each of the team members may be using a Mac or Windows machine, with the corresponding version of Axure. The only restriction is that, if the shared project was created with Axure 6, it cannot be opened by team members running version 5.x Each team member can check out any element of the prototype, including elements that are checked out to other team members. Elements subject to check-out and check-in are: • Pages • Masters • Annotation fields • Global Variables • Page Style sheet • Style sheet • Generators An important fact to remember is that each team member works on their own local copy, and not directly off the server. To edit files that are on the shared repository, each team member checks out a desired element (D) or (F). The icon for that element, on each person’s local copy, will display a green circle. As long as the element is checked out, other user will be prompted if they attempt to check out the item. Once done editing, team members check in the element (E) or (G), and it clears for editing by others.

[ 291 ]

Collaboration

Check out/in status Status

Description

Checked In

The element is available Blue diamond. for checkout to all team members. However, the status indicates only what the local copy ‘knows’. When you actually try to check out the file, Axure will let you know if it is available or not.

Checked Out

The element is checked out to you. The local copy of other team members will still display the file as checked in.

Green circle. The person who has the element checked out will see an indicator – in the form of an icon, or a label – mark its status. The local copies of the other team members will show that the element is checked in, until they attempt to check the item out.

New

When you add a new element, it is first created in your local Axure project file. Once you check it in, other members of the team will be able to to see or use it.

Green Plus sign. The icon is applicable to pages and masters, and appears only on the local copy of the person who created it. Other elements may not have an indicator.

[ 292 ]

Icon

Chapter 9

Status

Description

Icon

Conflict

The element on your local Axure project file conflicts with a version of the same element on the master project file on the server or shared directory.

Red Rectangle

Unsafely Checked Out

You checked out an element despite being warned that it has been checked out by another team member.

Orange Triangle

Setup Shared Repository The process of setting up the shared project is not unlike following a recipe. You need to prepare some ingredients in advance so that you don’t get stuck half way through. In this case, you need to have the location of the repository. As mentioned earlier, the repository can be stored on a shared network drive or on a dedicated SVN server, hosted on a company server, or hosted by an SVN hosting service. Either way, you will have an address that points to that location, and with the location available, you are ready to proceed. Hosting Service vs. Internal Hosting Organizations will be extremely cautious about putting anything outside of their secured environment. Weather your team’s plan calls for use a third party SVN hosting service, the organization’s own dedicated SVN server, or space on a shared directory - make sure to get clearance from the appropriate department, as well as a clear understanding of the support that will be provided, such as regular backups of the shared directory, emergency backup restore and so on.

To setup a shared repository, you always have to start with a standard stand-alone Axure file (A). It can be a completely blank file, or one that you have started as a preliminary sandbox. With the file open in Axure, Select the Create Shared Project from current File… option (B) from the Share menu. 1. The Create Shared Project window (C) will open, offering a wizard type flow that will walk you through the steps of creating the shared repository. 2. The first step is to name the project in the Shared Project Name field (D). Pay attention to the disclaimer: Files and Folders associated with the project will be created using the project name. Please enter a valid filename. For example “\” and “/” are not valid characters. My recommendation is to keep the project name short, and use a hyphen to separate several words, for example, My-Great-Project. Click the Next button (E) to continue.

[ 293 ]

Collaboration

3. The Shared Project Directory step (F) is where you need to point Axure to the location of the shared repository. This screen includes the following instructions: 4. This directory is commonly on a network drive where others can access the Shared Project. Example: /Volumes/Public/OurSharedDirectory 5. The Shared Project Directory will be created on this directory with the project name. Example: /Volumes/Public/OurSharedDirectory/ProjectName 6. The Shared Directory can also be a URL for an SVN directory. An SVN server must already be configured. Example: http://svn.myserver.com/OurSharedDirectory/ Example: svn://www.myserver.com/OurSharedDirectory/ 7. Shared directories or project names with special characters may not work. 8. You can either paste the address you prepared into the Shared Directory field (G), or use the Ellipsis button (H) to navigate to the shared directory on the organization’s network. 9. Before you click the Next button (I) to move to the next step, make sure you spelled the project name correctly, because the typo will stay with the file throughout the life of the project. You can return to the return previous screen and make the correction, if needed. 10. After you click the Next button, Axure will prompt you if there is a problem with the information you provide (J). You’ll have to validate that the path you have is correct. If you are dependent on someone else for validating the information, it is a good idea to do this setup during a time that the person is available. 11. In the following screen Axure asks you to point to the Local Directory for the Shared Project… (K), which is where the local copy of the repository will be created on your hard drive. By default, Axure offers to store it in the directory labelled Shared Projects, in the Axure Directory, but if you prefer to keep all your project work in a dedicated project directory, you can certainly do that. 12. You are ready for the final step. Click the Finish button (L), and within a short time Axure will prompt you with a Success confirmation (M). 13. When you look in the local directory, you’ll find that Axure has created two items. To use the example of our demo file, the first item is a file Alexandria. rpprj, (N) and the second item is a directory labelled DO_NOT_EDIT (O) – which, as mentioned earlier, you really should not mess with.

[ 294 ]

Chapter 9

Congratulations – you are good to go – the local copy of your shared project is ready for you to use. However – you are not done yet! Make sure to distribute the link to the shared directory to all your team members! For an SVN setup, you will also need to include the username and password that will enable your team to access the server the first time they attempt to load the file [ 295 ]

Collaboration

If you have been using a standalone version of the project, you will find the most prominent visual differences on the Sitemap pane and the Masters pane (A) <See illustration 3>>. In the Shared project .RPPRJ file, the icons for pages (B) and masters (C) include a status indicator. This indicator reflects the state of the element on your local copy of the project, not its status on the server.

Like the quintessential forbidden castle door in a fairy tale, the mysteriously labelled folder DO_ NOT_EDIT might be attracting your attention. And it is actually not a bad idea to take a quick glance to satisfy a natural curiosity. In the example depicted in the illustration 4, the local copy of the repository has been created in the Shared Projects directory, which is a sub-directory located inside Axure’s main directory (B). This main directory is created when you first install Axure. On the Mac it is located in your Documents folder (A), and on Windows, in you’re my Documents folder. [ 296 ]

Chapter 9

• Your project has a dedicated folder within the Shared Project directory, and as mentioned above, there are tow items in its root level: The rpprj file, and the DO_NOT_EDIT folder. • The DO_NOT_EDIT directory had two folders: • LocalStore (C) – Contains a small set of files • SVN (D) – Contains all the project files. The size of this directory will grow as the projects advances.

If you did not set up the shared project, or, if for some reason you need to recreate the local copy of the project, you will need to create your local copy of the project by accessing the shared repository, which we discuss next:

[ 297 ]

Collaboration

Loading From a Shared Repository The first item you will need, is the path to the shared repository on the server. You will also need a username and password, if the file is hosted on an SVN server. It is highly recommended that the person who is responsible for setting the shared repository, makes this information readily available to the team and is also available to help with the setup, if needed. On your part, make sure to store this information for future use! You should have either a path to a network directory, or a URL to an SVN server that looks something like this: https://company.svn.beanstalkapp.com/alexandria/Alexandria

Follow illustration 5 to continue: 1. From the Share menu (A), select the Get and Open Shared Project… option (B). 2. Axure will present the Get Shared Project dialog box (C). The dialog has the following instructional text, which is useful to keep in mind: 3. This directory should contain the shared repository including folders like “db”, “conf” and “locks”. 4. Note: If you have previously opened this shared project on this computer, you do not need to get it again. You can use File->Open to open the .rpprj file in your local copy of the shared project. 5. Shared directories or project names with special characters may not work properly. 6. The Shared Directory field (D) is where you either paste the URL or path discussed above (E), or use the Ellipsis (F) button to navigate within the network to the destination, if you are familiar with it. Use the Next button (G) to continue. 7. A Progress bar (H) will appear as Axure will attempt to connect to the shared repository. You will be prompted with an error, in case the path is incorrect. If all is well, Axure will move you to the next step. 8. The Local Directory for the Shared Project, is where you tell Axure where to create the local copy of the repository, in the Local Directory field (I). By default, Axure offers to store it in the directory labelled Shared Projects, in the Axure Directory, but if you prefer to keep all your project work in a dedicated project directory, you can certainly do that using the Ellipsis button.

[ 298 ]

Chapter 9

9. Click the Finish button (J) and Axure will download all the necessary files from the server or network directory, to the destination folder you indicated above. Depending on your network connection speed and the size of the file, this might take a few minutes.

The shared file will open and you can start working. Remember that to access the file on a day to day basis, you can use the Open Recent option from the File menu. If for some reason you forgot where the file is located, use the file search to look for the .rpprj string in the file name.

[ 299 ]

Collaboration

The Share Menu Once you have the local copy of the project loaded, you will be using the Share menu constantly. It is highly recommended that you and the entire team have a solid understanding of the various menu options.

Create and Load You typically have to use those options only once per project. Menu Item

Description

Create Shared Project from Current file…

Use this option if you want to create a shared project file out of the current file. This menu item is only active when you have an open file.

Get and Open Shared Project…

Use this option to create a local copy of a shared project file. If you are also the person responsible for creating the shared project, you can skip this step, because a local copy will be created for you when you create the shared file.

Update Entire the Entire File This set of options apply batch like functionality to updates, checkout and checkins. Menu Item

Description

Get All Changes from Shared Directory

This option will mass-update your local copy of the project file with all of the changes that were made by other team members. Make a habit of getting all change the first thing you do each time you start working on the file, and repeat it a few times during the day.

Send All Changes to Shared Directory

This option will update the shared repository with all the changes you have made since the last time you sent your changes. This about this option as a form of saving your work: Although you can and should use the Save option to save your work to the local copy of the project, sending your updates will ensure that, if something happens to the local copy, most of your work will be on the server. Note that the files you are working on are still checkout to you.

[ 300 ]

Chapter 9

Menu Item

Description

Check Out Everything

This option will check the entire project to you - a highly unadvisable action. Fortunately, Axure will prompt you with a warning (See Illustration 6 below).

If you do manage to somehow check the entire project out, check it back as soon as possible, because the rest of the team obviously will not be able to use it. checkout Check In Everything

This option will check in everything you have checked out. Develop the habit to use this option at the end of the day – which will ensure that you have nothing checked out.

Undo All Check Outs

This is a great option to help you undo undesirable work, and revert the effected items back to their state before you checked them out. It can happen to anyone: You check out a page and a few masters, with the intention of further developing the prototype. Things fall apart, and you realize that the best bet is to start over. Now, in the meantime you were saving your work, so you cannot undo the local copy. However – if you did not send changes, you can undo the checkout.

Update Single Page or Master This set of options allow you to deal with a single element at a time. Menu Item

Description

Get Changes from Shared Directory

This option applies only to a selected page or master.

Send Changes to Shared Directory

This option applies only to a selected page or master. [ 301 ]

Collaboration

Menu Item

Description

Check Out


Check In


Undo Check Out


Manage Shared Project… In a shared project environment, each team member has a copy of the project on their computer. During the course of a day’s work, each team member will create new elements, check out files and generally modify the project. These changes will not be reflected in the shared repository until the team member sends all changes to the server, or checks-in all their checkout elements. While you can tell if a page checked out to you, you cannot tell from looking at the sitemap, if a page that is checked-in is actually available for check-out, or perhaps has been checked-out by another team member. This applies not only to pages, but to all the elements that are controlled by the shared repository. The Manage Shared Projects consul provides any team member with a real-time view into all the elements that are managed by the shared project – In essence, you get a peek into the project’s files of record. Another information that you get, is the status of each individual element on the project. This view can spare you from the hassle of attempting to check-out an element that is checked out to another team member. Illustration 7 takes you through a normal use scenario: 1. Team member A has the page HM-100 Home [Initial] (A) , checked out. After doing some work on the page, and perhaps associated masters, which are also checked out to this user, it is time to send all changes to the shared repository using the Send All Changes to hared Directory option (C) from the Share menu (B).After a few seconds in which the Progress popup (D) is displayed, the user A is presented with the Send Changes dialog (E), which lists the elements that are going to be updated on the server in the top pane (F), and a field to enter what these changes were, on the Change notes pane (G). Upon clicking OK, the updates will be sent to the shared repository. 2. Switching to team member B, who also wants to checkout the same page HM-100 Home [Initial]. To this user, the page appears available for checkout on the Sitemap pane. However, the user chooses to use the Manage Shared Project… option (I), from the Share menu (H).

[ 302 ]

Chapter 9

3. The Manage Shared Project dialog (J) is presented. The top section of the dialog indicates the path to the shared directory (K) and also includes the following instructions: Click Refresh to retrieve the current status of the pages, masters and document properties in the shared project. Right click on an item or selection to check in, check out, and get the latest changes. Click the column header to sort by the column. Indeed, notice that initially, the main table area (L), is empty. 4. Upon clicking the Refresh button (M), the table area (N) is populated with the list of all pages, masters and design documents real-time. 5. The user can see that the page HM-100 Home [Initial] (O) is checked out and which team member has the file checked out. Now team member B can contact team member A and coordinate the checkout. In the mean time, right-clicking the row will present a contextual menu that will list available actions. 6. Note that one of the available options is Check Out (P). And while it is possible to do, it is critical to make sure that all team members understand that this is an option of last resort. 7. Dismiss this dialog by clicking the Close button (Q). It is a good idea to get into the habit of using the Manage Shared Projects before trying to checkout pages that are the responsibility of other team members.

[ 303 ]

Collaboration

Browse Shared Project History… In addition to the Axure’s Shared Projects provide your team with a couple of invaluable features: 1. The risks of lost work are almost entirely gone. As long as the SVN server, or shared network directory where you host your project, are reliably backed up, you can restore any previous version of the the project, from day one. It is not possible to exaggerate the importance of this capacity, and the peace of mind that comes with it. [ 304 ]

Chapter 9

2. The team gains the precious ability to step back in time, and access earlier iterations of the prototype. When you consider the realities of a large, fast paced project, you realize that the need to revert to an earlier version of some pattern is likely to happen. One of the most challenging aspects of iterative design, is having an effective way to revert to, or compare to a earlier version of the application. The value to the UX is real and measurable. The system maintains complete version control throughout the file’s life cycle. Each time a team member sends changes or checks in their work, a new version is added to the log. Each version, precisely identified with a unique revision number and the date of its capture, can be transformed back into a fully functional RP file which reflects its condition at the moment the version was created.Barring a catastrophic failure of the SVN server, or a shared directory that has not been backed up properly, as long as the shared repository is available, you can access practically any restore point in the project > 3. From the Share menu select the Browse Shared Project History… option. 4. The Shared Project History Browser dialog (A) will appear. The top field pints to the shared repository – you don’t want to change this. 5. Depending on the size of the team, and the point in time that you want to recover, relative to the start date of the file, the list of all versions can be overwhelmingly long. To narrow down the list to the set of potential versions that correspond to the date and time you are looking for, use the Start and End calendar drop lists (C) and (D). By default, the stared and end date are set to capture the last seven days worth of work.If you want to override the calendar pickers, you have an option to retrieve the list of all versions by checking the All Dates checkbox (E). Click the Get History button (F) for continue. 6. Within seconds, the table area (G) will be populated by a list of versions, with each row representing a fully functional restore point of the Axure file. Each row can be sorted by one of the version’s attribute, including Revision number, Date, Author and Check-in Notes. 7. Identify in the list the version that is most likely to contain. Normally, you will see several versions for each day. Since the revision number is serial, the highest revision number corresponds to the last update for that date. 8. When you click a row (H), all the activity that has been automatically recorded by Axure, will be displayed in the Check-in Notes pane (I), and additionally, any notes added by the team member uploaded the changes. This information is incredibly valuable, because typically, you will be looking to restore a particular page or master. Now comes the truly fantastic part. I have to admit that I am still excited by it [ 305 ]

Collaboration

each time I get to use it. - If you identified the revision, use the Export to RP file button (J). Axure will prompt you to save the file on your drive, and within a few seconds, you’ll be able to open a fully functional, stand alone Axure file corresponding to the time and date of that revision. Now you can find the element you were looking for, and import it into the current share project file, if you want. 9. However, if this ends up not being the snapshot you need, continue exploring until you find it. If more versions are available, the Next 100 Revisions button (K) will be active. Use the Close button (L) to dismiss this window when you are done.

A side benefit of the history browser, is that there is no need to keep old version of pages and masters, which, when you take into account the contribution of multiple team members, tends to greatly bloat the working environment. As the team moves deeper into detailed design, it is beneficial to do regular audits with team members, and discard pages that are no longer relevant and masters that are not used on any pages. All this work can be resorted, resulting in a leaner file that generates faster as both HTML prototype and Word specifications document.

Repoint to Moved Shared directory… Occasionally, there is a need to move the shared directory from its location on the network drive. As long as the repository has been moved in its entirety, this is a safe operation. All team members can continue to use their local copy of the file, but point towards the new location of the shared repository. [ 306 ]

Chapter 9

If there is a need to move the shared repository: > 1. Coordinate the move with the entire team. Ideally pick a date and time that will minimize the impact on the team’s schedule. Try to avoid proximity to major deadlines.Make sure that team members are aware of the planned move. Communicate to all clearly, that the shared repository will not be available at the set timeframe.At a set time before the move, all team members should use the Check In Everything option.After the move, provide all team members with the updated path. 2. Each team member will re-point to the new location by using the Repoint to Moved Shared Directory… option.

Clean Up Local Copy…

[ 307 ]

Collaboration

Best Practices for UX Axure Teamwork Teams are complicated. The number of variables that determine a teams’ makeup and workings, can be wildly different, making meaningful comparison difficult. But, as the famous proverb goes…For every problem there is an opportunity. In this section, I am not attempting to resolve this challenge, but rather, isolate the most fundamental team attributes are: Attribute

Situation

Size

How big is the UX team? Obviously, two people are a team, but, the larger the number of UX designers involved in a project, the harder it is to keep everyone on the same page. Larger teams are likely to break into multiple workstreams, so there is also the challenge of cross workstream communications

Location

Are all team members sharing the same physical office space? Is everyone on the same floor and in close proximity? Are people spread across the corporate campus, or across multiple cities? Are some team members working remote from their home-offices? Are team members spread across the globe?

Knowledge of Project’s Domain

Some team members may have previous project experience with and exposure to the application’s domain. Other team members are new to the domain and its nuances. This can be an issue with expert systems.

UX Experience and Expertise

Some team members may be UX veterans, with established track record, but also, with set preference for how they are used to having things done. Other team members may have different take. Junior members may have significantly less experience with UX work, and lack the ability to foresee potential problems, estimate workload and confidence when presenting to stakeholders.

Axure Expertise

Veteran team members are likely to have years of power-use skills with tools like Visio, but little Axure knowledge, perhaps even some resistance. Some team members will be totally new to the tools, while a few may have significant Axure experience.

Individual Personalities

This section is impossible to cover in a few sentences, of course. But the normal mix of extraverts, introverts, assertive, shy, outgoing, reserved, blunt, self-starters, Strong work ethics, lazy, overly polite, alpha and beta types and so on -- can turn a team dynamic into a soap opera.

Cultural Influences

In some cultures, it is not polite to behave in an assertive way around team members of higher seniority. This might be mistakenly interpreted by one from an all-are-equal culture as timidness, hesitation, and lack of confidence. Team members might find the attitude and manners of others to be rude and inappropriate, leading to tension and hostile relations. The combinations are diverse as the globe we live on.

[ 308 ]

Chapter 9

Regular and effective communications are the fundamental ingredient for successful team work, yet it is easier to say than practice. This is especially true with virtual teams of individuals, who work remotely from their homes and on-site teams spread across several geographical locations. That said, all too often, colleagues who share a cubicle, fail to exchange meaningful information despite their physical proximity. Below are a few practices to consider for your team: • As much as possible, it is important to allocate time for staff development. Ensure that all team members posses a level of Axure proficiency, that would not only make them productive, but also avoid loss of work due to errors caused by an unknowledgeable team member messing up the shared file. As we know, such calamities tend to happen just before a major deadline… • Team members should understand how to work with shared projects. All should be comfortable with the various options under the ‘Share’ menu and the difference between options such as ‘Get all changes...” and “Get Changes...”, for example. • New team members should have an on-boarding deep dive session with a knowledgeable team member to cover the structure of the sites. In large, intense projects new members are often thrown in to the cold waters of a shared project file to sink or swim because the team is at the height of some crunch. Disoriented and under pressure to get up to speed asap, the incoming member can be easily lost in the intricacies and work-around. • All team members should participate in a weekly status meeting that covers the structure of the sitemap, variables (since those are global and limited) and other important changes. Use web sharing to view the file, make sure that members understands the composition structure of their colleagues. • Despite looming deadlines, it is important to be careful and pay attention before checking in and out. A few seconds of concentration can save hours of lost work. • Team members should avoid unsafe check outs - this is critical. There are few and clear reason for breaking this rule, typically, when the person who has the elements check out, is going to be away for some time. • Before you begin work on a page, make sure to ‘Get ALL changes from shared directory’ - this will insure you have the latest copy. • Start your work session by getting all changes. Continue to update your file frequently throughout the day. • When done editing a page or master you checked out, check it in so that it will be available for other team members.

[ 309 ]

Collaboration

• Check out only what’s needed for your design work, check in as soon as done and check out the next chunk you are going to work on: Avoid hogging files you are not working on but still checked out. • If possible, structure the sitemap and masters in sections such that team members can work on chunks of the file in parallel. Agree on unique page and master IDs and a naming convention to help team members access the right files and communicate. • Make sure to back up the shared file.

Naming conventions for workstreams This section will be added after a revision to the main naming convention section in chapter 6.

Feedback from Stakeholders – The Discussion Tab Just a few years ago, the means of collecting feedback from stakeholders about a proposed user experience, were very limited, because it was rare to actually have an interactive prototype available for review on a regular basis. Axure helped revolutionize the way user experience is expressed, by replacing static wireframe presentations, with compelling interactive simulations. However, for a while, methods for collecting feedback continue to few and somewhat limited. Normally you gather stakeholders in a meeting room or video conference calls, and as you demonstrate the prototype, people respond to various aspects of the application’s design. It is good practice to request attendees to suspend their feedback, until you had a chance to complete an initial walkthrough of the proposed interaction. However, it is rare that people can hold off their comments, and typically, the presentation flow is interrupted, with a risk of derailment due to tangential discussions. Of course, experience and good facilitation skills play a major role in one’s ability to drive a presentation forward in a productive way. But regardless of the facilitation, it is objectively difficult for stakeholders to provide you with a thoughtful response, because they have a relatively brief window of opportunity to view, digest, and respond to your presentation.

[ 310 ]

Chapter 9

The discussion feature is brand new to Axure 6, and is meant to address this difficulty, by providing stakeholders with means to respond to the prototype in the privacy of their office, where they can take more time to consider the screens and interactions. The new Discussion tab has been added to the prototype’s left menu bar, and lets viewers type their comments to each page. While this new feature has a number of issues, and is far from being robust, it is, at the time of writing, still in Beta form. Given Axure’s track record of listening to the user community and enhancing features, the Discussion feature is likely to become an important value add to users.

Step 1: AxShare AxShare has been around for over a year, at the time of writing. It is the foundation to an Axure cloud based hosting service for your html prototypes. AxShare itself is currently hosted on the Amazon Web Services cloud platform, which is quite reliable and secure, as far as there environments go.As was mentioned earlier in this chapter, in the context of using a third-party SVN hosting service for your shared repository, it is important that you get clearance from the relevant department. It is also a good idea, to test how the corporate firewall impacts access to the site, since you want to provide a hassle-free experience to stakeholders.However, the beauty is that you can host the html on an internal server, and still enable the discussion feature. But you still need to follow step 1, in order to generate a prototype code. To experiment with the feature, start by adding the Discussion tab to the generated HTML prototype. . 1. You begin by pointing your browser to share.axure.com.(A), which will link you to the aptly named AxShare website (B). As the site states, AxShare is a beta, and hence the association with AxureLabs. 2. From this screen, you will be able to Sign In (C) to your account once you create it (D), and link to view to your uploaded prototypes (E). The last option is the one that stakeholders will use one you provide them with the appropriate code, password, and a link to AxShare. 3. Creating an account is a breeze, as you only need to provide an email and a password you’d like to use.Once you Sign In, start by uploading an RP file to the server (F). If you are working on a Shared Project file, export the latest version to an RP file, and check the file size. The current limit on uploads is 10mb. Use the Choose File button (G) to upload the RP file. 4. Add the prototype’s name (H) and an optional password (I). If you add a password, it will be required from everyone who will attempt to view or add feedback to your prototype. It is a good idea to set it up.

[ 311 ]

Collaboration

5. Press the Create button, and the prototype will be added to a list of all your hosted AxShare files. Within the section of each uploaded prototype (K) you have the following options: Rename the prototype Refresh the prototype Delete the prototype Modify the prototype password Disable the prototype’s Discussion thread View the prototype discussions Upload a new RP file The last option is really important, because you will have fresh iteration to present on an on going basis. All entries to previous versions of the file will be preserved. Notice the code next to the prototype name (L). This is the prototypes code, and you will need it in the next step.

[ 312 ]

Chapter 9

[ 313 ]

Collaboration

Step 2: Setup the HTML Prototype Back in Axure, you will configure the HTML prototype generator to include the prototype code, which you obtained in step 1. 1. Click the Prototype icon (A) on the toolbar to access the Generate Prototype settings dialog window (B). 2. Notice the Discuss (Beta) section at the bottom of the left bar (C). If you are using a Shared Project file, check out the HTML prototype to enable it (D). 3. Check Include Discussions, and paste the code which you generated in Step 1, into the Prototype ID (required) field (E). 4. Axure provides a link to AxShare (F), in case you did not start with Step 1.Hit the Generate button (G), to create the HTML prototype.That’s it – From this point on, and until you decide to disable the Discussion tab, this feature will be available.

[ 314 ]

Chapter 9

[ 315 ]

Collaboration

Step 3: Discuss Now you are ready to collect feedback from stakeholders. Make sure to provide clear and detailed instructions, but the process is quite simple if you plan to use AxShare: The person will need only two pieces of information: The link, share.axure.com, and a prototype id. If you chose to protect the prototype with a password, make sure to provide it as well. 1. When a password-protected discussion prototype is loaded in the browser for the first time, the left pane (A) is dimmed, and the user is prompted to enter the password (B). Notice that only the Sitemap and Page Notes tab are visible through the overlay. The user can continue without the password, but in that case, the discussion will not be available.After entering the password the left pane becomes active and the Discuss tab appears (C). Upon entering the Comments field (D), the user is prompted to enter a name which will associate them with the posting (E). By default, however, the posts are associated with Anonymous, unless changes.Once you enter your name, all additional comments in the session will be attributed to you. Each comment (G) is limited to 140 characters, which is also the maximum length of a Tweet. The length limit is certainly an issue which hopefully will be addressed in future releases. 2. It is always possible to modify the Commenting As field (H), by clicking the name next to the Commenting as label, are typing you name (I). 3. The discussion thread (J) will be maintained in the context of each page on the sitemap. Each comment includes a creation date and time.The built-in discussion feature is promising. Obviously, there are some known limitations like the 140 characters, and that variables are lost when navigating via the sitemap pane. But a more significant issue to think about, has to do with knowing how to use the prototype.

[ 316 ]

Chapter 9

[ 317 ]

Collaboration

Summary Once you experience Axure’s shared project capabilities, you may wonder how one managed to develop user interfaces as part of a UX team, before Axure. Well obviously, you, and others, did, but at a premium cost of time and effort. Teams that are evaluating prototyping tools to support their work, can reflect on their current workflow and methods, and consider Axure’s value preposition, compared to other options in the market.Axure’s support to shared projects adds real, measurable value, by helping the UX team address heads-on three major obstacles:It provides a controlled environment which facilitates work on the same prototype and specifications file by multiple team members. • Is maintains unlimited version control which is critical for disaster recovery or reverting to a previous revision.It facilitates dialog between the team and its stakeholders by proving a direct feedback in the Discussion pane. These capabilities are built on top of the tool’s rich, reliable, yet constantly evolving platform of UX specific feature-set for prototyping and specifications.

[ 318 ]

Axure RP 6 Prototyping Essentials

Axure RP 6 Prototyping Essentials

Axure RP 6 Prototyping Essentials

Perl 6 Essentials

Quarantine RP

Quarantine RP

Quarantine RP

Perl 6 and Parrot Essentials

Prototyping techniques

Red Hot Party RP

Joining the Party RP

Joining the Party RP

Out of Control RP

Red Hot Party RP

Out of Control RP

Red Hot Party RP

Out of Control RP

Prototyping: A Practitioner's Guide

Prototyping Augmented Reality

La Rp De La Antartida

Rapid Prototyping Technology

Essentials

FPGA Prototyping Using Verilog Examples

Design and Prototyping for Drupal

Design and Prototyping for Drupal

Rapid systems prototyping with VHDL

Design and Prototyping for Drupal

Rapid Prototyping Casebook (Casebook S.)

Essentials of Banking (Essentials Series)

API RP 1166 Excavation Monitoring and Observation

Rapid Prototyping of Digital Systems: SOPC Edition

Axure RP 6 Prototyping Essentials