Axure RP 6 Prototyping Essentials — Save 50%
Creating highly compelling, interactive prototypes with Axure that will impress and excite decision makers with this book and ebook
This article covers some advanced topics such as conditions, raised events, and so on.
In this article by Ezra Schwartz, author of Axure RP 6 Prototyping Essentials, we will cover a set of features such as raised events, conditional logic and variables, introduction to a terminology which is usually associated with programming and suggests complexity. It is understandable if you are not interested in, or are intimidated by, the prospect of coding, and 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 interactions by pointing and clicking. The only typing required is the labeling. You will find a similar easy-to-use interface when you use features such as the Condition Builder or simulate "drag and drop".
Secondly, think about some of the terminologies 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.
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 interactions in your prototype. Let's face it, we use logic all the time, even if the results are not always logical. Moreover, 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 has become the standard search interface.
Programming languages employ a variety of syntaxes for creating and evaluating conditional statements. Axure simplifies things by using the very common syntax of If-Then-Else, which essentially looks like this:
- If A is true, then do X
- Else, if B is true then do Z
This kind of decision-making is very natural to UX designers because we use a similar logical approach to model task and interaction flows. When we create a conditional interaction, we reflect the flow's logic in the prototype. As it is best to learn by doing, let's dive into a quick example:
Sandbox files 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 Axure feature works, or wanting to explore a new interaction. This is where the sandboxing technique can help: Create a blank new Axure file on your desktop, work through your explorations on this file, and then apply your learning to the project file. In the sandbox file, you don't have to worry about "breaking" any of your previous work and can focus instead just on the mechanics of the feature you are trying to figure out. The technique will also keep your production file clean and free of experimentation wireframes.
Guided example—conditions and dynamic panels
Axure makes it very easy to apply conditional logic to the prototype, as you will see in this example. We will use a "sandbox" file to explore the feature, and later, apply the learning to the Alexandria project file.
Step 1: Defining the interaction
Our goal is to change the state of a dynamic panel based on the user input. This is one of the most commonly used conditional logic interactions in the construction of Axure prototypes, and a great illustration of If-Then-Else.
In this simple example, the user selects a shape from a list of shapes and the appropriate shape appears. The first step is to define the desired interaction. Now that the conditional logic is involved, this is also the opportunity to spell out the logic:
- When: When the user changes the selection
- Where: A droplist widget
- What: Change the state of a dynamic panel to show the corresponding shape
- Conditions: On entry, the droplist should show the option "Select from List", and no shape should be visible
- If the user selects the value "Rectangle" from the droplist, show the rectangle state
- If the user selects the value "Triangle" from the droplist, show the triangle state
- If the user selects the value "Circle" from the droplist, show the circle state
- If the user selects the value "Select from List" from the droplist, hide the shapes
The logic here is simple, because each selection in the droplist has a corresponding dynamic panel state. We instruct Axure to evaluate which option is selected in the droplist, and then change the state of the dynamic panel accordingly.
Notice that the first sentence in the condition section specifies the entry state, in this case, the option "Select from List". This is the default state when the screen loads. When you plan interactions that involve conditions, always make sure you account for a default state of that UI control.
Step 2: Constructing Wireframe
We will start by preparing a sandbox environment. Create a blank directory on your desktop and label it Axure Sandbox. In this directory, create another directory named HTML—this is where we will generate the prototype. Finally, create a new Axure file named Sandbox and save it in the Axure Sandbox directory. The following screenshot illustrates the steps:
- From the Widgets pane, drag over a Droplist (A) and a Dynamic Panel (B) widget. Label them Droplist and Shape States, for example.
- Double-click on the droplist and in the Edit Droplist dialog (C), add the values specified in Step 1, and check Select from List to make it the default value (D).
- In the dynamic panel, create the states for the three corresponding shapes. This does not need to be an elaborate production. Make sure you label each of the states (E).
- Right-click on the dynamic panel and select Set Hidden from the context menu.
Step 3: Setting the first condition
When you start with interactions, having the flow pre-planned helps in creating the wireframe and in adding the interaction. Now that we covered both in Steps 1 and 2, we will set the conditional logic for the interaction. The following screenshot visualizes the process:
- With the droplist selected in the wireframe (A), switch to the Interactions tab in the Widgets Properties pane, and double-click on the OnChange event (B) to launch Case Editor (C).
- Before clicking on Case 1, we want to create the conditions. Click on the Add Condition link (D) to launch the Condition Builder window (E).
- We will discuss Condition Builder later in this article, but for now, notice that the first condition row already appears in the builder. It is contextual to the selected widget, and is structured like an equation: "The selected option of droplist equals the value Select from List." (F). As this is one of the conditions that needs to be evaluated, each time the user changes a value in the droplist, we can use it as is. Click on OK to close the builder.
- Back in Case Editor (C), notice that the condition has been added to Case 1, and Axure presents it in a human-friendly way: If selected option of Droplist equals "Select from List" (G).
Step 4: Adding the first interaction
Now we need to instruct Axure about the action to apply when the condition we have just set is met. In this case, when the value of the droplist is "Select from List", the shapes should be hidden. As the shapes are in the dynamic panel widget, we want to hide that widget. Now, you might ask yourself, "Why hide the dynamic panel, if it is already hidden?"
When you create conditions, always make sure to account for ALL the possible cases that are applicable to the interaction.
It is true that in the wireframe, the dynamic panel is hidden by default. However, once the user selects a shape from the list, the dynamic panel will become visible, until the user changes the value in the droplist to "Select from List". Moreover, this is where the Set Hidden action will come into play. The following screenshot illustrates the process:
(Move the mouse over the image to enlarge.)
- First, label Case 1 to something meaningful such as Hide Shapes (A).
- Select the Hide Panel(s) action (B), and click to check the dynamic panel widget which is listed in the column Step 4: Configure actions (C).
- The complete interaction is now listed under the column Step 3: Organize actions (D).
Step 5: Completing the interaction
At this point, the interaction includes a single case, which handles a single condition. In order to complete the interaction, we need to capture additional cases when the user picks various shapes from the droplist. The following screenshot illustrates the first half of the process involved in adding the condition and interaction for the first shape:
- As we are evaluating the selected option of the same widget, the only variable to check is the value of that option. This means we can use a shortcut: Right-click on the initial case created in Step 4 (A), select Copy Case (B), and then Paste Case(s) (C) from the context menu.
- Double-click on the new case (D) to open Case Editor (E), where the first things to do are to rename the case (F), and delete the Hide action (G).
Using one case as the starting point for another case is common. The following screenshot illustrates the process of tweaking the duplicate case to fit a new condition:
- In Case Editor, click on the Edit Condition link (A). All there is to do next is to change the copied selection from Select from List to Rectangle (B), and close the Condition Builder.
- Back in Case Editor, set the action to Set Panel state(s) to State(s) in the column Step 2: Add actions (C) and in the column Step 4: Configure actions (D), check the dynamic panel widget (D) and select the Rectangle shape (E).
- We need to add a Show Panel(s) action (F), because the dynamic panel widget is hidden by default and it is also hidden when the selected option in the droplist is Select from List. With this action set up, close Case Editor.
- The interaction for OnChange case (G) now covers a couple of the conditions we specified in Step 1 of this example. Add the additional cases using the process outlined in Step 5.
The following screenshot illustrates what the complete conditional interaction should look like:
When the user changes an item in the droplist, the OnChange action (A) evaluates the selection and:
- If the user selects the value Rectangle from the droplist, show the rectangle state (C)
- If the user selects the value Triangle from the droplist, show the triangle state (D)
- If the user selects the value Circle from the droplist, show the circle state (E)
- If the user selects the value Select from List from the droplist, hide the shapes (B)
It is time to generate the HTML prototype. Make sure you set the path for the prototype to Axure Sandbox | HTML, as discussed in Step 2 of this example. The following screenshot (A through E) illustrates the generated result:
The Condition Builder
Let's take a closer look at a simple conditional statement from the previous example. The interaction for the Rectangle case is composed of the following two sentences:
- If the selected option in the Droplist equals Rectangle
- Set Shape State state to Rectangle
The first sentence is the condition being evaluated, and the second sentence is the action that takes place if the condition is met. Now let's focus on the condition sentence itself, and the flexibility afforded by the modular nature of Axure's Condition Builder.
Although the condition is composed of five droplists, what we are looking at is an equation in which we compare the first two droplists to the last two droplists. The following screenshot illustrates how the segments are assembled in the builder:
- selected option of is one of eleven choices in the first droplist (A). The selection made here affects the other droplists. Note that, although in our example, we have the interaction tied to the OnChange event of the droplist widget, the condition we add does not have to be limited to evaluating the selected value of the droplist. We could add other conditions to the OnChange event that evaluate any of the other choices in the builder's droplist A.
- Our choice in the first droplist narrows the options in the second droplist (B) to droplists and listbox widgets. Our example wireframe has only a single droplist widget and so Droplist (Droplist) is the only item listed.
- The third droplist (C) is where we set the comparison choices in droplists A and B to the choices in droplist D and E. In addition to the option Equals, there are nine more options to construct the equation.
- In the forth droplist (D), we specify what type of value the comparison will evaluate. In our example, we want to know what is the selected option in the wireframe droplist. However, we could also set a comparison to the selected option of some other droplist and create contextual droplists (example is coming below).
- The last droplist (E) is contextual to the selection we make in D. In our example, as we opted to look at the value of the Droplist widget (B), Axure lists the values we entered for that widget.
- Finally, the Description section (F) is automatically generated by Axure to reiterate the condition in plain English.
Guided example—multiple conditions
We often have to evaluate multiple conditions before we can determine which action to take. For example, simulating validation of the required form or authentication fields, or simulating a contextual rendering of an application screen, based on the user login, status, and other parameters. The Condition Builder is a significant time saver because with relatively few wireframes, mostly variations within dynamic panel states, it is possible to create multiple conditions and simulate sophisticated interactions.
For this example, we will continue with our Alexandria project. Specifically, we will complete the login validation.
Step 1: Defining the interaction
Our goal is to evaluate if the user entered their username and password, prompt the user if there is missing or wrong information, or log them into the site. This interaction is broadly used, although interaction patterns vary slightly. Successful sign-in is a critical task because in most sites and applications, it affords access to the most valuable features.
It is sometimes tempting to postpone, or skip altogether, simulating the sign-in task, because it is so trivial. However, without an explicit directive from UX about this flow, we are leaving the interpretation and design to the developers.
In this example, we will use Condition Builder to compose several conditions and the first step is to define the desired interaction. As with all interactions that involve conditional logic, this is the opportunity to spell out the logic:
- When: When the user clicks on the Login button.
- Where: The Login rectangle widget.
- What: Validate the username and password. Alert the user if there is an issue, or log the user in.
- Conditions: On entry, the User Name and Password fields are empty, and the Login button is disabled.
- The Login button is enabled only if both fields are populated.
- When the user clicks on the Login button.
- If the provided credentials are ok, change the screen to reflect a successful sign-in screen.
- If any or both credentials are wrong, notify the user and disable the Login button.
- If the user re-typed the credentials, reactivate the Login button.
The logic here is a bit more involved compared to the previous example, as we need to account for the interaction in multiple widgets: The form fields, the Login button, and the notification to the user in the case of an authentication problem.
The following screenshot illustrates the current state of our Login wireframe and its interaction
- The Subscribe/Login master is a dynamic panel with two states
- Login Form is on the second state, and the only widget with an interaction is the Login button (A)
- The interaction is triggered by an OnClick event which does not evaluate the User Name and Password fields
Step 2: Constructing Wireframe
We will start by iterating on top of what we have already created, and make adjustments to the wireframe according to the new requirements. The following screenshot illustrates the tweaks:
- It appears that in the current wireframe, there is no room for providing the user with feedback if there is an issue with the username or password.
- Right above the Login button, we will add a dynamic panel which will contain the error message (see the preceding screenshot, A) and set it to Hidden (B). Remember that dynamic panel widgets are the only widget type or which you can control the visibility properties:
- The height of the current pop up needs to be adjusted to accommodate the added alert, and remember to increase the height of the dynamic panel that holds the state.
- The Login button (C) needs to have a disabled state. There are at least a couple of ways to approach the constructions.
- Converting the widget into a dynamic panel and adding a disabled state:
- Use the styling feature to add a Disabled Style (D) in the Set Disabled Style editor (E) and use actions to switch between normal and disabled styles. In this example, I will use the second option because it involves maintaining a single wireframe widget and the use of styles which is faster to update.
With the wireframe updated to support the interaction, we can now move on to the next step.
Step 3: Interaction tweaks
A quick review of the flow of interactions, as it pertains to the wireframes, is illustrated in the following screenshot:
- The entire interaction is triggered when the user clicks on the Log In button (A), a widget in the Before Login state of the dynamic panel DP Subscribe Actions Bar (B), which is part of the master M Subscribe/Login (C).
- The dynamic panel Login Form (D), which is also in the master (C), will become visible.
- The alert dynamic panel (E) will be hidden. This is taken care of by setting the default visibility of this dynamic panel to hidden:
- The Login button (F) needs to be set to show its disabled state.
As setting the Login button to a disabled style cannot be defaulted on the widget, it needs to be set in an action. The process is illustrated in the following screenshot:
The logical place to have this action is on the button that triggers the interaction, the Log In button (see the preceding screenshot, A). Moreover, as we already created an initial interaction for this widget, we only need to add the action Disable Widget(s) (C and D) to that interaction. Generate the prototype and test this out. The styling of the Login button will be set to the visual style you assigned to the widget, and although the widget has an OnClick interaction associated with it, it will be disabled.
Step 4: Evaluating multiple conditions
Now that we have established an initial state for the Login button in the prompt, we can move on to composing the interaction that will enable the button and allow the user to continue with the login process.
As the Login button should only be enabled if there is some content in the User Name and Password fields, let's assign each of the fields with an interaction to evaluate just that. In this example, our evaluation will not be too elaborate.
- For the User Name field, we will check whether the user typed in at least four characters. We will not look for a specific value.
- For the Password field, we will check whether the user typed in at least six characters. We will not look for a specific value.
Both fields are Text Field widgets. This type of widget can support the following events:
How can we decide which event should trigger the interaction? The truth is that you can accomplish the requirements in several ways, and in some cases, it is a matter of trial and error. In this example, I will use the OnKeyUp event to trigger the actions that evaluate the fields, because this event provides an instant feedback to the user if the entered credentials satisfy the requirements.
The following screenshot illustrates the conditions and interactions for the User Name field (A):
- We need to create two cases for the OnKeyUp event (B):
- The first case (C) will evaluate whether the length of the input in this field is at least four characters, and whether the length of the input in the Password field is at least six characters, because the user must provide both pieces of information. If the length of the input for both meets the conditions, the Login button (E) will be enabled.
- The second case (D) will keep the Login button disabled, if the length of input to the User Name field is less than four characters. We don't need to evaluate the length of the Password field, because the User Name must meet the condition and so it does not matter if the Password field is ok.
This example was a demonstration of the frequent need to evaluate multiple conditions in a single case. Let's take a closer look at the Condition Builder:
Satisfy all or any
The preceding screenshot illustrates the Condition Builder's Satisfy droplist (A) which has only two values, all and any. By default, it is set to all, which is fine if you have a single condition in the builder. With two or more conditions, it becomes critical that this droplist is set to the correct value. To help you make sense of the condition, the droplist is set as part of a sentence. Always read the entire sentence when you consider which option to set:
- Satisfy all of the following:
- Satisfy any of the following:
In our example, the conditional logic controls whether or not to activate the Login button, and because BOTH fields must be validated, the selection of "all" in the Satisfy droplist is the correct one.
Step 5: Final conditional touches
Complete the interactions and conditions for the Password field and generate the prototype to test whether the login control works as intended. The companion Axure file for this article includes the complete interaction, but I encourage you to try to figure it out yourself, because, as with anything else, we learn best by first-hand experimentation.
It will also be nice to demonstrate the alert field, which notifies the user when either of the fields is invalid. This condition is tested when the user clicks on the active Login button.
In this example, we will only evaluate the Password field and the process is illustrated in the following screenshot:
- We have already created an interaction for the Login button (A). The initial version did not evaluate anything, and the two cases for the OnClick event were to be triggered manually.
- The revised interactions for the Successful and Failed Login cases will evaluate a specific password value. While the conditional logic in the User Name and Password fields evaluates the length of the input, here, we want to simulate the system response if the value of the Password field (C) is incorrect.
- For convenience, set the password to something that is easy to remember and type, because as long as the conditional simulation of the login is in place, you will have to go through the flow each time you generate the prototype. This can become very tedious. Our password will be simply be 123456. If needed, however, you can use Axure to simulate very rigorous password verification conditions.
- The alert line (D) appears only if the password is incorrect. The Successful Login case will test if the password equals to 123456 and will change the state of the entire dynamic panel.
eBook Price: $29.99
Book Price: $49.99
(For more resources on Axure Prototyping, see here.)
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, unfortunately, no. However, 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.
There are three important things to remember about raised events:
- Raised events can be created only for widgets that are on masters
- A master may have multiple raised events
- Creating a raised event is a two-step process:
- Step 1: Create the raised event on the master
- Step 2: Create the interaction for the raised event on the page where an instance of the master is placed
Why do we need raised events? A one-word answer is Context. The longer explanation goes something like this:
- Masters would be of very limited use for an interactive prototype, if there was no way to allow the master exhibit different behaviors, based on the page on which the master is placed.
- When a master is placed on a page, it is not possible to edit or assign interactions from the page to any of the master's widgets. The master's wireframe has to be edited in its own page. A raised event affords a way to create an interaction on a wireframe, which can be applied to widgets within masters.
Our first example will demonstrate the use of raised events to manage the behavior of a Global Navigation master, such that a tab that corresponds to the current page will not respond to an OnClick event.
We set a basic interaction for each of the four tabs that make up the master M Global Nav. Each of the tab widgets links to its corresponding page when an OnClick event is triggered. For example, on the b page, clicking on the Books tab links to the Books page; quite straightforward. The problem is that the Books tab continues to be clickable on the Books page because the tab is part of the master. It performs its built-in interaction on each page on which the master is placed. In this example, we will make the behavior contextual.
Step 1: Creating a raised event on the master
For this example, there is no need to make any construction changes to the wireframes, just adjust the interactions. The following screenshot illustrates the wireframe before using raised events:
- On the master M Global Nav wireframe (A), the Books widget (B) has a single interaction tied to the OnClick event (C).
- The interaction, as seen in Case Editor, is Open Books in Current Window (D), composed of the action Open Link in Current Window (E) pointing to the Books page in the sitemap (F).
- An instance of the master M Global Nav (G) is placed on the Books page wireframe (H). Notice that the Interactions tab in the Widget Properties pane (I) is disabled and empty.
As you can see in the preceding screenshot (I), widgets on the master cannot be assigned interactions once the master is placed on a page. Moreover, depending on the interaction, it is complex or impossible to create an interaction context in the master wireframe that is assigned to master widgets. The following screenshot illustrates the first of the two parts in the process of creating raised events:
As raised events can only be created in a master wireframe, we start by opening the Global Navigation M Global Nav (A). I will focus on the Books tab widget (B), but the process should be repeated for all widgets.
- The Books widget has one interaction triggered by the OnClick event. We start by deleting the existing action Open Books in Current Window (C).
- Double-click on Case 1, and in Case Editor, scroll all the way to the bottom of the column Step 2: Add actions, where you will find the Raise Event action (D) nested under the Miscellaneous section.
- While the Raise Event action is added to the column b (E), the column Step 4: Configure actions (F) is empty.
- In order to add a new raised event, click on the Add icon (G) there. You may have noticed that Axure provides a description of raised events in the top part of the column. The important part of the description pertains to labeling raised events:
- Raised event names must be alphanumeric
- Spaces are not permitted in raised event names
- Label the raised event something like GoToBooks (H), and, very important: make sure you check the checkbox to the left of the raised event name!
- While you are at it, and if you did not do it before, label the generic Case 1 to something meaningful such as GoTo Books (I).
- Notice that now, because of labeling, the interaction in the column Step 3: Organize actions is easy to figure out.
Troubleshooting Raised Events
The first thing to check if a raised event does not work is to make sure that the checkbox next to the raised event name in Case Editor (see the preceding screenshot, H) is indeed checked!
Finally, the following screenshot illustrates an alternative way to create raised events on the master:
- From the Wireframe menu (A), select 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 Case Editor. Existing raised events, such as the one we just created in the example, will be listed (D).
- Use the Add icon (E) to create additional raised events (F). These raised events will then be available for you to use in interactions for widgets within that master.
The following screenshot illustrates how to associate these raised events with master's widgets, this time using the Home tab widget as an example:
- Follow the step that we took in the Books tab, and start by selecting the Home tab in the master wireframe, and use the Delete option (A) to clear the original action Open Home in Current Window (B).
- In Case Editor, as soon as we select the Raise Event action, it appears in the column Step 3: Organize actions (D), and all four events we just added are listed in the column Step 4: Configure actions (E).
- After checking the box next to the raised event GoToHome (F) and labeling the case with the meaningful name (G), the interaction in the Step 2 column is updated (H).
Repeat the process for the News & Mags and Movies & TV widgets to complete the conversion of the master M Global Nav. At this point, each of the widgets on the master can respond to an OnClick event which will trigger the corresponding raise event. However, we created the labels for those raised events. The names could be very arbitrary. So how does Axure know that the label GoTo Home, for example, is supposed to link to the Home page? How do we assign an actual Axure action to the raised event? For the answer, let's move on to the next section.
Step 2: Applying interaction to raised events on a page
The following screenshot illustrates the "before" and "after" use of raised events on the Books page wireframe:
- Without raised events: In the Books page wireframe (A1), there is an instance of the Global Navigation master (B1) in which the tab widgets have conventional link actions. When you click on the master on the page wireframe, the functionality of the Interactions tab in the Widget Properties pane is disabled (C1), because the master's widgets are not exposed to the page.
- With raised events: In the Books page wireframe (A2), there is an instance of the Global Navigation master (B2) in which the tab widgets have interactions that involve raised events. When clicking on the master on the page wireframe, the functionality of the Interactions tab in the Widget Properties pane is enabled, and the raised events are listed (C2). Now, it is possible to create interactions on this page, which will be triggered by widgets on the master.
Therefore, here is the fascinating and powerful aspect of raised events, and why the time investment in understanding raised events will pay off. As masters are placed on multiple pages, the list of raised events will be exposed on each page, including the wireframe pages of other masters. In each page, you can create different interactions for the same raised event. Moreover, this is how the same master can have different behaviors on different pages.
The following screenshot illustrates the interactions assigned to the four tabs in the Global Navigation on the Books page:
- When the master M Global Nav (A) is selected in the Books page wireframe, all the raised events associated with the master are listed in the Widget Properties pane's Interactions tab (B).
- The OnClick event for the raised event of the Books tab widget (C) is only assigned an "Other" type action, with some verbiage that basically says that when the user clicks on this tab, nothing happens. Creating a case for this raised event is optional, and here I also demonstrate how to user the "Other" action as a way to document the prototype.
- Note that for usability testing, you may want to clear the interaction, so that the tab will not respond to a mouseover
- The OnClick events for tabs Home, News & Mags and Movies & TV (D, E, and F) involve the simple link action to the corresponding page of each of the tabs.
Repeat the assignment of interactions to the master's raised events on each of the other pages.
Nested masters: Amplifying the raised event
It is common to include one master within the wireframe of another master. The raised event of the nested master, however, will not be exposed when the enclosing master is placed on page wireframes. The following screenshot illustrates an example of the nested master:
One of the requirements for Alexandria is to provide a contextual help. Your proposed approach is to include a small help icon where needed. In this example, the icon appears in the login prompt (A). Clicking on the icon shows a transparent help pop up (B), which can be dismissed by clicking it.
The following screenshot illustrates the underlying construction in Axure, and the issue of raised events in nested masters:
- The help pop-up is constructed as a master M Help Popup (A), composed of an image widget that holds the help icon (B) and a dynamic panel widget (C) where each state contains the relevant help content. In order to visualize the example, the dynamic panel is shown as visible, but in the actual construction, it should be set to hidden by default.
- The interaction for the help icon (B) is triggered by an OnClick event, which includes the raised event action ShowHelp. As the help pop-up master will be placed on multiple pages and masters, the plan for the raised event is to do the following:
- Show the help pop-up dynamic panel
- Bring the pop up to the front
- Set the dynamic panel to the state which contains the help content that corresponds to its placement on the page wireframe
- Place an instance of the help pop-up master on the Login Form master wireframe (E). When the pop-up master is selected (F), its raised event is visible in the Interactions tab (G).
- However, when you click on the Login master (H) on the home page wireframe (I), the raised event of the nested help pop-up is not visible (J).
What to do? The following screenshot illustrates the issue and solution using a simple method which I call Amplify Raised Events:
- While we cannot see the help master's raised event on the Home page wireframe, we can see it on the login prompt of the master wireframe (A). So, click on the nested help master (B) to show the raised event in the Interactions tab (C).
- Create a new case for the raised event ShowHelp. The action for this case will be a raised event which you will name AmplifyShowHelp (D). Essentially, the nested raised event will trigger a new raised event. In essence, it will amplify or repeat the call to the original raised event action.
- Switch to the Home page wireframe (E) and click on the Login master (F). The raised event AmplifyShowHelp will be visible in the Interactions tab (G).
- Now create a new case for this raised event, name it Show Login Help and assign it relevant actions, as discussed above. Generate the prototype to make sure that the interaction is working as intended.
To conclude the raised events topic, I want to re-emphasize the tremendous usefulness of this feature to the construction of high fidelity prototypes. While masters help us enforce visual consistency and reduce the number of redundant wireframes, raised events help assign contextual behaviors to those masters.
In this article, we covered a set of Axure functionalities that are responsible for creating truly interactive prototypes. Conditions and raised events extend our ability to move beyond the basics of navigating from one wireframe to another. We can also create a relevant context in response to inputs.
- Page Management [Article]
- Article Marketing on CMS, Blogs, and Online Magazines to Improve Sales [Article]
- Users and Permissions with CMS Made Simple [Article]
- Access Control in PHP5 CMS [Article]
eBook Price: $29.99
Book Price: $49.99
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 for phased, 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 lead 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 http://www.artandtech.com.