The point of the #MakeoverMonday project is to take an existing data visualization and improve it. But how can you improve anything that “The Economist” creates? They have such a knack for breaking down complicated topics into clean, clear and concise visualizations. So, when I saw that Week 31’s challenge was to makeover charts related to their Big Mac Index, I knew I was in for quite a challenge.
My original idea was to show a table with local Big Mac prices, dollar equivalents and percentage over-/under-valuation, along with a sparkline to show historical currency valuation. I love the way FiveThirtyEight uses highlight tables to draw attention to certain values and patterns in tables (there is a great example in their recent article about mid-term elections), so I started with that. But by the time I got 42 countries in there, each with three different values and a trend line, things looked pretty overwhelming.
So, I started scaling back.
Figuring that the most important number was the percent over-/under-valuation, I stripped out the local prices and dollar equivalents, leaving just a highlight table and a sparkline for each country. I added in a parameter that allowed users to change their base currency and then inserted a link to “The Economist’s” original article into my header for people who wanted to learn more. After applying some visual styling inspired by the menus at Ferris, a restaurant in NYC, I ended up with this:
Matillion – cool name, cool tech. Before I get into the actual tech, I’ve just got to comment: Who comes up with all these company names? It seems like in the entire tech industry, the Coolest Names Award is going to big data. Okay back on topic: What is Matillion, and why should you care? Matillion is an ETL tool that’s available on the AWS Marketplace. It is completely cloud-based, billed at an hourly rate and comes with significant advantages when coupled with Snowflake, Redshift and BigQuery.
We have been using the Matillion for Snowflake with as many of our clients as possible. Here’s why: When you build an extensive data warehouse from the ground up, it can sometimes be tough to hand it off at the end of the gig. Matillion effectively automates most tasks in the ETL process, allowing you to build a data warehouse from the ground up with complex ETL processes all while leaving very few opportunities for routine errors.
Matillion comes with a list of “components” that are used as a toolkit for your ETL journey. These components range from DDL SQL commands to Python scripts, and some of these components are designed to perform some of the most complex of tasks. The predefined components actually generate SQL code that you could drop in your IDE and test with, making data validation so much easier (all while making you look like a SQL guru).
To introduce Matillion, I’m excited to kick off a little project I’m working on. Over the coming months, I am going to relive my cross-country glory days and start prepping for longer-distance races. I’ve been running for about six years, and it’s something that I would like to become competitive in for the rest of my life. As I train, I want you to follow the process with me while I go from regular two-mile runs to my end goal of a half marathon. Along the way, I’ll build a data pipeline that will help me analyze my performance and identify contributing factors to my success.
Throughout this process, I am going to let Matillion do a fair amount of the heavy lifting. To get started, I’m going to build my Matillion project.
Initial Project Setup
Before I can start playing with anything cool in Matillion, I’m going to build a project repository that will host my orchestration and transformation jobs. After logging in to our AWS account and powering on the Matillion EC2 instance, I was able to log in to Matillion with a user account provisioned for me.
Image may be NSFW. Clik here to view.
Now that I’m logged in, instead of joining an existing project on the launch screen shown above, I am going to create my own and lock it down so that only my user account will have access. Go through the form and fill in details relating to your project. This is where Matillion will be granted access to interact with our AWS S3 bucket and Snowflake.
Image may be NSFW. Clik here to view.
Quick overview of the fields to pay attention to:
AWS Credentials – If you leave this as the default, it will authenticate with the AWS IAM that was used to configure the Matillion instance
Account – Snowflake account name
After creating the project, I can test the credentials and begin building.
Pipeline Overview
Now that the project is built, I’m ready to get started. The first thing to do here is to figure out what I want my workflow to accomplish so I can plan what tools to use accordingly. As T. Boone Pickens once said, “A fool with a plan can beat a genius with no plan any day.” In this scenario, I’m the fool with the plan. This project is going to be analyzing data from two sources: The Dark Sky API for weather, and performance data from a fitness iOS app or Fitbit. This will help to figure out how weather conditions impact my performance.
After getting out and running around ’til my face turns blue, I want to upload this data to an AWS S3 bucket on a predetermined schedule (maybe with a fancy Python script Image may be NSFW. Clik here to view.). From S3, I then want Matillion to take the Dark Sky JSON data and load it into a table, then do the same with the workout data. From there, I’m going to let Matillion to build a view with the tables that hold my data. Then, I will connect it to a Tableau dashboard for visualizations.
It’s going to look something like this:
Image may be NSFW. Clik here to view.
Getting the Matillion Job Started
The first step of my Matillion job will be reading files in my S3 bucket and storing their names in an environment variable for later use. To accomplish this, I created an Orchestration Job in Matillion and attached the File Iterator component to the beginning of my workflow. The File Iterator is selected in the screenshot below. The iterator reads through my S3 bucket iw-holt and stores each file name in the variable file_name. Additional functionality allows me to filter the selection with RegEx, which will be useful for this project.
Image may be NSFW. Clik here to view.
This is just the beginning of my data pipeline’s requirements. Over the coming weeks, I will be adding extensively to this project, and I am excited to walk you guys through the process. In the future, expect blog posts about:
Building and loading tables with Matillion (makes working with JSON even easier!)
Using Matillion to clean semi-structured ata
Snowflake’s performance with a live connection to Tableau
Anything interesting I encounter building the pipeline …
If there is anything you would like to see represented in the project, please feel free to drop it in the comments! I will be using Matillion quite a bit, but I will definitely keep my eyes peeled for opportunities to introduce Talend and Fivetran. I am excited to showcase for you guys the power of some of these cloud tools I’ve grown to love so much. Using cloud ETL tools with Snowflake makes something like this not only possible but easy. This will be a great learning experience for everyone observing and potentially could give you guys an example of how to build the pipeline for your own data warehouse!
Portals for Tableau are created and maintained by lazy people. Many people that administer and use Portals for Tableau are also lazy people. This is not a bad thing. In fact, I would argue it’s dumb to do more work than is necessary. As a result, we like to build features that allow us to be even lazier.
Up until now, when you are connecting your portal to your Tableau Server, we’ve completely and unreasonably asked for the Server’s URL in one field and the site in another field. We’ve corrected that problem. You can now copy a link from your Tableau Server, paste it into a specific box, click a button and those fields are automatically populated for you. It’s almost as good as reading your mind to populate the fields for you, but we were too lazy to implement telepathy. Maybe one day.
Every single day, I get emails from former students asking for help with everything from visual best practices to calculated fields. Sometimes the questions are quick while others require more thought. Some may be deceptively simple questions that turn into something more complicated than first thought.
What started as a relatively straightforward question from a student led me into a quest to better understand how aggregations work in conjunction with each other within reference lines.
Here is the question that kicked all this off:
Goran, from a virtual Desktop II class, was trying to compare this year’s monthly sales against last year’s maximum sales.
Note: For the purposes of demonstration, I am using the Sample-Superstore data set that comes preinstalled with Tableau Desktop.
The first calculation I will make will isolate 2018 sales:
IF YEAR([Order Date])=2018 THEN [Sales] END
Then I will make a very similar field to isolate 2017 sales to use in a reference line:
IF YEAR([Order Date])=2017 THEN [Sales] END
When I drag over the 2017 Sales field onto Detail to use it in my reference line, I can change the aggregation to Maximum. Then, when I actually create my reference line, I can change the aggregation of the line to sum.
Let’s take a look at this first permutation of our Maximum Sales on Detail, with our reference line set to the Sum of our Maximum Sales:
Image may be NSFW. Clik here to view.
Our reference line appears at $79,167. If we look at a breakdown of the data, we see that this is the sum of the single highest transactions for each month of 2017.
Image may be NSFW. Clik here to view.
Is this what we are looking for? To really answer this question, we must ask ourselves: What is the reference line that we are really trying to see? A line showing us the total of all those single transactions, or a line at the value of 2017’s single highest month of sales? If the latter is the case, we need to switch around our aggregations.
If we change our MAX(Sales) pill to SUM(Sales) and change our reference line to Maximum, we will now get a line at the value for the single highest month in 2017, December:
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
You can try out many different combinations of aggregations on both your pill and your reference line, but you need to be cognizant of what the business problem is. In this case, since we wanted to compare each month of 2018 to 2017’s highest monthly sales, this combination works.
Make sure whenever you are creating a reference line that the aggregation is correct – and don’t skip the step of checking your work in a crosstab if you want to be sure!
Thank you for the question, Goran, and for the challenge!
“I want to build a Sankey diagram with my survey data, but I don’t know how to even start this. I want to be able to see someone’s response before exposure and after exposure to the test object we are surveying on. Could we hop on a working session and work through this process together?”
If you’ve never heard of a Sankey diagram, they are quite fun. Here’s an interpretation from datavizblog.com:
There are several steps to getting this right, and I’ve outlined them step by step below.
Overview
You need two dimensions that you will be connecting between. Next, you need a way to stretch the data between the two axes. In my example, I only have one point for pre-exposure answers and one for post-exposure answers on the survey. This would result in a straight line, not a curve. To get the curve, you need to use the Sigmoid function with your stretch field along with some table calculation magic. Enough overview – let’s just dive into the steps and see how this all comes together.
1. Data Setup
The first step involves structuring the data so that you have a flow between two dimensions. I only have a single record per respondent, and I need two records to connect in a Sankey. Many survey data sources group the data into one row by respondents – that way, when you look at that respondent in a spreadsheet, you can see their change. This doesn’t support a Tableau Sankey well, so we are going to restructure the data using a custom SQL union duplicating the same sheet. We’ll also place an axis side field for the left and right sides of the chart, as shown in this image:
Image may be NSFW. Clik here to view.
2. Padding
We only have two points of data now, but we need to add some data densification, a.k.a. padding, for all the data we don’t have between these two points. To do these, I start by creating a calculated field called MyPad:
Image may be NSFW. Clik here to view.
Now that we know which side is the left side, we can stretch to the data to the right using bins. Right-click the MyPad field and create bins of size 1. I named my field ToStretch:
Image may be NSFW. Clik here to view.
Let’s see this start to come together. Next, we create another calculation entitled T. I also defaulted the table calculation to use ToStretch:
Image may be NSFW. Clik here to view.
And the last calculations we need before creating the S-curve are the ranking calculations. These will keep our data points correct vertically when we build out the Sankey in a minute:
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
3. Creating the Curve
The mathematical function to create an S-curve is the Sigmoid:
Image may be NSFW. Clik here to view.
We can use Tableau to recreate this function to look like this:
Image may be NSFW. Clik here to view.
We then need to add in our ranking functions to get our curve field correct:
Image may be NSFW. Clik here to view.
4. Building the Viz
Pull the two dimensions you are wanting to connect to the Detail shelf along with the ToStretch bin field.
Change your Mark type to Circle.
Pull T to Columns and Curve to Rows. You’ll notice the Delta letting you know that we will need to update the table calculation to display the curve correctly. Image may be NSFW. Clik here to view.
Right-click on Curve pill and edit the nested calculations like so:
Rank 1 to be Specific Dimensions from Pre to Post to ToStretch, in that order.
Rank 2 to be Specific Dimensions from Post to Pre to ToStretch, in that order.
T to be Specific Dimensions for ToStretch only.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
I now have a Sankey chart that I can start to make formatting changes to. Make the Mark type a Line instead of circles, adding sizing to show how many respondents there are for each line. You might also create two additional charts for the left and right so you can see what the respondent answered pre vs. post-exposure.
Image may be NSFW. Clik here to view.
I hope you find this helpful. If you need help like this, reach out and get InterWorks Assist on your team.
When we hear waterfall charts, we expect to see a visualization showcasing the cumulative effect across various categorical-based data to see the positive or negative change between them. But we have not talked about using a waterfall chart to represent parts of the whole. Pie charts, treemaps or stacked bar charts come to mind when trying to represent proportions and should be considered in addition to this rendition. Ultimately, it’s adding more options to our toolkit. If you came here looking to build a traditional waterfall in Tableau (but an improved version), Ben Bausili has you taken care of. If you are curious about this different Tableau waterfall chart, read on!
I’m going to be using our favorite Superstore dataset to demonstrate this chart. The goal here is to represent all 17 Sub-Categories. 17 elements would be too much to cram into a pie chart or stacked bar chart. Normally, we should consider building a treemap. In our case, let’s concentrate on the waterfall. The first step is to create the waterfall chart.
Starting off with Sub-Categories in Rows and Sales in Columns, we need to do a Quick Table Calculation on Sales using Running Total. We then change our Mark type to Gantt Bar. You should get the result below:
Image may be NSFW. Clik here to view.
Now its time to fill in those gaps. Dragging another instance of Sales onto Size on the Marks card, we make it negative utilizing an ad hoc calculation that fills the gaps in-between our bars. I have also increased the size of my bars so they just barely touch:
Image may be NSFW. Clik here to view.
As a visual best practice, it’s easiest for users to see the items largest to smallest from top to bottom. To do that, we go back to Sales on Rows and click Edit Table Calculation. We utilize Specific Dimensions to get access to the Custom Sort:
Image may be NSFW. Clik here to view.
By doing a Custom Sort by Ascending Sum Sales, we get a modified chart that is easier for our audience to process. I’ve also added Row Grand Totals to the left so the user has a reference to compare to:
Image may be NSFW. Clik here to view.
Let’s hide that Axis and Headers for the Sub-Categories. We are going to add labels to give our user context for each bar instead. We can also do some formatting to get rid of those distracting gridlines and borders. Taking another instance of Sales to Label on the Marks card, we can add a Percent of Total Table Calculation. When possible, avoid using the default label alignment that forces your user to tilt their head to an uncomfortable 90 degrees. We can also employ color to differentiate the Total Bar from the other elements using a diverging palette with Include Totals Checked. With these changes, you should end up with the result below:
Image may be NSFW. Clik here to view.
This rendition of the waterfall chart is almost like a dissected stacked bar chart. It makes it easier for our audience to see each of the Sub-Categories and read each label without overlapping, which would be difficult in a stacked bar. Some pitfalls to watch for:
Be careful with the length of labels. Longer texts will start to overlap the marks.
The smaller Sub-Categories are hard to compare to the total bar due to the distance between them.
We would mainly use a graph like this to focus our users’ attention on the largest proportions. We can draw their attention to the largest sub-category by creating a calculated field and dropping the field to color and using a diverging palette.
Labels on line charts can get messy. To reduce clutter, we are often are faced with reducing the labels to only the end of the line or simply removing the labels altogether. Here’s a simple trick that provides some flexibility with labels on lines. This quick method replaces the line vertices with the line labels, allowing more space for the labels and creating a slightly more direct and minimal graph.
Before
Image may be NSFW. Clik here to view.
After
Image may be NSFW. Clik here to view.
Want to Try? Here’s How.
TL;DR: Create a dual axis with a white circle mark and a center-justified label.
Image may be NSFW. Clik here to view.
Create a dual axis by dropping the same measure to Row again. Right-click the Measure pill and Dual Axis. Don’t forget to Synchronize axes.
Label the mark and center justify the label both horizontally and vertically. Image may be NSFW. Clik here to view.
Change new mark to Circle type from the original Line type and change color to white.And “voila!” A simple and elegant line graph.
Image may be NSFW. Clik here to view.
What if you have multiple lines with varying colors by dimension? No problem! But, there’s an added trick.
Add your dimension to the view.
Create a duplicate field of the dimension you just added. Why? We want our circle mark to be white across all values in our dimension. If we used the original dimension, Tableau would use the same color scheme as the lines. But, we want our circle to be white. By creating a duplicate field, we can assign a new color palette to our dimension while keeping our lines the original color.
Add the duplicate field to color on the circle Marks card and change the color of all your values to white.
Image may be NSFW. Clik here to view.
Notes: This method breaks down a bit when vertices from multiple lines overlap (you’ll get overlapping labels), but you’ll have this issue any time you use labels on a line.
Until now in Portals for Tableau, we’ve basically forced you to allow your users to download a crosstab of each dashboard by using the Export CSV button.
Image may be NSFW. Clik here to view.
If you didn’t want to let your users access this button, the only solution was to hide it with custom CSS. After a few requests for this custom CSS, we realized that we were missing an opportunity to make your lives easier.
The new answer is that there is a backend setting under Settings > Portal Settings > Features > Action Buttons. You can now decide whether you want this button to be shown and easily make the change with the flick of a switch (and clicking the Save button, of course).
Image may be NSFW. Clik here to view.
Feel free to use your newfound power to change it as often as you want. You could even toggle it on and off every few minutes if you want to play pranks with your colleagues. This feature is one more way we are trying to enable you to be yourself, so we won’t judge if you decide to go that route.
Recently, I was required to prepare data in Alteryx and output it into a .Hyper file to create a Tableau workbook. The data that was being utilised looked at past sales and potential future sales. The dataset was a very large dataset, over 20 million rows long and 100 columns wide.
Once the workbook was built in Tableau and published on the customer’s Server, the performance of the workbook was below what was expected of the client. Consequently, there were some performance optimisation techniques required to amend this. It was this process that gave me the idea to write this blog post. One of the main optimisation strategies that could be implemented would be to aggregate the data. In this situation, we were unable to do so as the end user wanted to be able to investigate each individual opportunity or sale.
This post concentrates on increasing the performance of a Tableau workbook by passing calculations built in Tableau into Alteryx. This positively impacts the performance of the workbook, instead of Tableau having to process a logic statement, such as an IF or CASE statement. Tableau will only have to deal with a predefined number, as Alteryx has completed the heavy lifting by calculating the logic statement.
The most important question here is: “What calculations are relevant for your analyses?” Choose the filter calculations that are required for your reports. If not all are covered in this post, the ones that have should act as a stepping stone to creating the remaining calculations.
Breaking Down the Process
This process will be broken into two blog posts. The first blog will be based on creating the foundation Filter Calculations. These are the core of the optimisation calculations. Much of the calculations in the latter stages will be based on these calculations. These will include Date, Date Parse and Boolean calculations. These will predetermine several timeframes. For example, Year to Date, Current Month, Previous Year, etc. Although not all these calculations will be relevant to the user, it is possible to pick and choose the ones needed.
The second blog post will be split into two segments building the single metric calculation and multi-field calculations. This section of the blog is for users who have large data sets and need to increase workbook performance. In these segments, the newly calculated Boolean filter calculations will return a variable value when the filter is “True.” This rationale will be applied to both segments of the second blog post.
Data
For simplicity reasons, a sample data set has been used. The data examines the monthly Sales, Target and Profit. Each row correlates to a month of data. The data is updated on the first day of the month. The data runs from January 2016 until December 2020.
This post has been written in August 2018. It will be taken that all the data up to August 2018 is actual data as the data updates daily, while everything after this is forecasted. This point of when your data will be updated will be talked about in more detail when it comes up in the workflow.
Image may be NSFW. Clik here to view.
Download the data at the bottom of the post.
As mentioned earlier, this segment is laying the foundations for the rest of the workflow and dataset. What work is completed here allows the user to create the calculations in next blog post. The following filter types will be made.
Name
Alteryx Name
Name
Alteryx Name
Actual/Forecast
Actual/Forecast
Current Year Current Month
Filter_Current Month
Current Year
Filter_Current Year
Previous Year Current Month
Filter PY Current Month
Previous Year
Filter_Previous Year
Current Year to Date
Filter_CYTD
Current Months
Filter_Current Month Comparison
Previous Year to Date
Filter_PYTD
Year to Date
Filter_YTD Comparison
To create these, we will need to complete several steps involving the separation of Date as well as creating a date that signifies Today’s Date (or whenever the data is updated).
Step 1
Load the sample data into Alteryx and pull the Formula Tool into the workflow
Step 2
Create Event Year. This will pull the Year from the date field. Ensure that the Data Type is numeric. Use the calculation DateTimeYear ([Date]).
Image may be NSFW. Clik here to view.
Step 3
Create Event Month. This pulls the month number from the Date field. This will range from 1-12. Use the calculation DateTimeMonth([Date]), ensuring the Data Type is numeric.
Image may be NSFW. Clik here to view.
Step 4
Create the Todays Date formulate. This will correlate to the day on which your dataset is updated. In this use case, we’ll take it that the dataset is updated until August 2018 (it’s currently August 2018). So, the formula that will be used is DateTimeToday().
Image may be NSFW. Clik here to view.
However, in many companies, the data can lag by a certain amount of time. In this case, for example, it could be taken that the June 2018 numbers are only available during August 2018, as it takes a month for internal processes to get the July 2018 numbers ready for analysis. The DateTimeFormat calculation would be required as this allows the user to manipulate a part of the date. The calculation DateTimeToday() is manipulated,by deducting 1 (-1) from the month value. This means that the columns Todays Date will return 2018-07-18 rather than 2018-08-18, as seen in the earlier calculation. The full calculation is as follows:
DateTimeAdd(DateTimeToday(),-1,"month")
Step 5
Repeat Step 2 and Step 3 for the new field Todays Date. By this step, the dataset has grown from two columns to seven columns. These columns are the foundation for making the filter calculations.
*Ensure that you are happy with the calculation names here. They should make sense going forward, as to make changes to the names later will mean that edits will be needed for all the calculations that hold these five calculations.
Image may be NSFW. Clik here to view.
Now for the fun part! Creating the filters.
Step 6: Actual/Forecast
This is to differentiate between the actual and forecasted values. The way to do this is to see if the value [Date] is greater then [Todays Date]. If it is, then the value is forecasted. If not, then it is the actual value. This is the only “filter” that has a String data type, the rest of the data types will be Boolean.
Image may be NSFW. Clik here to view.
You can see how important it is to know when the data is updated. In this case, we assume that the data is updated daily.
This calculation is an IF statement with the following syntax:
IF [Date]>[Todays Date] THEN 'Forecast' ELSE 'Actual' ENDIF
Step 7: Filter_Current Year
In the next number of steps, you will see why we parse out the two date fields. For this current year filter, a Boolean calculation will be needed, so ensure that the data type is changed to Boolean for the Filter calculations. This will return either a True or False. In this case, the True will be if the Event Year equals Todays Date Year, e.g. if “2018=2018.”
[Event Year]=[Today Date Year]
Image may be NSFW. Clik here to view.
Step 8: Filter_Previous Year
This is very similar to Step 8. However, we are going to change the Today Date Year by reducing it by one year. Instead of being 2018, the value will be 2017. The calculation will look like the following:
[Event Year]=([Today Date Year]-1)
Image may be NSFW. Clik here to view.
If a filter is required for two years previous from today’s date, then replace -1 with -2.
Step 10: Filter_Current Month Comparison
This is to return a value of True when the Event Month equals the Todays Date Month. In this case, when both values are equaled to 8 (August). Here, Year is not considered, so it will return True for all months equal to, regardless of what year it is. This is a good filter for comparing the current month to this time last year. The calculation for this is:
[Event Month]=[Today Date Month]
Image may be NSFW. Clik here to view.
Step 11: Filter_YTD Comparison
The purpose of this calculation is to see what the sales have been up until the current month of the year. This is good for comparing performance between different years up until the same point. In this case, we will be looking at the fields Event Month and Todays Month. We will only want to return the Event Month values that are less than or equal to Todays Month. In this example, with Todays Month equaling 8, the calculation will need to return Event Months, where the values are 1-8. The calculation for this is:
[Event Month] <= [Today Date Month]
Image may be NSFW. Clik here to view.
Step 12: Filter_Current Month
This filter returns true for only the current month of the current year. It is built using two previously built filters Filter_Current Year (Step 7) and Filter_Current Month Comparison (Step 10). These are used together using an AND statement:
[Filter_Current Year] AND [Filter_Current Month Comparison]
Image may be NSFW. Clik here to view.
Step 13: Filter_CYTD
This calculation works off Filter_YTD Comparison (Step 11). It is combined with Filter_Current Year (Step 8). These are combined using an AND statement:
[Filter_Current Year] AND [Filter_YTD Comparison]
Image may be NSFW. Clik here to view.
Step 14: Filter_PYTD
This calculation works off Filter_YTD Comparison (Step 11). It is combined with Filter_Previous Year(Step 9). These are combined using an AND statement:
[Filter_Previous Year] AND [Filter_YTD Comparison]
Image may be NSFW. Clik here to view.
You can download the packaged Alteryx workflow below.
Stay Tuned for Part 2
The subsequent blog post will examine how to apply these filter calculations to the required values in the data set. It will look specifically at applying the above calculations to one single metric or to multiple metrics at once.
Sarah Burnett’s career in data has taken her all over the world – from New Zealand to London and now to Singapore. Sarah co-leads the Singapore Tableau User Group (with Datasaurus Rex) and is a Tableau Social Ambassador. Jia returns to talk with Sarah about her data (and literal) travels, her involvement in the data community and her favorite Tableau tips. And don’t miss Sarah on Makeover Mondays, Iron Viz and the Tableau Fringe Festival APAC where she’ll be presenting!
Here are all the places you can find Sarah in the meantime
I love cars. The way they sound, the way the smell and the way they feel when you’re cruising down long roads. But sometimes, finding the right car for the experience can be troublesome. Car shopping is a lot like dating. There is a lot of fish in the sea, but when you find the right one, you’re in for the ride. I wanted to create the experience of shopping for a car with Tableau.
How It’s Built in Tableau
By collecting data from various car brand websites, I was able to compile a list of around 100 cars to compare in terms of both fuel efficiency, price and horsepower. I wanted to showcase Tableau’s ability to import custom shapes and using sheets in tooltips. They respectively add a personal touch and give your audience additional insights without cluttering up your dashboard.
For the shapes, I worked with our Experience Consultant, David Duncan, to create simple shapes that would easily register with anyone on the body type of a car and the cost range. I pulled PNG files of car logos from the web to represent each of the cars.
For the visualizations in tooltip, I wanted display the purchasing power of money in getting horsepower when purchasing a specific model. I’m a personal fan of the donut chart, so I set out to make it happen. Since sheets in tooltips get filtered based on the data that the user hovers over, I needed to create a worksheet that essentially had a donut chart for every single car.
Image may be NSFW. Clik here to view.
Afterward, I incorporated it into the scatterplot’s tooltip using the Insert option at the top-right of the dialog box.
Image may be NSFW. Clik here to view.
Now I was able to tell how much engine roar I was getting in my engine for every $1000 I spent. Unfortunately, money does not go directly to horsepower. Additional options drive up the price. That means the more expensive the car, the less horsepower you get per dollar.
Image may be NSFW. Clik here to view.
While this does not factor in every detail of buying a car, such as safety, cost of ownership, resell value, etc., I do hope this has provided you with an interesting perspective on combining a love for cars and data. In the future, I plan on creating a more comprehensive dashboard incorporating those other factors.
It’s August again, which means it’s still hot, but football is here! Personally, I’ve been enjoying a ton of baseball and the gobsmackload of home runs we’re seeing. The World Cup was also simply outstanding start to finish, but football in America means only one thing: 22 warriors on the gridiron. Expectations are high for a surprising number of teams, meaning we should get some tremendous games all year long.
We’re into year five of the Tableau Fantasy Football Draft Kit, and we’re still free! Last year’s draft kit was used around sixteen thousand times, and I’m hoping you’re all back and brought your friends! I’ve incorporated some feedback from last year’s kit, but please don’t hesitate to leave suggestions, questions about usage or how your team performed. You can drop a comment here, email me, post in one of the reddit threads, or on LinkedIn. I try to read them all.
As a reminder, all of my data is sourced from the wonderful Fantasy Football Analytics site, who are kind enough to provide their data and tools.
How to Use This Kit
The kit works very much the same as last year’s. This Tableau viz is meant to be used while you draft your league. The design is simple, and only the most pertinent info is displayed to eliminate confusion.
The draft list can be found in the middle of the dashboard and is the most important part. It shows you which player to draft next base on Value Over Replacement (VOR). More info on VOR is provided below.
At the bottom-right, you’ll see available players per position (non-DF/K) by point expectation buckets. As you take players off the board, the chart will update and show you the remaining talent pool.
The bottom-middle chart shows the top ten teams by total expected fantasy points. This is useful when choosing between players with close VORs. A team projected to score more points will also be more likely to spread those points around better than those that score less. You can filter the draft list by clicking the position spread at the bottom-left and the team list at the bottom-middle.
The draft list is automatically sorted by Value Over Replacement, which is the most important metric in good draft strategies. Each player’s information (team, BYE, etc.), their VOR, expected range of points with consensus target and last year’s actual total points are displayed alongside the relative risk per player. There’s a glossary of these acronyms at the bottom of this post if you need a refresher.
Average auction draft values per player ($200 standard pool), age and years in NFL. Users can toggle between showing the Risk calculation or Auction Value.
I recommend reading through this whole post and familiarizing yourself with the all the acronyms. You might even practice drafting before you do the real thing. It will give you familiarity with taking players off, filtering by position or team and keeping up with the draft in general.
I like to use a laptop when drafting so I can check news and depth charts to avoid injured or benched players. It’s a safe strategy to pick whomever is at the top of the draft list when it’s your turn. Second quarterback is the exception here, but you can do that much later in the draft. I also recommend not drafting a team defense or a kicker. You won’t want more than one of either during the season, especially when you draft.
NOTE: As each player is picked, they need to be cleared from the draft list by clicking their name (or anything else on the row, circles/etc.) and clicking “Exclude” from the pop-up OR by typing a portion of their name in the “Remove Player from Board” box, hitting enter, then clicking the player.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
Standard Scoring Draft Kit
If you don’t know your league’s scoring system, use this version.
Points Per Reception (PPR) Draft Kit
Metrics
Some of the terms you’ll need to be familiar with to use these kits, pulled from the VBR data source:
Rank: Overall rank by VOR.
POS: Position
VOR: Value Over Typical Replacement Player. Used to rank players across positions. Calculated by comparing players’ projected points to a “typical” replacement player at the same position (determined by VOR baseline values). For more info on how VOR is calculated, see here.
Points: Average projected points for a player across analysts.
ECR Rank: Expert Consensus Ranking from FantasyPros.
Pos Rank: Position rank.
ADP: Average draft position.
AAV: Average auction value.
Risk: Risk of injury and degree of uncertainty of players’ projected points, calculated as the average of: 1) injury risk from Sports Injury Predictor and 2) the standard deviation of the players’ projected points and rankings across analysts. Standardized to have a mean of 5 and a standard deviation of 2 (higher values reflect greater risk).
ADP can help you identify if a player is going too early/late in your draft and is a great place to look for value later in the draft. If you’ve been diligently drafting by VOR and have a good team, but you still need an RB or WR on the bench, ADP can help you identify players that are available later than they should be. Your drafting site should be keeping track of what pick number your draft is at all times. If it’s the 100th pick and you see an ADP of 65 available, you should take a peek at that player’s news (linked when you click on a player in my draft kit) to see if there’s something going on with that player. Likewise, you’ll want to avoid drafting an ADP of 65 if it’s only the 20th pick.
Finally, remember that whatever you do on this Tableau dashboard won’t affect your actual draft. You still need to draft your players on your website. Be sure to also keep up with draft pick filtering as players go off the board. If you don’t, you may waste time drafting an unavailable player and scrambling for a replacement.
NOTE: If you’d prefer to download the full workbook and dataset to your desktop, head to this link.
If you’ve evolved to the point where your dashboards are crunching gobs of data and are powerful enough to warrant numerous filters and parameters to drill down for myriad uses, you may have been annoyed with waiting for each filter to be applied before being able to set the next one. Not only do we want to make your Portals for Tableau experience fun when you’re first learning Tableau, we want it to stay that way as you gain mastery. This is where the filter and parameter Apply button comes in.
Instead of applying the filters and parameters as soon as you change them, there is now an option to wait until all of them have been set. Once you’re ready to pepper your dashboard with all of your filter and parameter changes, you can click the Apply button. That will immediately send all of them to the dashboard at the same time so you only have to wait for your dashboard to refresh once.
To turn on this feature, log in to the backend of your portal and then navigate to Settings > TableauServerSettings > GeneralTab and turn on the FilterandParametersApplyButton option.
Image may be NSFW. Clik here to view.
Once enabled, you’ll now see the Apply button below your filters and parameters, just patiently waiting for you to click it.
We’ve all been there: You grind away on a dashboard and spend hours to perfect the look and feel. Slowly, you notice the creeping spinning circle running longer and longer – “but that’s a problem for future me,” you tell yourself. Then comes the demo. Suddenly, you’re talking a lot more than you expected in hopes that the filler in the air distracts people from what is now the slowest dashboard you’ve ever seen.
But hey, I get it! It can be easy to gloss over performance when you’re building something. You just want the data to work, you can’t think about speed at a time like this.
There’s nothing quite as eye-opening as demoing your own work. We all always have to go back to improve speed, but sometimes that can be tedious! I’m here to reassure you that we’re always working on ways to reduce your dashboard’s load time at InterWorks – whether it’s Portals for Tableau, helping with your specific dashboards or even creating a performance checklist. And today’s feature is all about Portals.
To start, we’ll have to explain a bit about the JS API and why we need this new feature:
Tableau’s Default Filter Worksheets Method
When you apply your filters in your Tableau workbook, you add them to specific worksheets – whether that’s applying them to worksheets individually or using the Apply to Selected Sheets.
Portal’s Filter Worksheet Method
When you’re creating a Portal filter, you actually need to do the opposite. The logic here is inverted – when you create a portal filter, it will automatically apply to each and every worksheet on your embedded dashboard. But not every worksheet needs your filter – and if you’re unnecessarily filtering worksheets, that’s adding work to the Portal and Tableau Server that’s not needed!
On the Edit-Filter Backend Portal page, you can add the names of worksheets to skip over when applying your filter. This can be a very big performance gain if you’ve got a long list of worksheets. It’s also likely that if one filter needs to skip all those worksheets, another filter needs to as well.
Enter Filter Blacklists
Now we’ve added one convenient, easy location for you to add in a list of worksheets for your Portal filters to skip over.
Image may be NSFW. Clik here to view.
Navigate to the Tableau section of the backend and you’ll see the Filter Blacklist option. Clicking this will take you to a list of all your Filter Blacklist groups. Let’s go ahead and create a new list by clicking New Filter Blacklist.
Once here, I can now add a list of my worksheet names from my workbook:
Image may be NSFW. Clik here to view.
NOTE: The names you enter on the Edit Filter Blacklist page must match exactly with the names of the worksheets in your dashboard:
Image may be NSFW. Clik here to view.
Now we click Save and we’ve got our blacklist group! On to the final step. Navigate to the Edit-Filter page you want to apply this blacklist to. In the toggle group, enable Use Filter-Blacklist Group.
Image may be NSFW. Clik here to view.
Next, a drop-down below will populate with all your Filter-Blacklist groups:
Image may be NSFW. Clik here to view.
Select the Blacklist-Filter group you wish to apply, and watch your dashboard pick up the speed!
I’m sure we can all relate to the following scenario: A client or boss requests a change to a query, so you plop your hands on the keyboard and start cranking out some SQL. At the end of your last revision, you’re about 75% sure that it’s the correct change. Just prior to executing your changes, a few thoughts run through your mind: Am I going to be stuck waiting for 10 minutes for this query to run? Is the change correct? If it’s not, am I now going to have to wait another 10 minutes to run the original query to compare values?
The normalization of wasted time due to query execution is a very real issue. Up until Snowflake arrived, there was not a way to avoid it without shelling out huge amounts of cash. Sadly, a lot of time working with databases can look like the image below:
Image may be NSFW. Clik here to view.
Snowflake: The Solution
While you might miss your sword fight, I can assure you that the amount of work you can get done in what used to be execution purgatory will make everybody much happier in the long run. Snowflake has built in a handful of tools that are provided at no additional cost to make running queries faster than ever and at an extremely reasonable price. In this blog post, I am going to discuss how Snowflake’s architecture enhances performance as well as how the Query Cache feature gives you the ability to run common queries fast and free.
Architecture 101
One of the big discussions around Snowflake is it’s MPP columnar structure. Columnar databases are designed for quick analytic queries, but there are still columnar databases that require a fair bit of tuning and optimization to actually receive faster query results. Snowflake changed the game by automatically optimizing all queries that run through the data warehouse. In Snowflake’s Cloud Services layer, all query planning and optimization techniques are determined at the time the data is loaded. From the moment you place data in your table, Snowflake begins gathering information so that when query time comes, it knows how to distribute the query across all compute nodes in the most effective way possible.
This means you no longer need to spend countless hours tuning the data warehouse. You no longer need to determine partitions, partition keys and indexes. Querying in Snowflake is truly as simple as finding out what you want the query to return, then drafting a SQL statement. Boom, your life just got ten times easier.
If you don’t trust that Snowflake is optimizing queries in the most efficient way for your data, there’s even a way to double check their work. In the Web UI, after you execute a successful query, it will be stored in the History tab. From the History tab, you can then select that query’s ID and view a visual diagram outlining how it is executing. This helps to identify bottlenecks in performance.
Image may be NSFW. Clik here to view.
Above: Query Profiler example.
Query Cachin’ Out
Snowflake’ query optimization is a great feature in itself, but a big concern around cloud services in general is the pay-as-you-go model. Let’s say one day I have a single group of Tableau analysts querying my database to figure out a business problem. In that situation, I can make a reasonable estimate of what my bill will look like. However, what if I am going to make my database available to hundreds or thousands of employees? Will my bill be exponentially higher?
One of the ways that Snowflake has made cost savings available to the customer is through their Query Cache feature. Query Cache is built into the Cloud Services layer of Snowflake’s architecture. The Query Cache is exactly what it sounds like – run a query, and the result set is cached in memory for quick access. Where they took it a step further is by offering the Query Cache component in the Cloud Services layer, which is not a billed component of Snowflake. Normally, to run queries, you must resume a warehouse. These warehouses consume Snowflake credits by the second, with a minimum of 60 billed seconds. To execute a query stored in the query cache, you don’t need to have an active warehouse – meaning that the query execution is free.
Query Cache in Action
To showcase the Query Cache feature at scale, I built a query that returns about 148 million rows of airline data.
select f.*, aline.*, a1.*, a2.*
from factflights f
left join dimairline aline on f.airlineid = aline.airlineid
left join dimairport a1 on f.originairportcode=a1.airportcode
left join dimairport a2 on f.destairportcode = a2.airportcode;
After executing it one time, the next time I submit the same query, the results are retrieved from my query cache. Here is the history of each time I executed the statement above:
Image may be NSFW. Clik here to view.
Execution went from over a minute to under a second. The great thing about this is that I will be able to access this query’s results for a default of 24 hours or until the underlying data changes – whichever happens first. The Query Cache can be configured to retain query results for 24 hours all the way up to 31 days. The duration of your cache piece is dependent on your account with Snowflake and heavily influenced by how often your data changes. After running this query a second time, I can even go and check out the Query Profiler to see how Snowflake handles the execution.
Image may be NSFW. Clik here to view.
There we have it, a built-in way to run queries at scale for free. This is one of the key features that separates Snowflake from other cloud data warehouse solutions.
To get the most out of Query Cache, there are a few things to keep in mind:
To access a query from the cache, the syntax must be identical.
The underlying data accessed must be unchanged; if rows have been updated or inserted, the query will be executed with an active warehouse to retrieve new data.
The query cannot contain functions that are evaluated at the time of execution (e.g. current timestamp).
You can find Snowflake documentation about Query Cache here.
Why Do You Care?
In a cloud environment, cost saving is a huge factor. Being able to take advantage of the pay-as-you-go model is what has moved businesses to rely on cloud products for mission-critical applications. Snowflake has architected its product to not only save you man hours optimizing queries or tuning databases but to also save compute credits through its query cache feature. Both features pass savings along to the client and help you get the most out of your data warehouse.
This allows businesses to power Tableau dashboards live from Snowflake with insane efficiency and no downside to sharing that dashboard across the entire business. The nature of the cloud implies infinite scalability – a feature that has always been approached with caution. Snowflake has done a great job removing the caution tape from the compute side of the equation, letting you focus on putting the data warehouse to work.
Tableau user adoption is a common topic not only internally at InterWorks but also throughout the community. You can find many interesting blogs, videos, podcasts and discussions about it. User adoption has many aspects, including building Centres of Excellence, building community and scaling, sharing best practices and so on. We started to collect interviews in the form of blogs and podcasts, which we plan to release here in the coming months.
Today, I want to share an interview with Marleen Meier (Quantitative Risk Analyst) and Kristi Blaisdell (Regulatory Reporting Analyst) from ABN AMRO. They will tell their story about building Tableau Community in their organization.
Image may be NSFW. Clik here to view.
Above: Kristi Blaisdell (left) and Marleen Meier (right).
Q: Let’s start at the beginning. What was your Tableau journey like?
Marleen: It all started two years ago. I was working on a project in which I changed the layout of our risk reports. A prototype had been built in Excel, but we needed a tool that was suitable to handle huge amounts of data, like 16 Mio trades a day. My colleagues from the U.S. told me about Tableau and on the same evening, I downloaded the free trial. With my reporting prototype 2.0 in Tableau, I went back to my boss and convinced him that I would need a licence.
After that, I started using Tableau for data checks as well as for risk analysis – tasks I usually did in Excel or with the help of SQL, querying directly on the database. After that, I went to the Tableau Conference. Within three days, I learned so much and met so many other enthusiasts that ever since I am kind of an ambassador within ABN AMRO Clearing. I successfully built a proof of concept and implemented Tableau, followed by many presentations and hands-on trainings.
Together with Kristi, we created a Centre of Excellence and internal user group meetings, conferences, webinars, certificates, etc. The list is long, but the bottom line is that I just love working with the tool and sharing this positivity with my colleagues.
Kristi: My journey with Tableau started in the U.S. when my team was looking for a tool to assist us in analytics and dashboarding. Tableau was one of the top tools in a laundry list of analytics tools. During our proof of concept, I used Tableau to assist me in turning our Client ETF (Exchange Traded Fund) data into insight, assisting us with regulatory questions and sharing more in-depth information with the regulators. Together with four other colleagues, we created a foundation for a Centre of Excellence, where we both learned from one another and challenged each other.
When I moved to ABN AMRO headquarters in the Netherlands, I was enthusiastic to bring Tableau here as well. After participating in the European POC, we finally got Tableau (yes!). From that point, I was one of the co-founders of the Tableau user group (with Marleen) within ABN AMRO Clearing. I have given trainings and presentations to colleagues and joined all the excitement at the 2018 Tableau Conference in Europe. Tableau has allowed me to bring my job to a new level by providing insight into our data, and getting the privilege of working with the tool has been so much fun (who says that about an analytics tool?).
Image may be NSFW. Clik here to view.
Above: The ABN AMRO team at TC18 Europe in London.
Q: How have you created a journey for Tableau user adoption? What actions have you done?
Kristi: We started by inviting a Tableau expert who gave us a short intro to Tableau. After, we created a POC where, over the course of two weeks, people from each department participated in solving their problems and challenges in Tableau. Ensuring most departments were involved increased the level of awareness around Tableau.
After the POC, Marleen and I organized internal community meetings. The first few sessions were more about Tableau in general (the use of ABN colors, connecting to ABN’s data, etc.). We also asked all parties to watch the online videos from Tableau to gain more insight without having to explain the general items. We also created a wiki for the community to ask questions internally. We posted articles, blogs and other useful items we had found – tips and tricks and simpler items that people were having a hard time with.
We created bi-weekly, two-hour sessions where someone would showcase their work, ask questions and get feedback or advice. Since we were all from different departments, the different dynamics were helpful in ensuring someone else could understand their dashboard.
Q: What was the most challenging part in building community?
Marleen: It is difficult to get people to take the time to learn or use the tool. This is either because they don’t get the time from their managers and are too busy with day-to-day business to handle it or it’s hard for them to change from something known to the unknown – leaving the comfort zone. So, from one to the next meeting, it might be that some participants didn’t open Tableau for a month. Then, of course, we can’t book any progress. But I also think we expected too much. Not everyone shares our excitement, so we have to give it a bit more time, be more patient and never give up.
Q: Which actions have you found were the most successful?
Marleen and Kristi:
Meetups within the company! While it may be hard to round up everyone and meet, it helps people get committed to the tool. Also, showcasing someone’s work sparks others to re-evaluate the things they are doing and see how Tableau can simplify their work
A blog that we wrote on the intranet that got a lot of people interested who previously didn’t know much about the tool
Giving Tableau presentations/workshops to other departments with their own data, like ad hoc dashboard building together with the audience
Q: Do you organize workshops or other events to embrace user adoption?
Marleen and Kristi: Yes, as mentioned before, we have the monthly user group meetings where we discuss the status of Tableau adoption within the Clearing. We show dashboards of participants and share blogs, vlogs, webinar, tips and tricks or similar resources. We also encourage people to meet bi-weekly with groups of two-four people to discuss questions, give and receive feedback on dashboards, etc.
Earlier this year, we invited Andy Kriebel who presented his journey on becoming a Tableau Zen Master. We are soon going to have a three-day workshop called “From Idea to Product.” We are also hosting the Netherlands Tableau User Group in September. The invitation is now available here. Join LinkedIn group or community forum to be notified about future events.
Q: How do you measure the success of the user adoption?
Marleen and Kristi:
Feedback surveys
Clicks/views on a dashboard on Tableau Server
How many licenses are being used
Number of dashboards created in production
Feedback from colleagues
Q: Which activities would you recommend to people who are just starting with Tableau?
Marleen: Watch online videos and webinars. I personally think that the videos from the Tableau website and the conferences are especially helpful. But if you are less of a self-starter, I recommend attending online or in-class trainings where you can have your hands on the tool. For example, I took the Visual Analytics course, which is great if you want to create visual best practices and outstanding dashboards. It is also really good if you are planning to get the Tableau Professional Certificate.
Next, questions from other people really helped me learn a lot! The data you work with every day is easy to manipulate, but a great challenge/motivation is to help answer your colleagues’ questions or those from other Tableau users on the online forum. Last but not least, I participated in many Makeover Mondays, which had a similar effect. Unknown data helped me to be more creative, to step out of my “tunnel” vision and explore the tool from different angles.
Kristi: I took the Desktop III – Advanced Calculations during the Tableau Conference in London 2018! I found the course extremely helpful as each time you learn a new “skill,” you are then asked to do a small exercise. This helped me to fully understand what the instructor was telling us to do. The instructors were also great in answering any questions you had or explaining information in different ways. What a great experience it is to be able to have a full-day, “hands-on” training session!
Image may be NSFW. Clik here to view.
Above: Kristi (left) and Marleen (right) at TC18 Europe in London.
For the rest of the 2018, I have made it my goal to produce more Makeover Monday visualisations. I’m always trying to develop my skills, and an area which I’m keen to improve on is the design aspect. My goal is to make beautiful visualisations!
Last week’s (week 33) Makeover Monday dataset was about Anthony Bourdain and the places where his shows took him. Tragically, Anthony committed suicide on June 8, 2018, when he was in France filming his latest season of “Parts Unknown.” Anthony was a fantastic chef and through his TV shows and books, he shared a love of food, culture and travel with his audience.
The Tableau Viz Explained
This dataset contained information about Anthony’s shows and the places he travelled. Using a Gantt chart, I thought this would be the best way to represent the runtime for each of his shows. Looking at this view, it looks as if he was very busy in 2011 and 2012 as there was an overlap of when “No Reservations” and “The Layover” were aired!
Next, I created a map as an easy method to quickly visualise the locations he visited for each of his shows. It’s no surprise that he visited the most cities (258!) in his longest-running show, “No Reservations. “It was only in “Parts Unknown” that he visited every single region at least once, including Antarctica!
Next, I wanted to see the top cities he visited in his shows. The first three cities are all in East Asia. Can’t argue with that as the food is incredible in those places! Finally, I added in a time series to see how many cities he visited across time.
For the colour choices, I actually just used the Tableau default Summer palette. I thought that the colours stood out well and worked against the dark background of the dashboard. Hope you enjoy my viz!
Recreating an inspiring visualization is a great way to learn and stretch the limits of a tool. Recently, Andy Kirk reached out to Twitter followers looking to see if it’s possible to make a grid full of circles like this Nobel Laureates graphic using Tableau. Not only is it possible, it is easy to build with a few steps. Below are the original and my remake. You can also see Andy Kirk’s version on Tableau Public.
If you have a dimension on Rows or Columns and choose Circle as the Mark type, Tableau will arrange the circles along straight lines, not as floating bubbles, by default. This is how it looks:
Image may be NSFW. Clik here to view.
Adding any continuous field to Size will tell Tableau to arrange them like a bubble chart instead. I decided to use a parameter called Size with a value of 1. If that field has the same value for all marks, the bubbles will display as equal-sized dots.
Image may be NSFW. Clik here to view.
That’s all it takes to make this chart type in Tableau.
Adding Up Little Differences
I appreciate Andy’s series, “The Little of Visualization Design.” Small details make a big difference when they’re all put together. While this Tableau viz closely resembles the original, there are some details that can’t be perfectly replicated.
Bubble Packing Method
When every circle is an equal size, some “bubbles” may be closer to others. In some cases, a line of circles will touch each other. In others, there is a wider gap along a vertical or horizontal pattern. These areas are more obvious in larger groups of circles. Also, Tableau’s algorithm produces something closer to a pinwheel pattern than a nice circular group.
Image may be NSFW. Clik here to view.
Checkboxes
It’s possible in Tableau to change the icon on a sheet when you click it, but it’s a complicated workaround that isn’t worth the effort in my opinion. In my version, the active selection is highlighted instead of making the checkmark appear or disappear.
Image may be NSFW. Clik here to view.
Animation
Tableau doesn’t animate marks upon loading or filter change. In this example, I don’t think the animation adds much, but it is a limitation of Tableau over the original.
Custom Font
The Reuters graphic uses Source Sans Pro, available at Google Fonts. Since Tableau doesn’t render web fonts, I stuck with the default Tableau fonts as a close approximation.
Tooltip Sizing
I used Tableau’s viz-in-tooltip feature to achieve the black background on hover and limit the width. The downside is that the height is not dynamic, leaving some extra space at the top and bottom of shorter descriptions. It also leaves a white border which cannot be removed.
Image may be NSFW. Clik here to view.
Original Tooltip
Image may be NSFW. Clik here to view.
Updated Tooltip
Column Gradients
Unlike the example visualization with gradients at the top and bottom of columns, the gray shading in Tableau is one solid color. The gradient adds some visual interest, but I prefer the sharper edges in this case. If you really wanted to, transparent backgrounds would make it possible to use a custom background image behind the data to achieve this effect.
Alternate Layouts
The original lets you choose whether to see affiliations, countries, prize categories or time. Dynamic layout choices are entirely possible in Tableau. I omitted those choices for the sake of time and illustration purposes.
All of these things add up to a less-than-perfect reproduction, but I’m pleased with how closely it matches in the main areas.
In Portals for Tableau, we understand the need to customize the look and feel of your portal for the front-end users. We provide a few different styles that you can utilize to give a unique experience for your users. These navigation types are the standard Top Navigation, Top Navigation (No Subnav), Mega Menu, Side Menu and Mobile Menu navigation displays. To change these settings, navigate to the portal backend and log in. Once there go to Settings > Portal Settings > Layout and select the Navigation Type drop-down field.
Image may be NSFW. Clik here to view.
Top Navigation
Our Top Navigation is the standard for most web sites. This navigation rests at the top of the page.
Image may be NSFW. Clik here to view.
Our menu depth is fixed to display three levels in total. An admin user can set the Top Navigation to either be left or right-aligned. You can also add in your own custom CSS to style the front-end user experience to suit your tastes.
Top Navigation (No Subnav)
This navigation is the same as the Top Navigation, except it does not have a sub-navigation bar under the normal navigation bar. The sub-navigation bar is used to display titles for pages, dashboards, etc. as well as the dashboard action buttons. This menu type combines them all into the Top Navigation bar. Use this if you don’t have many menu items to display.
Image may be NSFW. Clik here to view.
Mega Menu
The Mega Menu forgoes the traditional display of the Top Navigation menu in favor of showing you all the content at one time. It displays a large panel of content that is shown below a menu item. The colors of the Mega Menu use the sub-navigation colors to allow for a contrast with the main menu.
Image may be NSFW. Clik here to view.
Side Menu
When you have too many top-level menu items to display, the Side Menu will come to the rescue. This menu type displays on the left side of your portal. It stretches the full height of the page and allows you to add in many top-level menu items. The navigation from one menu item to the next is all contained inside the menu instead of displaying hidden dropdowns. This allows us to display more than three depth levels. We also add in a breadcrumb navigation trail to navigate back and forth. As with all the menu types, it can be styled to fit your needs with custom CSS.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
Mobile Menu
With all our menus we do use responsive design. You can set a specific width in the backend to display our Mobile Menu. The Mobile Menu will trigger when a resolution matches the value you entered and anything less. By default, we set this to be 1025px wide.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
All these options cover most of the current menu types found on the internet. As more and more unique styles come out, we will continue to add more menu types so that we can provide our customers with options that best suit them.
This post continues from Building Filters in Alteryx for Tableau, Part 1. In this, the foundation filter calculations were built. I advise going through Part 1 before looking at this section. If you would like to follow on with the workflow, it is possible to download this from the first blog post.
This post will be split into two alternative workflows where the filter calculations will be applied to a single measure or multiple measures.
Picking either option depends on the data. If there is only one value that needs to be manipulated, then the single-field calculation is obviously the more time efficient route. Some ideas that should be considered when choosing which route to go down are:
How many fields do you want to calculate?
Will more metrics be added to the data that need the same calculations?
If there are many metrics that need the same calculations, or more metrics need to be added to the data set, then the multi-field route should be taken.
Section 1: Single-Metric Calculations
This will apply the filter calculations to one measure (Sales) in the workbook. The data will only return the value when the relevant metrics are True. In this case, Sales will be the only metric we are using. Examples of the outputs are YTD Sales, Current Month Sales and Running Total Sales.
An IF statement will be written in Alteryx using the Formula Tool for each of the Filters calculations created in the previous blog post. The returning values will return sales values for when the relevant filter is True and NULL when False.
Step 1: CY_Sales
IF [Filter_Current Year] THEN [Sales] ELSE Null() ENDIF
Step 2: PY_Sales
IF [Filter_Previous Year] THEN [Sales] ELSE Null() ENDIF
Step 3: CM_Comparison Sales
IF [Filter_Current Month Comparison] THEN [Sales] ELSE Null() ENDIF
Step 4: YTD_Comparison Sales
IF [Filter_YTD Comparison] THEN [Sales] ELSE Null() ENDIF
Step 5: CM_Sales
IF [Filter_Current Month] THEN [Sales] ELSE Null() ENDIF
Step 6: PY_CM Sales
IF [Filter PY Current Month] THEN [Sales] ELSE Null() ENDIF
Step 7: CYTD_Sales
IF [Filter_CYTD] THEN [Sales] ELSE Null() ENDIF
Step 8: PYTD_Sales
IF [Filter_PYTD] THEN [Sales] ELSE Null() ENDIF
Step 9 (Optional)
It is possible to remove the filter calculations created in Part 1. Now that the required sales calculations have been created, these will be passed through the workflow into the Tableau workbook, meaning the filter calculations are no longer required. Below is a screenshot of the single measure workflow:
Image may be NSFW. Clik here to view.
Section 2: Multi-Field Calculations
Multi-field calculations are an alternative approach when applying the filter calculations to the data values. This approach is suitable when there are several measures that require the same manipulations. These are created using a Multi-Field Formula Tool in Alteryx. Again, an IF statement is used in conjunction with the filter calculations created in the first blog post. However, instead of Sales being included in the formula, the value _CurrentField_ is used.
_CurrentField_ represents the fields that are selected in the Multi-Field Formula Tool. These are selected in the red box in the adjacent image. In this example, it represents the fields Sales, Target and Profit. This alternative workflow allows the users to calculate multiple measures using one formula.
The statement is almost identical to the single-metric calculation approach. However, instead of a specific metric being included (Sales), the _CurrentField_ variable is included. What this represents is dependent on the fields checked at the top of the configuration panel.
Image may be NSFW. Clik here to view.
An example of how this tool works is the following: A user is looking to return only the Current Year (CY) values for each of the three fields mentioned above. The user is looking to calculate the CY values for Sales, Target and Profit, so these three values will be checked in the configuration box. A prefix of “CY_” allows the data to have a similar naming structure for the three new values being calculated. In the drop-down menu below, it is possible to click and drag the required variables into the expression box. The variables under the header Current Field refer to the fields select in the red box. The header Original Fields refers to all the fields in the dataset. All the fields can be dragged into the expression box. In this example, the field Filter_Current Year and _CurrentField_ are used in the formula. Filter_Current Year will be replaced for each of the relevant filter calculations. See Steps 1-8.
Note: the Multi-Field Formula Tool can only hold one formula per tool, whereas the Formula Tool can hold a number of formulas in one instance of the tool.
Step 1: CY_value
IF [Filter_Current Year] THEN [_CurrentField_] ELSE Null() ENDIF
Step 2: PY_value
IF [Filter_Previous Year] THEN [_CurrentField_] ELSE Null() ENDIF
Step 3: CM_Comparison value
IF [Filter_Current Month Comparison] THEN [_CurrentField_] ELSE Null() ENDIF
Step 4: YTD_Comparison value
IF [Filter_YTD Comparison] THEN [_CurrentField_] ELSE Null()ENDIF
Step 5: CM_value
IF [Filter_Current Month] THEN [_CurrentField_] ELSE Null() ENDIF
Step 6: PY_CM value
IF [Filter PY Current Month] THEN [_CurrentField_] ELSE Null() ENDIF
Step 7: CYTD_value
IF [Filter_CYTD] THEN [_CurrentField_] ELSE Null() ENDIF
Step 8: PYTD_value
IF [Filter_PYTD] THEN [_CurrentField_] ELSE Null() ENDIF
Step 9 (Optional)
It is possible to remove the filter calculations created in Part 1. Now that the required calculations have been created, these will be passed through the workflow into the Tableau workbook, meaning the filter calculations are no longer required. Below is a screenshot of the multi-measure workflow:
Image may be NSFW. Clik here to view.
In this example, due the simplicity of the data, the number of columns becomes far larger than the number of rows. As I mentioned at the start of the blog, the main takeaway is to give the user knowledge of how to pass the calculations from Tableau to Alteryx. Not all the calculations will be relevant to the user as the filter calculations will be chosen based on what is needed.
The completed packaged work is available to be downloaded below.
