For as long as Axure RP has had the conditions feature, it’s been included in the “advanced” section of our training guide—here’s our current documentation on conditions—and it’s true that conditions are usually a must-have feature if you’re building a prototype with a high degree of interactive fidelity. But the conditions feature itself isn’t inherently complex, and one or two well-placed conditional statements can really punch up the interactivity of your design without sacrificing its elegance. We’ll be looking at a few scenarios like this in our new blog series, Easy Conditions.
First up: form validation. This is one area where the conditions feature really shines. I happened to notice the other day that the homepage of a certain mega-famous social media platform (rhymes with Space Cook) has a form with dynamic validation occupying its entire right half. Form design critiques aside—hey, I guess 1.2 billion daily users can’t be wrong—I decided to see what it would take to rebuild their dynamic form in Axure RP. Turns out it’s not too hard at all when you use conditions.
Click here to download the .rp file and follow along. It’s a good idea to preview the prototype in your browser first to get an idea of of how the form works. Try clicking around or tabbing through the fields, filling in some fields and leaving others blank. You’ll soon notice the system react to your blank fields with a couple distinct behaviors: a red border will appear around any field that’s been left blank, and a red instructional callout will appear when you click back into that field in order to complete it. (There’s also a red error icon that appears in the original form, but its functionality is redundant with the red border, so I left it out for simplicity’s sake.)
Read on to explore the cases configured on the “first name” text field widget. (All fields in the form have similar logic, so we’ll focus on the “first name” field as an example.)
show the callout and hide the red border
(If is selected of first name bg rec equals true):
Show first name callout
Set is selected of first name bg rec equal to “false”
show the red border
(If text on This equals “”):
Set is selected of first name bg rec equal to “true”
hide the callout (always)
Hide first name callout
What we have here are three cases: one on the OnFocus event and two on the OnLostFocus event. Each case has a title (user defined), a condition (shown in parentheses), and one or more actions (shown in green). We’ll start by examining the cases on the OnLostFocus event.
Show the red border
This case has a condition that checks what is written on the text field at the moment the widget loses focus in the browser. (If you see the word “This” in any condition, it means that the condition is checking something about the widget to which the case is applied.) The action specified in this case will only happen if the text on the widget equals “”—those are double-quotes with nothing in between, as in, no text, as in, blank—at the moment the text field loses focus. The action on this case sets the interaction style of a rectangle widget behind the text field to its “selected” style, giving the appearance of a red border. (For more on interaction styles, check out our Interactive Button tutorial.)
Hide the callout (always)
This case hides the “first name” field’s red instructional callout any time the person filling out the form clicks or tabs into the field. I added the word “always” to the end of this case title to point out an important aspect of the case: it happens every time the “first name” field loses focus, regardless of whether the case before it was executed. This case works this way because of its condition, which is “If True” instead of the default “Else If True”. You can toggle the “If / Else If” behavior of any case by right-clicking on the case title in the inspector.
Show the callout and hide the red border
This case’s condition is looking at the “selected-ness” of the “first name bg rec” widget, checking to see whether the “first name” field’s background rectangle has its red border at the moment the field gains focus. If it does, that means that the field was previously flagged as being left blank, which means we’ll want to show the user the red instructional callout for this field to get them to fill it out this time.
The first action on this case does just that: it shows the previously hidden “first name callout” widget. The second action changes the background widget for the “first name” text field back to its default interaction style so that it doesn’t have a red border anymore.
– – –
I’ve explained this scenario to death for the sake of thoroughness, but hopefully the .rp file is intuitive enough to be understood quickly. (It’s almost like an interactive prototype is more efficient at communicating ideas than a page of text … interesting.) With just three conditions, three cases, and four total actions, we’ve put together a pretty sophisticated behavior. Hopefully I’ve convinced you to give conditions a try as part of your next project in Axure RP. Happy prototyping!