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:
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.
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.
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:
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.
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:
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:
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.)
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:
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:
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:
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:
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:
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:
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.
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:
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
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:
With the wireframe updated to support the interaction, we can now move on to the next step.
A quick review of the flow of interactions, as it pertains to the wireframes, is illustrated in the following screenshot:
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.
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.
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):
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:
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:
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.
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:
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…