How-To Tableau

The Most Important Tableau Concept Of All

I don’t care what anyone else says when it comes to the most important Tableau concept. Ok, maybe that’s a little harsh… but for me, there is one that trumps all. This concept drives every single calculation and visualization on a dashboard. If a developer doesn’t understand it, it will cause wildly inaccurate analyses to be published. It’s the most frequent cause with newer developers as to why Tableau is “doing this weird thing”.

It’s the number one issue I come across when troubleshooting other peoples’ dashboards. It’s also the number one thing that beginners struggle with. As soon as a beginner masters this concept, it immediately catapults them into intermediate or expert territory. This is because of the creative options and intentions it opens up. So what is it?

Level of Detail

That’s right, you’ve heard it before. If you haven’t been around Tableau long, you’ll probably think it’s just those fancy expressions you’ve heard about but try to avoid using. Unfortunately or fortunately, it’s actually much bigger than just level of detail expressions. It’s the entire conceptual framework that impacts how and where data is aggregated and rendered in Tableau.

In case you skimmed over it, let me repeat. Level of detail is the entire conceptual framework that impacts how data is aggregated and rendered in Tableau.

The terminology here might be a little different than what is expressed officially by Tableau. Tableau talks more about aggregation, granularity, etc. For me, the level of detail concept encompasses these other concepts. At the finest level of detail, you’ll have no aggregation and the highest possible granularity. At the broadest level of detail you’ll have the maximum possible aggregation (like table calculations) and the lowest granularity. Ironically enough, granularity actually has the words “level of detail” in its second dictionary definition.

So ultimately, level of detail is the result of the combination of aggregation and granularity settings on your dashboard. You can have a row level of detail, an aggregate level of detail, or a table level of detail. Depending on your calculated field, you can force aggregation at a certain level of detail.

Why It’s So Important

There are many subtle and not-so-subtle ways Tableau allows a developer to control the level of detail in which data is aggregated and rendered. Through calculated fields, a developer can make:

  • relatively static calculations using Level of Detail expressions
    • this is explicit control of the Level of Detail displayed by Tableau
  • dynamic calculations that take place at different levels in the data
    • row level
    • aggregate level
    • table level
      • this includes selecting the level in which table calculations compute and are relative to
  • through the “Aggregate Measures” option in the Analysis menu

Knowing exactly how Tableau will handle aggregations and granularity will tell you exactly what level of detail your analysis is taking place. Is your measure being aggregated? Is it aggregated by a specific dimension? Is your dashboard visual being rendered for the entire data set or just the current year? There are tons of situations where you have to know what level of detail will be calculated and displayed on your dashboard. That way you can know that it is time for a fixed level of detail or not.

A common error I see with beginners is a claim that “Tableau is calculating things wrong”. They’ll run a calculation in Excel to check an average or sum after filtering on a column. This won’t match what Tableau is displaying. 99% of the time it’s because Tableau is aggregating at a different level of detail than expected because of the dimensions on the dashboard.

So How Do I Get Better

  1. Look at advanced dashboards on Tableau Public
  2. Practice recreating those dashboards
  3. Check out blogs that have tutorials about Aggregation and Level of Detail expressions
  4. Read the Tableau documentation on Aggregation and Level of Detail expressions

Meta Tableau

My Top Upcoming Tableau Features in 2020

Have you ever seen the Tableau Coming Soon page? If not, you should check it out. It gives you a good idea of where Tableau is focusing their efforts and the direction of the platform. As someone who works with many products within Tableau’s platform, here are my top upcoming features. These are the features that I think will have the most impact on what a developer can do in Tableau!

1. IN operator for calculations

Tableau seems to be closing the gap that exists between its existing functions and what is available in Excel and a few programming languages. It’s still missing a few things (check out number 2 and 3 on this post I made earlier), but it’s getting better.

2. Search improvements in the Data pane

With the new relationships feature in Tableau Desktop, the data pane has changed slightly to accommodate how those relationships interact with the dashboard . There is no longer separate windows for Dimensions and Measures, which can be quite the shock for those who have used Tableau for several years or more. It looks like Tableau will be reaching a middle ground though. They’ll be keeping the changes to the data pane, but adding filters to search.

