Open With Multiple Versions of Tableau Desktop on Mac OS X

Do you have multiple versions of Tableau Desktop installed on your Mac?

You might be beta testing the new version, but still need to work with a current version for production work. Wish you could just right-click on a .twbx and choose on the fly which version to open it in?

Well, thanks to Mac OS X, it’s easy. No registry hacking required. (Note that this isn’t supported by Tableau — it’s a Mac OS X feature, so talk to your favorite Apple Genius if you need help.)

  1. Install multiple versions of Tableau Desktop on your Mac. Go to the Applications folder and rename each one with its version so you can keep them straight.
  2. Launch each version at least once. (During first run, Mac apps do things like register with the OS.)
  3. Right-click a .twbx and select Open With > Other…
  4. Check Always Open With and select the version you want to add, then click Open. (The checkbox seems to be necessary to make the option “stick” in the Open With menu. You can change the default version at any time by repeating this step.)
  5. Now, you can right-click and have your choice of Tableau version available at your fingertips.

Enjoy! Post a comment if you have any questions and I’ll do my best to answer when I get a chance.

(If your question is, “how can I beta test the new version of Tableau?” the answer is, contact your Tableau account manager and they’ll be happy to sign you up!)


Unpackage Tableau .twbx Workbooks on the Mac


Tableau Desktop’s .twbx packaged workbook files are archives which contain both a .twb workbook file and the data.

On Windows, Tableau Desktop installs an “Unpackage Workbook” command which is available by right-clicking any .twbx file.

And Tableau Desktop is coming to the Mac! But the unpackage workbook feature is not included in the initial release. As a workaround, you can rename a .twbx file to .zip, then double-click the .zip file to decompress it.

But if you want to be able to right-click (or control-click) a .twbx file and choose “Unpackage Tableau Workbook” on your Mac, here’s what to do.

Warning: this is an unsupported utility!

Download this Automator workflow file, unzip it, and double-click Unpackage Tableau Workbook.workflow. When prompted, click Install, then click Done.

service installerservice installer complete

To use, just right-click or control-click a Tableau packaged workbook and select Unpackage Tableau Workbook.



1. The file does not require a .twbx extension, as long as the file type is Tableau Packaged Workbook.

2. If the service is run on a file other than a Tableau Packaged Workbook, the service will take no action.

3. Files are unpackaged to slightly different destinations on the Mac vs PC. On PC, the .twb goes in the same directory as the .twbx; data goes inside a new folder:

Result on Windows

Result on Windows

On the Mac, both the .twb and the data directory go inside a new folder.

Result on Mac

Result on Mac


Go to ~/Library/Services
Delete the file Unpackage Tableau Workbook
Log out and log back in

Known issue

If you unpackage a workbook that has already been unpackaged in the same location, Automator will throw an unclear error. This is because the shell script doesn’t handle the scenario when a duplicate file already exists. (Repro: unpackage the same workbook twice in a row. To resolve, delete or rename the folder of unpackaged files.)

This is not a very helpful error message

This is not a very helpful error message

What is this thing?

It’s a simple Apple Automator workflow which calls a shell script. Sometime soon, I’ll write another blog post soon explaining the details. I also hope to post the code to github, in case you want to contribute improvements to the community.

If this was helpful to you, please leave a comment and let me know!

If it’s not working for you, feel free to leave a comment, but I make no promises that I’ll respond or be able to help – your best bet is to just follow the uninstall information above.

Benchmarking mobile browser performance



Back in the early days of PC’s, comparing performance was relatively easy: just look at the processor and the clock speed. A 486/33 (with an Intel 80486 CPU running at 33mHz) will perform calculations about twice as fast as a 486/16.

Figuring out performance from mobile device specifications is a little more opaque these days. It can be much quicker and easier to just run a benchmark. 

For web-based applications, one useful benchmark is’s SunSpider JavaScript benchmark

Running this can give you an idea how much of the performance difference between two different mobile devices or browsers is due to raw JavaScript speed.

Sorry, Internet Explorer 8 is NOT going EOL next week



Web developers and users notoriously hate old Internet Explorer versions.

