# Understanding Axure Conditions

One of our Axure training clients asked us to create an easy reference guide for Axure conditions.

When you’re building an interaction in Axure, very often you’ll want to create conditions. Axure can then check if these conditions apply, and fire your case or bypass your case.

Many newbies find the list of Axure conditions a bit overwhelming, but rest assured they are all there for heaps of flexibility. So let’s learn what they are commonly used for (though you’re welcome to find other common or uncommon uses of your own).

# Value

Value is when you want the condition to compare two values to each other to check if they are equal, not equal, greater than, less than, etc… I rarely use this one, but I don’t deal with too many math prototypes. I also often do my math and drop the result in variables so I can easily control the information.

Examples:

• Let’s say you are asking someone their salary and what percent of it they plan to save for retirement. You might decide that if the value of salary times the percent is less than a certain value, you’ll show them a message saying they’re not saving enough.
• If you only wanted something to appear when people have scrolled down a certain amount, you would use a condition with value to express how many pixels down from the top they should be to see this.

# Value Of Variable

This one is similar to value. The main difference is that one of the elements you’re comparing is what’s in one of your global variables.

Examples:

• Let’s say people have to enter a salary number, you’re dropping that into a variable, and you only want certain math to be done if they entered a number greater or equal to a certain figure.
• This could also be used for text. You might have asked someone in a questionnaire if they are male or female. Perhaps you sent that information to a variable (value of Gender variable = male). You now need to check what they responded so you can show the right set of questions on a different page. You can have a condition for if value of variable equals male.

# Length of Variable Value

If you have dropped some text into a variable, this condition will “count” how long it is. I don’t use this often, but here’s an example of when I once did.

Example:

• I was doing a banking app where when you typed “123,” it would show “\$1.23.” As you typed another number, it would appear from the right and the decimal point would be in the right place. I did this by taking what the user typed, dropping that into a variable, and writing cases that split the string into some of the number before the decimal and some after, depending on how long the number was. To determine how long the number was, I used conditions asking Axure how many numbers were typed. I could then write a Set Text for \$0.0X, \$0.XY, \$X.YZ, etc… One case with its condition for each string length.

# Text On Widget

This condition is best used when you want to “check” what a user has typed somewhere.

Examples:

• You want to make sure a field isn’t blank (not null). You can use a condition of value does not equal and then put nothing in the value. That means as long as somebody typed SOMETHING in there, your condition will be true.
• You can make a field appear to validate by running conditions on what text has been entered. You can check that an email address field likely contains an email address by using a condition for if text on widget contains value @.

# Text On Focused Widget

I don’t use this one. It’s like “Text On Widget” but instead of choosing the widget, you are saying that Axure should choose where the user has clicked the cursor, probably a form field. I tend to write very specific interactions where I might call that field by name, so I wouldn’t need a condition that’s for “wherever the user happens to be focused right now.”

# Length of Widget Value

This one is similar to Length of Variable Value. The difference is that instead of operating on what’s in a variable, you’re operating what’s on a specific widget.

Example:

• I wanted to make it look like as people typed a 140-character tweet, we were counting how many characters they had left. That meant that I needed Axure to help me know how many characters had been typed. That means I want length of widget (or variable if I’m dumping what they type into a variable, but I wasn’t). I created a condition on OnKeyUp to check if length of Twitter Textarea is greater than 140. When it was true, I had it pop up a message saying your tweet was too long. If the length were 140 or fewer, the message was hidden.

# Selected Option Of

If you have used Axure’s widget for a dropdown list, and you want to write a condition based on whether people selected (or didn’t select) a certain value from that list, or a condition based on which value they selected, this one’s for you.

Examples:

• You have a drop down menu of all USA states, but your company only does business in certain states. If someone chooses a state in which you don’t work, you want to pop up a message suggesting they contact your colleague who handles that state. You’d use if selected option of State Droplist equals South Dakota to choose if your case gets set off.

# Is Selected Of

I mostly use this one to have Axure check if a checkbox, radio button, tab, or anything else that can be “selected” or “checked” is checked/selected or unchecked/selected. First you choose which widget you want Axure to look at. Then pick “equals” or “does not equal”… either something is selected/checked or it’s not! Finally, you’re going to pick true or false. This can be a bit confusing at first. True means it IS selected or checked. Someone clicked that tab, checked off that box, chose that radio button. False means it was either never selected/checked or they went and UNselected or UNchecked it.

Remember that for things like this, you may want to write two cases. One is for when someone selects or checks your target widget, and one for when/if they UNselect or UNcheck it. Axure doesn’t automatically assume that unchecking undoes whatever you had it do when it was checked.