3. Web authoring improvements

For those who do their authoring on the web, you might have run into some limitations compared to Tableau Desktop. There are some big game changers coming though. Say hello to data source and viz filters, a big improvement for those looking to build more functional dashboards without leaving the web.

4. Stale content management

Do you have a large deployment? A bunch of sites and data sources? Data management is one of the top pain points for organizations. Entropy is always increasing and this stale content feature will help fight wasted space and mess on your server.

5. JavaScript API updates

As Tableau usage has grown, different users have appeared and increased their voice. As business usage grows with Tableau and organizations look to sell dashboards externally, software developers become more and more involved. Look for some big changes with many of the APIs, allowing for greater customization in look and behavior.

6. Tableau Bridge improvements

This really depends on your deployment and use cases. Tableau Bridge is getting a boost to access VPC (Virtual Private Cloud) data. Think AWS, Redshift, Snowflake, etc. that can only be accessed within a private network.

7. Data Quality Warnings

If you’ve ever developed a dashboard with an old data source, the pain of finding out that it’s no longer relevant makes this upcoming feature your dream-come-true. Users will be able to see data quality warning in Tableau Desktop with a little warning symbol.

8. External Assets list

Ever wonder what was being uploaded in packaged workbooks? If your user checks the “Include External Files” option when publishing to server, those files will now be visible in one list.

Tableau is still implementing ideas from the community at a steady pace. As long as they keep building the most asked-for features alongside the new products that grow their company, they’ll be in good shape. As soon as all of the new features are clearly driven around increasing the bottom line rather than considering the biggest user headaches, that’ll mark the peak of Tableau. For now though, it’s smooth sailing!

How-To Tableau

Making a Direct CSV Download Button For Tableau Server

Note: As of June 2020, URLs in Tableau Public dashboard no longer function properly.

Note 2: Updated again on Aug 13th, 2020. URLs work again in Tableau Public but this CSV export method does not work in Tableau Public. It still works in Tableau Server and Tableau Online.

Tableau has a standard out-of-the-box way to download data from workbooks (if permissions permit for the user). But for new users who are just clicking on a URL to view a dashboard, they don’t want to learn new menus to figure out a simple export. So if you want to give an easy, 1-click option, you can add a button with a link. This can be configured to download specific worksheet data or the full data set. For this demo we’re just going show how to download the whole data set from the first sheet displayed on the dashboard.

Unfortunately, URLs aren’t working in Tableau Public as of this publishing, so you’ll have to try it out on your own server.

Other Ways

There is a Tableau JavaScript API that will allow you to add this functionality as well. The best use case for this is if you are embedding dashboards in a portal or other web page where you can control the code. I won’t go into the details here, Tableau has a nice example that you can check out:

Meta Tableau

Why Tableau Metrics Is a Game Changer

With the release of Tableau 2020.2, the Metrics feature was released. And it’s one of the biggest impact changes implemented this year. This feature ushers in a significant reduction in dashboard building time for many designs and fundamentally changes Tableau’s position versus competition.

Why This Is Big

Big, bolded KPIs are one of the most common things I implement on dashboards. While these KPIs cover the most important highlights for the dashboard and target audience, users always want one more data point or highlight. This either leads to scope creep or a handful of unhappy users.

Metrics takes care of this. Similar to the Ask Data feature, which allows your most “independent” users to interact with the data directly to create their own ad-hoc analyses, Metrics gives users a quick way to get the exact info they want. Now, instead of developers making additional views for each and every KPI people want to see, users can be taught how to create their own using this out-of-the-box functionality. Just like your dashboards, they can be refreshed regularly. Unlike your dashboards, users can see a quick snapshot of their metrics in one place on Server compared to going into each and every dashboard. These Metrics can be seen either in a project or in the user’s favorites.

This means less hours spent tweaking dashboards and adding additional KPIs up-top and more time providing deeper insights from the data.

Did I Mention They’re Mobile First?