You might think from the web that as of April 8, 2014, Internet Explorer is going to be unsupported, end of life, on its way out, an ex-browser, going the way of the dodo, dead.

Sorry. Not quite.

It is only on Windows XP that IE 8 is going EOL. IE support now follows the support lifecycle of the OS it is running on – so EVERY version of IE on XP is going EOL next week, not just IE8.

IE8 originally shipped as Windows 7’s built-in browser version. IE8 on Win7 (like Win7 itself) is still in mainstream support until January 2015. IE8 on Win7 will be covered under extended support until January 2020.

It’s the latter date – end of extended support – which most IT teams consider to be EOL for MS desktop products, because that’s when they’ll stop getting security updates.

So, if you create software for enterprises, you may have customers using IE8 for years to come.

MAC vs. Mac

Sometimes people refer to a Macintosh computer as a MAC – in all caps.

This is wrong.

Further, it is a sign to Mac users that you don’t really get Macs.

I’ve heard the argument that MAC is the correct parallel to PC. But this is incorrect; PC is an acronym for Personal Computer, while Mac is the short form of Macintosh, just as Dan is short for Daniel.

(There is a MAC acronym – Media Access Control. When you use MAC, that’s what you’re saying. But that’s not important right now.)

Don’t believe me? Check Apple. You’ll see they only ever use Mac – even when combining Mac with other words (Book) and letters (i).

Mac, not MAC

Apple only uses “Mac” – never “MAC”.

So if you want to look literate to Mac users, don’t call it a MAC.

This is one of those things that is like USING ALL CAPS IN EMAILS. While it doesn’t bother some people at all, it really bugs other people.

(Of course, if you’re TRYING to troll Mac users, go right ahead! I know it’s futile to ask trolls to stop trolling.)


Root Cause Analysis reports


So, you’ve investigated a problem, asking why and how.

Now you’ve got to write up a root cause analysis report. And that’s where the art comes in.

A good RCA is one that can, ideally, be used to make changes at the root cause to avoid having this sort of problem occur again.

In some cases, an RCA won’t be able to achieve that goal, but even then it can provide value if it helps make clear how to work around the problem, or why the problem cannot be easily solved.

So a RCA report should focus on what is relevant and actionable for the audience.

In this application crash example, talking about issues around development practices (compiler settings, IDEs, code review practices) might be quite helpful for the developers, but it doesn’t help the end user of the software; they can’t influence the development process. Instead, focus on what is actionable for them. In this example, this could include both staying current on maintenance releases, and making sure the relevant details of the end user’s scenario or environment is communicated to the developers, so they can be included in test cases.

So you might produce an RCA for the customer from this which focuses on those aspects, and doesn’t go down the development path. Of course, it’s still a good idea to share those items with the development team!

Related posts:

Root Cause Analysis: Five Why’s

Root Cause Analysis: Don’t just ask “Why?” — also ask “How?”


Root Cause Analysis: Don’t just ask “Why?” — also ask “How?”


One classic tactic in conducting root cause analysis is to ask “why” something occurred. This is a useful approach! But “why?” is not the only question you should be concerned with. And focusing too much on “why”—especially if it passes into motivation, as opposed to causation—can start getting into a question of ‘who’s to blame’ as opposed to ‘how do we fix this.’

John Allspaw, who runs Etsy’s operations engineering group, talks about doing ‘blameless postmortems’ as a way to improve, scale, and learnEtsy is in the top 50 most-visited websites in the US, top 150 globally, so you may want to listen to his advice.

Having a “blameless” Post-Mortem process means that engineers whose actions have contributed to an accident can give a detailed account of:

  • what actions they took at what time,
  • what effects they observed,
  • expectations they had,
  • assumptions they had made,
  • and their understanding of timeline of events as they occurred.

…and that they can give this detailed account without fear of punishment or retribution.

I was struck, as John described the process, by the frequency of “how” compared to “why” (emphasis added):

  • The goal is to understand how an accident could have happened, in order to better equip ourselves from it happening in the future
  • We enable and encourage people who do make mistakes to be the experts on educating the rest of the organization how not to make [mistakes] in the future.
  • We strive to make sure that the blunt end of the organization understands how work is actually getting done.
  • In order to understand how failures happen, we first have to understand our reactions to failure.
  • One option is to assume the single cause is incompetence and scream at engineers to make them “pay attention!” or “be more careful!”
    Another option is to take a hard look at how the accident actually happened, treat the engineers involved with respect, and learn from the event.

