The problem we need to solve can be explained by considering Figure 1 where we have prototyped a very simple usability questionnaire using Axure 7.
Figure 1: A very simple usability questionnaire prototyped in Axure 7.
In this example there are three questions and a pair of radio buttons for answering each of these. As the questions are answered by clicking the radio buttons, the total score is updated whereby one point is scored for each "Yes" answer. So, if the user answers "Yes" to all three question, the total score is 3; and if the user answers "No" to all three questions, the total score is 0.
To prototype this in Axure 7 we can do the following:
Label all of the radio buttons and add a rectangle shape for calculating the total, as illustrated in Figure 2.
Assign each pair of radio buttons to a radio group to take care of the exclusivity of each answer, as illustrated in Figure 3.
Add a case to the
OnClick event of the first radio button, named
setTotalScore in this example, that has an action to calculate the total score, based on the status of the radio buttons, and place this value into a global variable called
gVar_totalScore. In this example, I’m doing this via three local variables (
lVarquestion3) that are mapped to the
is selected of status of the three ‘Yes’ radio buttons. This means that when the radio buttons are in the selected state the value of each local variable will equal 1. The values for each local variable are then added together and placed in the variable called
gVar_totalScore. This is illustrated in Figures 4 and 5.
Add an action to this
setTotalScore case that places the value of the variable
gVar_totalScore into the rectangle shape called
bstotalScore, as illustrated in Figure 6.
Copy this case onto all the radio buttons, so that the total score will be updated when the user clicks on any of the radio buttons, as illustrated in Figure 7.
And now the problem…
This example will work just fine, but the architecture of this Axure prototype has a significant problem that could cost us a lot of time later on. The problem comes if we want to add a fourth question and an associated pair of radio buttons, as illustrated in Figure 8.
As well as adding cases to the new radio buttons, we also need to update every case on every one of the existing six radio buttons, so that the total score is now calculated on the basis of all four questions. This is quite a lengthy and tedious task, and in real prototyping scenarios, we may have to update lots of cases this way, and remember — a key feature of prototyping is speed.
When there are many actions and conditions to be updated within each case, we could save some time by updating just one case, deleting any old cases, then copying and pasting the updated case as required. However, this is still quite lengthy and tedious. Its repetitive nature also means that it is error-prone, for example it is easy to forget to update one or more widgets if we are editing lots of them. In turn, finding bugs introduced by such errors can be quite difficult to track down, as we may be convinced that all the widgets have been correctly updated.
And now the solution…
Fortunately, there is a solution to this problem. Consider a new version of our Axure prototype illustrated in Figure 9. This includes a small dynamic panel, which has one empty state and, in this example, is labelled
OnMove event of this panel has a case that contains all of the actions necessary to calculate and set the total score: that is, the same cases that were present on each radio button in the previous version of our prototype.
As illustrated in Figure 10, each of the radio buttons in this version has a case with a single action on its
OnClick event —
Move calculator by (0,0). This does not actually move the panel anywhere (because the move values are 0,0) and, indeed, we have no interest in actually moving this panel in this prototype. Rather, the key here is that this action triggers the calculator panel’s
OnMove event, which in turn performs the cases we need to calculate and set the total score.
This architecture means that if we add one more question, we simply have to update one case on the
OnMove event of the dynamic panel, and copy and paste some cases onto the new radio buttons — we do not have to update any of the cases on the exiting radio buttons!
Discussion, Takeaways and Next Steps
Of course, the time saving and error prevention benefits of this architecture increase along with the number of times that similar cases would otherwise need to be replicated across the prototype, but the architecture has another, less obvious, but key advantage. Keeping track of what interactions each widget/event is performing in a prototype can ultimately become the limiting factor in how complex an Axure prototype an individual can produce. This architecture, whereby we keep more complex cases in one place, or put another way, "modularize" the interactive aspects of the prototype, makes the process of managing complex interactivity easier and more scalable. Therefore, this increases the potential complexity of the prototype.
The ultimate progression of this architecture is to set global variables prior to triggering a dynamic panel’s
OnMove event, such that the panel then uses the value in the variables to determine (through the use of conditions) which case(s) to execute, and how this execution should be performed, in particular contexts. Indeed, some Axure experts, including myself, have pushed this architecture to the point whereby, for very complex prototyping, we manage most, or even all, of the interactivity using a single control panel and a suitable set of variables for managing the behaviour of this panel. In my experience, this makes it easier to keep the ‘interaction model’ in mind and identify/correct any bugs. Indeed, an example of this can be found in the widget called
menuPanDragSwipeRepeaterItems (H) in Ax-Stream’s Drag, Swipes and Spins widget library (which is a free download), and Figure 11 contains a snap shot of this that demonstrates the basic concept.
The use of such architectures can be extended in Axure prototyping whereby we set up a bunch of such ‘control’ dynamic panels on a page that act like a subroutine library that we can simply call upon from any widget or event to execute the cases we need.
Of course, as with all Axure functionality, we can place these control panels into masters if we want to reuse them across pages. Similarly, we can place them within custom widgets so that (complex) cases can be reused across different projects via widget libraries. I also hope that such libraries will eventually be produced for distribution across the Axure community so that Axure prototyping speed can be increased in general — just as code subroutines and objects that solve common programing problems are freely available to developers (for a wide variety of development environments).
Clearly, these more sophisticated progressions will be best suited to those with a more technical background, who are capable of complex Axure prototyping. However, the basic technique of using the
OnMove event on a dynamic panel to reduce redundancy in a prototype’s interaction model is not particularly difficult to understand at its most basic level, and I hope it will be useful to the wider Axure community.
This article is an extract from "Reusing Cases Across Different Widgets and Events" from Prototyping Essentials with Axure, edited by Ezra Schwartz and Elizabeth Srail (2014).
About the author
Dr. Ritch Macefield (@Ax_Stream on Twitter) holds a BA in Creative Design, an MSc in IT/Computing and a PhD in HCI. He is an acknowledged expert in Axure having led Axure projects for clients like Thomson-Reuters, Dell computers and Vodafone. He was a panel speaker at Axure World 2012, contributed to the book “Axure RP 6 Prototyping Essentials” and founded the Axure RP Pro LinkedIn Group.
Love it? Hate it? Join the discussioncomments powered by Disqus
Foundation Certificate in UX
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Every month, we share an in-depth article on user experience with over 10,000 newsletter readers. Want in? Sign up now and download a free guide to usability test moderation.
User Experience Articles
Our most recent articles
- Apr 3: Is Usability a Science?
- Mar 6: Why iterative design isn’t enough to create innovative products
- Feb 6: The Beginners' Guide to Contextual Interviewing
- Jan 9: The 8 competencies of user experience: a tool for assessing and developing UX Practitioners
- Dec 5: Non-UX books that every UX practitioner should read
Our most commented articles
Search for articles by keyword
- 7 articles tagged accessibility
- 4 articles tagged axure
- 5 articles tagged benefits
- 16 articles tagged careers
- 8 articles tagged case study
- 1 article tagged css
- 8 articles tagged discount usability
- 2 articles tagged ecommerce
- 14 articles tagged ethnography
- 14 articles tagged expert review
- 1 article tagged fitts law
- 4 articles tagged focus groups
- 1 article tagged forms
- 6 articles tagged guidelines
- 10 articles tagged heuristic evaluation
- 7 articles tagged ia
- 14 articles tagged iso 9241
- 11 articles tagged iterative design
- 3 articles tagged layout
- 2 articles tagged legal
- 11 articles tagged metrics
- 3 articles tagged mobile
- 7 articles tagged moderating
- 3 articles tagged morae
- 2 articles tagged navigation
- 9 articles tagged personas
- 15 articles tagged prototyping
- 7 articles tagged questionnaires
- 1 article tagged quotations
- 4 articles tagged roi
- 16 articles tagged selling usability
- 12 articles tagged standards
- 44 articles tagged strategy
- 2 articles tagged style guide
- 4 articles tagged survey design
- 5 articles tagged task scenarios
- 2 articles tagged templates
- 21 articles tagged tools
- 53 articles tagged usability testing
- 3 articles tagged user manual