If you’ve used Tableau on your phone, you know how painful it can be. Most of the time developers aren’t focused on their dashboards’ mobile layout and interactivity. Target users usually are accessing dashboards through their computer. But the BI community is catching up to consumer trends, and mobile is becoming more dominant every day. Executives might only carry their phone and a tablet on trips, and don’t want to go through clunky dashboards designed for laptop screens.

Tableau realized this and Metrics handles this shift. It’s meant for mobile devices, so it just works. That’s a huge step and a big hint as to where the Tableau platform is heading.

Repositioning Against Competition

PowerBI dashboards have a very specific boxed look. This lends well to the familiarity business users have with products like Excel. Usually you’ll see a few top KPI boxes with some bar charts and/or a map. Tableau dashboards seem to vary further in their design and doesn’t necessarily encourage this type of layout with its dashboard layout builder.

Tableau Metrics moves further into this look and feel that is familiar to business users. A big KPI with a small bar chart or line chart. It shows Tableau (at least on mobile) is repositioning its product slightly to encourage a more business-user centric design. Once again, they’re pushing the big important number with small trend look that many executives like to see.

Summing It Up

Tableau is heading towards mobile-first functionality, eliminated the low-hanging developer fruit of KPIs on dashboards, and further integrated Ask Data type functionality with a few clicks on a dashboard. While I would’ve considered Tableau more of a general purpose data visualization tool, I believe they’re focusing their product roadmap towards the standard business use cases.

It is important to note that there are some specific considerations developers need to have in mind while developing their dashboards to maximize Metrics. Check them out here.

Meta Tableau

My Biggest Tableau Desktop Headaches (and Probably Yours Too)

I love Tableau. It’s my hammer that makes everything look like a nail. No it’s not right for everything, but it can do a lot of things really well once you know how to use it. And because of this loving relationship, I also know exactly what I hate about it. Like an intimate relationship with a lover, the overall experience with Tableau is something you want to shout to the world. But also like an intimate relationship, Tableau has those small things about it that really grinds your gears. Kind of like when someone you love makes a little annoying noise after they drink a beverage. Technically it’s not wrong in any way, but you just want to take away every single beverage from them for all eternity so they can never make that noise again. Ok… maybe that was a little far. Anyways…

Tableau Desktop has been the data visualization tool of choice for me for the last 7 years. It has grown from a pretty good tool into an excellent platform. Tableau Desktop in 2020 takes care of so many of the gripes that existed a few years ago in previous versions. Things that were once nearly impossible are just a click of the button. Things like Set Controls and Relationships. Tableau has provided more tools for every step of the process, from simple data blending to completely managed server environments. That’s without even getting into extensions, APIs, etc.

I love Tableau and believe they will continue their track record of implementing user-desired features. Tableau has been one of the best companies I’ve interacted with, who truly takes user feedback to heart and continues to make their product more enjoyable to use. So while these are my current 7 biggest headaches, I can’t wait to see what the future holds for their platform.

My 7 Biggest Headaches

1. Being unable to modify the layout hierarchy from the dashboard layout tab

Tableau has a beautiful layout pane to select objects in the dashboard. You can adjust padding, margin, background color, etc. from here. But you cannot rearrange the objects using the hierarchy displayed in the layout pane.

It feels natural to be able to click and drag an object in the hierarchy and put it somewhere else. This is not the case though, you can only do it on the dashboard itself. If and when this feature comes out, it’ll cut down on dashboard building and reorganizing times and headaches significantly.

2. Not having a PROPER() function

We’ve got UPPER()… We’ve got LOWER()… We do not have PROPER() or TITLE(). Sometimes you can’t control your data source because you don’t have the right permissions. But you need to change a field that’s in all uppercase or all lowercase to something that has the first letter of each word capitalized.

This doesn’t exist in Tableau. It exists in some form in Excel, C#, Python, Java, and more languages. This fact paired with headache #3 makes title/proper cases in each workbook painful.

3. Related to number 2; not being able to define our own functions

Ever use the same calculated fields and functions over and over. Each and every workbook. You open it up and you create another calculated field that does the exact same thing in each workbook.Long calculated fields, like your own custom version of making the proper case from point number 2.

