Engine Works
Under the hood of Alteryx: tips, tricks and how-tos.
If you didn’t catch Part 1, Part 2, or Part 3 be sure to check them out.
We have now learned about the basics of analytic apps, the philosophy of app building (chicken or the egg conundrum), and about the dataset we will be using to build some sample apps. Let’s get started, but first I want to address one final topic before we dive in: UX (something @Hollingsworth loves to talk about).
UX, or User Experience, is very important in analytic app creation as you will be building a way for a user to interact with a workflow without having to build anything within Alteryx. This means we must consider how and why we want a user to interact in each way. Just like an Alteryx workflow, Alteryx analytic apps do have flexibility in the way you can create your interface. A tip here is to keep the app as simple as possible (KISS method = Keep It Simple Superheroes). Here is a great article to go a bit more in depth on UX (which is more than just the UIs we will be building): https://xd.adobe.com/ideas/career-tips/15-rules-every-ux-designer-know/
We have a total of four apps we will be building over the next few parts of this series and we will be starting with:
- Allowing a user to define a range of gas prices and how that group compares to the rest of the group in regards to sales
As I mentioned above, we can accomplish this in several ways as apps are just as flexible as workflows. I can think of three ways off the top of my head (I will post an app with all three to this blog).
- Two Numeric Up Down tools that define the lower and upper range of the gas prices
- Two Text Box tools that give open text typing to the upper and lower gas prices
- One Text Box tool that gives a user the space to put both the upper and lower price in one go
All these methods have their pros and cons that we will dive into as we build. Also, for reference the minimum fuel price in our set is $2.472 and the maximum is $4.468. We are also going to look at sales from an average store perspective over that the whole data set otherwise we would not compare apples-to-apples.
Option 1: Two Numeric Up Downs
The Numeric Up Down tool, used to display a numeric control, is probably the most rigid option and ensures the least number of potential issues by the end user. You can limit the values that a user can put in and can make sure they get exactly what is needed. Passing these values through to the workflow will be the easiest as well.
In the above picture we create a workflow to compare the range we want with any other data summarized and then shown in a Browse (more than likely would need to give a user an output option). Here is how we can set up each numeric up/down:
Lower:
Upper:
For each of these we can set our minimum and maximum to what we see in the data (this can be made flexible if the data is variable. We can also set the increment amount so it will increase at the penny level and also set a default. The app is designed for a default for the lower price to indeed be less than the upper price. This is something we need to ensure happens or otherwise the filter will not work properly in the workflow. The error message you can see in the workflow is there to ensure a user selects a lower price that is truly lower than the upper limit price. Here are the properties we are using to achieve that goal:
You can see in the image that we compare [#1] to [#2]. The order of this is dependent on the order in which you connect the numeric up/downs to the error message tool. In the connections from questions section above you can see [#1] = Lowest Gas Price and [#2] = Highest Gas Price.
The last thing that we need to look at for app properties is the action we want in the workflow. This can be achieved two ways:
- Option 1 – connecting each value to the Q marker on the tool you want to change
- Option 2 – using action tools and connecting them to the lightning bolts of the tool you want to change
Both achieve the desired results but have different ways of achieving the goal. I recommend looking at both options and choosing which you like better.
Option 2: Two Text Boxes
This is the 2nd best option as it gives a bit more flexibility to the end user to provide the value. There is risk in that the user could put in a character that is not a number accidentally, put in a comma instead of a period to separate dollars and cents, or just put something in that doesn’t make sense in terms of app input. Like the above method you can attach the tools to the tool directly, but if there are any bad characters this will fail, so we will show how to account for that.
Notice here there is a way to put in a default value so that the end user knows what they should follow as far as format.
The error message that accounts for the comparison in prices is different as the values passed from a text box will be strings.
We will need to add additional errors to ensure the formats of the entries are in a price format: some number of digits followed by a period followed by at most 3 more digits.
Option 3: One Text Box
This is the least viable option as there is the most risk for issue for a user to input. You would need to know there will be a character that separates the 2 prices but could be deleted or changed to something your workflow would not handle.
Not only will we need to do some regex to check the prices are in the right order, but then we will also need a check to ensure the prices are without error. I will not be diving into the regex for this error checking as this option should be the last choice for any developer.
The last piece of the puzzle is to look at the UI and make sure we like the layout and add any additional information for the end user. You will want to make sure you view your interface designer in Alteryx Designer:
I also like to make sure the interface designer is always visible (personal preference) and put it with my results pane:
Now that we have Interface Designer present, we will look at the design of the interface and one setting so we can test in designer specifically.
The first tab in interface designer shows us the UI without any interaction so we can modify how it looks. The order of things, building features inside one another (see in our future app build blogs), and adding additional groupings or text.
I want to add additional text to give the end user some instructions for how to use this app. To do this we will first hit add and then label. Once a label is inserted, use the arrow keys on the right hand side to move it to the top.
Add any flavor text you would like and you can see mine below:
Above I highlighted the tab name as I clicked on it and changed it to say Gas Price Input versus saying Questions.
One last edit we want to make (so you can test the app and see output is in the properties pane of the interface designer (the gear icon). Once there, the only change needed is to ensure the Browse results are displayed upon a successful run (see below):
Depending on how many tools you put into your canvas (and how many Browses) you will need to make sure the ending Browse is the one that is displayed.
Beyond those changes, feel free to add/modify/adjust as you see fit and enjoy playing around with the UI, workflow, etc to show different analyses based on gas prices. Please comment on this post with what you build! I would love to see what different people come up with. The next app build will be an app that allows a user to input a set day count pre-holiday to analyze sales trends. See you then!