While “why” is an excellent question to help understand causation, chains of events, and motivation, asking “how” can help uncover systemic issues.

Better still, asking “how” can also help you understand what needs to be done to defang those issues. Knowing how a situation can turn out badly can give you the answer to what needs to be changed so that similar situations will have better outcomes in the future. I’ve found that once we understand how a mishap came to occur, it is often immediately clear to everyone what needs to be guarded against. It’s even fairly frequent to have a good idea at how such a safeguard can be implemented.

So, next time you are involved in a root cause analysis, by all means, keep on asking those five whys.

But don’t forget to ask “how?” a few times, too!

Related posts:

Root Cause Analysis Reports

Root Cause Analysis: Ask Five Why’s

Root Cause Analysis: Asking Five Why’s


There’s a technique used in Root Cause Analysis called “5 Why’s.”

The idea is, you define the problem, and ask why that problem occurred. Get the answer to that question. Then ask why THAT happened. And repeat, until you’ve gone at least 5 levels deep.

This trivial example comes from the link above:

You are on your way home from work and your car stops.

  • Why did your car stop? Because it ran out of gas.
  • Why did it run out of gas? Because you didn’t buy any gas on my way to work.
  • Why didn’t you buy any gas this morning? Because you didn’t have any money.
  • Why didn’t you have any money? Because you lost it all last night in a poker game.
  • Why did you lose all your money in a poker game? Because you’re no good at bluffing.

Ok, that’s a fairly trivial example. Sometimes things really are that simple – or even simpler, you might only need two or three why’s to get to the true root cause. (If you find yourself referring to universal constants or physical laws — “because f = ma” — you probably have gone far enough.)

But sometimes things aren’t so linear. Sometimes there is more than one answer to a why. Sometimes, there are multiple why’s to ask of a because.

Five isn’t a magic number; it’s simply to encourage you not to stop at the first, second, or even third level of analysis. Forcing you to go five levels deep should make you go beyond the obvious.

These sorts of complications often arise when doing root cause analysis of complex systems, such as multi-tier software applications.

Don’t be discouraged. And don’t get hung up on finding a tidy linear flow of the questions. Just keep asking why. For example, let’s imagine a root cause analysis for an application that stopped responding:

  • Why did the application stop responding? Because it couldn’t write to the disk.
  • Why couldn’t the application write to the disk? Because there was no free disk space.
  • Why was there no free disk space? Because a process was crashing repeatedly, creating a large dump file each time.

Now, there are several questions which can be asked here. And sometimes, a single question can have multiple answers!

Why was the process crashing? The following could all be valid answers in the same case.

  • Because the programmer made a mistake that wasn’t caught by the compiler.
  • Because the programmer made a mistake that wasn’t caught by code review.
  • Because the environment the software was running in did not conform to assumptions made in the solution design.
  • Because the instance had not upgraded to a newer version of the software which included a fix for this bug.

And each of these could in turn have multiple why’s. That’s OK. Don’t get wrapped around the axle. Generate a bunch of these!

If you are having a hard time coming up with why’s, consider the system from a different perspective. If you were looking at it from a system administrator’s perspective, consider it from the point of view of:

  • an end user
  • an infosec engineer – or an intruder
  • a business stakeholder who doesn’t use the software but relies on people who do
  • a tech support engineer
  • a developer

Using these different perspectives can also be helpful if you are only generating why’s that lead to insights which can’t be practically acted upon – for example, because they are outside the scope of control of any of the involved parties.

If you do successfully generate a large number of why’s, it can be helpful to arrange them in a fishbone or tree diagram to show how they relate to each other.

sample fishbone root cause analysis diagram

Sample fishbone root cause diagram (aka Ishikawa diagram) from

Related posts:

Root Cause Analysis Reports

Root Cause Analysis: Don’t just ask “Why?” — also ask “How?”