If custom user functions were possible, users wouldn’t have to ask for specific functions to be added. The flow for a user could be much more efficient too.

As a counterpoint from Tableau’s standpoint, allowing users to manage and implement their own customizations like this can do a few negative things. Things like new support requests claiming a bug because a user can’t figure out why their function doesn’t work as expected. Or that this type of functionality would drift the product from user configuration and light development to something more of a user development tool. This could potentially shift the target user for Tableau Desktop, and I doubt Tableau would want to drift from their current pinpointed target user. One last point is that allowing user defined functions could potentially open up security issues. It’s just a whole new bag of worms.

Still, the pros for usability outweigh the cons for me.

4. The limitations of organizing worksheet tabs in workbooks

Simply, we need a way to group and organize tabs differently. The colors are nice, the toggle to change the tab layout is nice, but scrolling left to right constantly for large workbooks is not nice. If you could group tabs into folders or hierarchies just like calculated fields, that’d be great.

5. Restrictions on bulk editing dashboard objects

As of 2020.2, users are able to only format the standard configurations of categories of objects in bulk. For example, you can format all parameters in the workbook by changing its font, color, borders, etc. What you can’t do is select 3 dashboard objects (like 3 worksheets) and adjust all of their padding or margins. Instead, you have to select each worksheet on the dashboard and edit its settings one-by-one.

My back of the napkin calculations estimate that bulk editing of dashboard objects would save me about 15 minutes for each dashboard I have ever created.

6. Lack of hierarchical filters

Hierarchies are a feature for building dashboards already. When you establish these hierarchies in the data pane, it allows users to expand axes to drill up and down hierarchies. A common request and question I get from end users is, “why can’t I drill down in filters?” Or something similar to that.

You can place all of the separate levels of hierarchies as their own individual filters, but cannot have a singular filter where you can select parents and children, or expand the hierarchy to drill down to other levels. From a user’s standpoint it makes sense. You would expect a relationship like a hierarchy to function as a hierarchy on the graph portion, and in the filters. Something like the below, taken from the Tibco Spotfire documentation:

7. Formatting in tooltips

There’s a workaround for this one, but it’s not incredibly customizable and has it’s own limitations. That workaround is creating embedded sheets in the tooltip so that you can do things like control the background color. But to create a custom sheet for every tooltip you wan’t to customize is exhausting and adds baggage to the workbook.

Being able to do some basic things like change tooltip background color and transparency would go a long way. Making the tooltip almost like a page builder or able to accept HTML would be spectacular. I won’t get my hopes up for that last one though, as it would be a huge undertaking for Tableau to develop and support.

Wrapping It Up

Tableau Desktop is a spectacular tool. Whipping up interactive and insightful visualizations for users is 1000x easier than what was around before Tableau, and it’s truly led to a democratization of data visualization and analysis. With that comes growing pains and millions of change/feature requests. These are 7 of mine and maybe some of yours. Selfishly I hope these are the next 7 features on Tableau’s product map.

I’ll soon be posting my favorite features of Tableau since version 2019, as well as my headaches/favorites of Tableau Server and Tableau Prep. So keep a look out for those.

P.S. I had to update the title to reflect that this is specifically about Tableau Desktop. Since Tableau has been expanding its platform which includes more advanced Tableau Server capabilities and an online visualization builder. These offer separate functionalities compared to what I’m talking about in this post with Tableau Desktop.


Data Visualization is Not Even 25% of the Work

What Did You Just Say?

I’m a Data Visualization specialist at this point in my career, and I’ll tell you an unpopular opinion… The visualization part of data projects really isn’t the hardest part of the project, it’s not the most important, and it’s the least time consuming. Even with all of these factors considered, it’s often the most visible and emphasized part of the project (no pun intended) in many businesses. This is wrong.

I’ve estimated that not even 25% of the work on data visualization projects has to do with the visualization. Are there any studies or hard numbers to back this up? Nope. Just an estimation which I’ll go through now.

Estimating a Data Project Timeline

