Sometimes interactions in the prototype don't work as you expected—an experience that can be frustrating, and sometimes stressful, if you are under a tight deadline. Bugs happen: it is unavoidable, and you should build time into the project plan for testing and debugging. Of course, so many things can go wrong, but we found that there are a few common behaviors that lead to the creation of issues and other behaviors that help resolve them systematically and efficiently.
Experienced Axure users are often asked by colleagues for help in debugging their interactions. While sometimes, especially during looming deadlines, it is very tempting to just fix the problem for them and move on, we believe that taking the time to help team members adopt good troubleshooting habits pays off. It reduces the frequency of you being disrupted to help with a bug just to find a very basic error, which your colleague could have easily identified had they followed a basic troubleshooting checklist. Stress and annoyance can be reduced, which is very important for good teamwork.
The following sections are brief on purpose and meant to help you, if you are a novice user, quickly absorb and internalize core best practices, and reduce time spent and frustration built over bugs, as you enhance your skills in constructing interactions. For experienced users, we hope they will save the time needed to come up with such a list to hand out to less-experienced colleagues.
The following list combines common-sense and learned behaviors that we have adopted over the years, because they help us reduce bugs or tackle them more efficiently:
Axure invokes events in the order listed in the Interactions tab. Therefore, make sure you order the events in the order you want them to play out.
Assign unique names and IDs to widgets and dynamic panels. This will save you from accidentally assigning an action/event to the wrong widget or dynamic panel.
If you have multiple bugs on one wireframe, fix one bug at a time. When you uncover a bug, isolate it, fix it, and then verify the fix before moving on.
Read the code in the Interaction tab. For example, you may be 100 percent positive that you set the associated widget to Show, but when reading the code, you may find it is set to Hide.
When relevant, add the Bring to Front and Send to Back actions to cases. Sometimes, the widget you are trying to have do something is simply covered up by other widgets.
If you hit the wall trying to fix a particular bug and getting increasingly frustrated and stressed because of lost time, it is sometimes best to walk away from it for a bit, and then review it afresh.
If you have spent a lot of time on an issue, and still cannot figure it out, try the following:
The first approach to isolate the issue could be: delete the case and start over, or make a copy, delete the original, and slowly rebuild it from the copy. Add one chunk at a time until something goes wrong.
The second approach to isolate the issue could be: start a new RP file, and recreate only the problematic cases from scratch. Don't copy or import anything from the production file. As you rebuild the integration step by step, consider the logic and order of operations.
Generally, the use of copy and paste is a great time saver, but often, it is a source of issues. Look at the original interaction, and see what makes it work. Then look at the pasted version and make sure that all the actions are pointing to the correct widgets.
Ask a colleague for help.
Send the Axure file to Axure support, as they are very helpful.
Axure additionally has a wonderful support forum which you can find at http://www.axure.com/forum/forum.php.
This list reflects some of the common mistakes we keep repeating. Taking the liberty of assuming we are not significantly more stupid than the average Axure user, we think that the reason for repeating some of these mistakes can be attributed to fast pace of work, multitasking, and other very normal causes. So, when you run into a bug, ask yourself the following questions, just as we often do:
Is the action assigned to the correct widget or dynamic panel?
Are you using the correct action?
Do you have the order of events correct?
Do you have an action in your event that is cancelling out what you are trying to do? For example, did you set up a Show action, and then two lines later you have a Hide action? Since the Hide action is after the Show action, Axure will hide the widget or dynamic panel, so you will not be able to see what you are actually trying to show.
Do you have a panel in front of the widget or dynamic panel from which you are trying to invoke an action, and thus, cannot click on it? Make sure the item you want to click on is in front, otherwise you will not be able to click on it.
Have you reviewed the interaction you have set up at the page level and at the widget/dynamic panel level? You may have an action at the page or master level that is cancelling out your widget/dynamic panel events.
Have you initialized global variables by setting their default value?
Are the variables you are using working as intended? The generated HTML prototype includes the ability to observe how interactions change the values of variables. You should know the variable's initial value, and its expected values as the interaction progresses. Click through the prototype, and stop when the variable does not change as expected. Check the relevant case to make sure it includes an action that affects the variable.
Do you have extra actions? As you add actions to a case, some of the initial actions may be conflicting with those added later, or causing some unexpected behavior.
This section is organized by core Axure features and is focused on basic sources of trouble which inexperienced users often face:
|
Category |
Hurdles |
Recommendations |
|---|---|---|
|
Masters |
I have the master on my wireframe but do not see how to create events for it. |
Go to the master and create a raised event to it. To invoke an action in a master, use raised events. When creating a raised event, remember that its name cannot have spaces, and it must be checked in order to be associated with an action. To read more about raised events, refer to Chapter 5, Advanced Interactions. |
|
Masters |
I create the raised event but still do not see it on my wireframe. |
Go to the master wireframe and make sure that the raised event that should be triggered by the action is checked. |
|
Moving widgets and dynamic panels |
Where did the widget/dynamic panel go? |
Check to see if you have it set to a Move To or Move By option. You may think you are moving is to 1200 pixels, but you may be moving it by 1200 pixels. |
|
IF/THEN Statements |
When do I use All versus Any? |
When you use All, the interaction will work only if all the conditions are satisfied. In Axure, "AND" shows in the code. When you use Any, the interaction will happen as long as at least one condition is satisfied. In Axure, "OR" shows in the code. |
|
Adaptive Views |
Why are my views changed when I do not want them to? |
If you have the checkbox Affect All Views checked, all views will now be "tied" together. The checkbox should really only be used if you are in a child view and want your change to apply to the parent view. Be sure to check the checkbox before you make the changes, and uncheck when you are done making the desired changes. |
|
Adaptive Views |
What do I do when I generate the HTML (not preview) and the views do not change? |
This is most likely a settings issue. Go to the generator you are using in the Adaptive Views tab, and click on Generate ALL pages. |