Axure 8 introduced interaction events “OnSelected” and “OnUnselected,” which have made some people think they don’t need to write two “OnClick” cases, one for if it’s selected and one for if it’s unselected. I still use OnClick for these IF I want to make sure that humans touched the widget. Otherwise, OnSelected and OnUnselected could be triggered via domino effect… I check this checkbox, it unchecks that checkbox, OH Axure then runs “OnUnselected” on the checkbox that got unchecked. Did I really want that to happen without a human unselecting that? Beware of the domino effect.

Example:

• If someone checks the “agree to terms” checkbox, you want to enable the Submit button so they can finish their form. If they uncheck it, the Submit button should be disabled again. You might start with a disabled button. You’ll then write a case enabling the button, and your condition would read like if is selected of Terms Checkbox equals value true. Just to make sure people aren’t being cheeky and unchecking that, you would also write a case for “OnClick, if is selected of Terms Checkbox equals value false,” disable that button (again!).

# State Of Panel

This condition asks Axure which state of a dynamic panel is the one people can see (or would see if that panel were shown). Dynamic panels are like picture frames that can have one photo shown at a time, one “face to the world” as I like to call it. We can write conditions based on which “face to the world” people can see.

Example:

• In my usual lesson on carousels, we learn to “light up” the pagination dots based on which state of the panel is showing. “If state of panel Carousel Panel equals Message1,” then light up dot 1 (by selecting it).

# Visibility of Widget

I use this one a lot. This asks Axure if a widget or panel can be seen. Is this shown or hidden? True would be yes, it can be seen. False would be no, this is hidden. Takes some getting used to, but if you just think it out each time you go to use it, it’ll get more comfy.

Example:

# Key Pressed

This is a neato one. You can actually “listen” for certain keys to be pressed, and assign interactions to happen when that condition is met. I haven’t used this one much, but here’s how it could work:

Examples:

• The user is filling out a form. She is in a field and then clicks her TAB button. She expects to go to the next field. Your prototype may or may not go to the next or correct field. While the user is in a certain field, you could create an if key pressed equals Tab to then focus on a certain field next.
• Perhaps you are validating fields and you do not want people to be able to type special characters. Maybe you’re a jerk forcing people to fill out forms that match your database rather than parsing what people type and making it easy on them.
• Perhaps if someone types a ~ in a phone number, you want to show an error of some sort.

# Cursor

I haven’t used this yet. It relies on the mouse moving to, on, or away from something. You’d also need to come up with a reason to use this rather than a more typical OnMouseEnter or OnMouseHover. I can only think of one example of this right now!

• One of my students wanted to precisely control how long someone had to hover over a widget before a hover effect happened. For THAT, you would want to use a condition checking if the cursor is still over that widget. I say just use OnMouseHover and don’t get so fancy!

# Area Of Widget

I used this one a LOT. Until Axure version 8, where I still use it but less often. In the old days, the only way to create boundaries for scrolling or moving something was by saying “if this is on top of this,” do something like not letting something move any further. Luckily, Axure 8 now has boundaries inside the Case Editor so I don’t need it for this anymore. But I might still use it in other situations.

Example:

• If you are building sliders on a number line, you could use hotspots to act like boundaries. Think about having a number line with discreet places you want the slider to land. Someone could try to drop the slider between numbers. You can make it more realistic by having the slider move to the closest number. There are functions you could probably write for this, but I keep it visual and drop hotspots on the number line under the slider panel. If the slider gets dropped on a certain hotspot (if area of widget slider is over area of widget hotspot 4), snap the slider back to a certain point by moving it to certain coordinates.

This is great for when you want conditions to only fire if people are looking at a certain adaptive view. This condition lets you choose the Adaptive View.

Example:

• There’s a button in your design, but you need it to do slightly different things if the user is looking at the desktop view vs the mobile view. Or maybe you only want this to work in desktop and you’re not building it out in mobile. You can use a condition for the case that includes “if Adaptive View equals Base” or “if Adaptive View does not equal Phone” and write the case that’ll only work for your Base view. If that case has additional conditions, you will have to add them on and use the Boolean “and,” which means that you want ALL of these to be true for this case to fire.

# Looking for Axure training?

Please get in touch if you are interested in our Axure or UX training.

Delta CX author | Customer Experience Strategist, Architect, Speaker, Trainer. “The Mary Poppins of CX & UX.” Learn more at DeltaCX.com.

## More from Debbie Levitt

Delta CX author | Customer Experience Strategist, Architect, Speaker, Trainer. “The Mary Poppins of CX & UX.” Learn more at DeltaCX.com.