When it comes to a full-scale data project that ends in a visualization, the hard work and complexity happens behind the scenes. Gathering business objectives, setting scope, listing deliverables, data collection, data exploration and availability, data cleaning, data structuring, exploratory analysis, and maybe some additional modeling and data science before we even begin crafting an end visualization. That right there is up to 10 different steps and could be broken down further. If we (wrongly) assumed that each step took the same amount of time, then data visualization only takes 9.1% of the time (1 out of 11 steps).

In reality, the longest and most difficult portion of the project happens in the “unsexy” part. That would be data collection through data structuring. These steps are the bulk of the work. Unless the data set you’re working with is simple or there has already been significant effort in building clean and structured data sources, you’ll spend significant amounts of time exploring and verifying data. The reality is usually about 30-70% of the project timeline is spent in these phases. The other reality is that you’ll go through these phases of the projects several times, since the first few presentations of the data visualization will bring up many more questions on data quality and how the project ended up with the values presented in the data visualization.

What is the amount of time then for the data visualization part? If you have your business questions laid out during planning and you are aware of the analyses that need be done, there are only so many paths to take. There are a limited number of visualizations you can choose. The meat of your data story is already outlined with the business requirements. Sure, you can spend more time digging for additional data stories to tell, or on the UX/UI components to make it look better. But additional analyses are cherries on top of the outlined deliverables. And once you meet a certain design threshold, a slightly better look won’t fundamentally change how the visualization is received.

Why Isn’t The Data Visualization the Most Important Part?

Ok, maybe I was a little harsh. The data visualization portion of a data project is important. Striking out on the data visualization can make a project bust. But an excellent data visualization can’t make up for a poorly executed planning and data collection phase. It can’t make up for bad data science or inaccurate data sets. That’s why it isn’t the most important part. What a good data visualization can do is: surface bad data, surface inaccurate data science methodologies, answer business questions that should have been part of the planning phase, and much more. Yes, data visualization is important in data projects. Maybe 2nd most important, but it’s not the be-all and end-all.

But That’s My Job…

Building impactful data visualizations can provide great value to your organization and data projects. So being efficient and good at what you do can certainly provide great value to your company, job security, and a fruitful career. That being said, if you want to make your job more resilient to economic forces, you need to keep some things in mind.

If you’re a Data Viz specialist like me, you need to constantly work at delivering additional value outside of simply your visualization. The one exception to this would be a consultant hired specifically for data visualizations while everything else is perfectly prepared (ha!). Even as a consultant you’re arguably always better off delivering more value than anticipated for your customer.

But I digress. Deliver extra value. Somehow, some way. Whether it’s through your data visualization or through other parts of the project you’re working on. Having a diverse skillset that provides a significant multiplier of your cost to a company will make you a prized member of your company.

For some this is easy. Maybe it’s because you’re actually a BI developer, which encompasses many more responsibilities. Maybe you’re simply the data person in a smaller organization and therefore handle more of the data pipeline. If you’re not explicitly in a situation that pushes you outside of data visualization, just beware the fragility of your position and the need to diversify your value contribution in order to make your position more resilient. Just because you’re job box has a label doesn’t mean you can’t break out of that box or just pop the top open and relabel it yourself.

Give Me A Parting Analogy

Constructing a building is a great parallel to a data project and its steps. The planning, permits, surveying, laying of the foundation, erecting of the frame, installing the mechanicals, and putting up the drywall and insulation take the bulk of the time. Especially before the frame goes up, how many construction projects have you looked at and said ‘they never make any progress on this, they’ll never finish!’ This is only before you return a couple weeks or month later and everything is finished! It’s not that nothing was happening before that last stretch of time, it’s just that the progress wasn’t visible to the untrained eye.

This is equivalent to the business planning through data structuring part of a data project, especially from an end-user’s perspective. Nothing happens… nothing happens… then boom! The data visualization presents itself with all the work wrapped up into the visible end-product. Like the finishing steps of a construction project, the data visualization is what everyone will see and pay attention to. As long as there aren’t horribly obvious mistakes or incredibly artistic/unique details, most people won’t be too moved. The end-product will simply serve its purpose.

On the flip-side, if the foundation and frame of the construction was poorly or improperly done, the looks and/or functionality of the interior and exterior finishes won’t matter. In fact, the construction will eventually become unusable due to its improper foundations. Data visualizations are no different. Without high quality data, structure, and planning, the whole thing falls apart. Then your visualization answers the wrong business questions or answers the right questions incorrectly.

So remember, get the foundation right and spend the most time on it. It’s the most important part. Then focus on the visuals, because that’s what the people will appreciate.

I’m always looking for feedback, tell me what you think of this post! – Dan


Success! You're on the list.
How-To Tableau

Fixing Empty Spaces in Tableau’s Layout Containers

UPDATE: I’ve made an additional post highlighting some common ways to fix empty spaces in Tableau’s layout containers: Fixing Empty Spaces in Tableau’s Layout Containers: Part Two

If you’ve been using Tableau Desktop or Tableau Public to design workbooks, there’s an issue you most likely have run into while configuring layouts. In fact, there are several posts in the Tableau Community Forums trying to get an answer to this exact problem. All remain unanswered. Post one, post two, post three. As a note, the last version I’ve used as of this post is 2020.1 and the issue was still present on certain dashboards.

Fortunately, I have a solution for you!

To preface this solution, it seems as if this is actually a bug in Tableau, and this is only a workaround to that bug. Hopefully in the near future this is fixed and this post becomes irrelevant!

The Problem

You have a horizontal or vertical layout container. Your worksheets for the container are configured to one of the proper dynamic sizing options (fit height, fit width, or entire view). Yet when you put these worksheets inside of the container, there is always a little empty space at the end of the container.

It looks like a little grayed out area with diagonal slashes through it. Like this area highlighted in red (this photo was borrowed from the first linked Community post above):

We see this blank space appear occasionally when configuring layout containers.

The Solution

To preface, before trying the below solution, you should explore the easier and more common fixes first. Most of the time the common fixes cover some small configuration issue that can cause this blank space to appear. These common fixes are:

  • Make sure you’ve configured the worksheets to fit automatically with either Fit Width, Fit Height, or Entire View
  • Clear any manual sizing for the worksheet
  • Remove the sheet and add it again

If none of those work, there is a another solution. This involves a little bit of switching back and forth. Although you probably have the worksheets configured to one of the dynamic options, Tableau is actually using the manual sizing of your axis to determine the maximum size the worksheet will take on when dropped in your container.

So what does this mean? This means you’ll have to do the following in order for your worksheet to fill the entire container.

  1. Go back to the worksheet(s) you want to fill the container with
  2. Toggle the worksheet fit to “Standard”
  3. Manually size the x-axis (if it’s in a horizontal container) or y-axis (if it’s in a vertical container) to be larger than the container you’re dropping it in
  4. Toggle the worksheet fit back to one of the dynamic options (Fit Width, Fit Height, or Entire View)
  5. Ta-da, go back to the dashboard and view your container. The blank space should be gone

As a note, this sizing issue usually only happens when discrete dimensions are on the axis that determines the container fit (x-axis for horizontal and y-axis for vertical). I have not seen it happen in circumstances outside of that, but the fix should be the same. But what if the sizing issue is happening in containers that only have filters, parameters, legends, etc.? Let’s cover it in the next section.

A Related Problem and Solution: Containers with Filters, Parameters, and Other Static Things

So what if this same sizing issue is happening with a container that just hold filters, parameters, legends, or other more statically-sized elements?

The recommended action here is to manually set the height or width of the element to equal the height or width of the container. You can do this by clicking on the drop down arrow for the element, then clicking on “Edit Width” or “Edit Height”. Make sure to use the Layout tab to first find the size of the container you’re trying to fill.

1. Using the layout tab, select the target horizontal or vertical container you’d like to fill.

2. Click on the dropdown for the element you are trying to make fit the entire container.

3. Set the pixel value equivalent to the height or width of the container you are trying to fill completely.

That’s all there is to it! Let me know if you found this useful or if this didn’t solve the issue for you.

Check out Part Two here (common fixes for empty spaces): Fixing Empty Spaces in Tableau’s Layout Containers: Part Two

Success! You're on the list.