Comment on Dashboard design philosophies (vis-a-vis Tableau).

Motivation

This post is motivated by a discussion Steve Wexler started on LinkedIn regarding Stephen Few's recent dashboard design contest. See the discussion here.

Stephen Few's dashboard design contest.

The announcement is here.
The winner is announced here.

Steve Wexler

Steve Wexler is a prominent member of the Tableau community who's been a strong advocate for Tableau and high quality dashboard design, and an innovator who's been instrumental in the popularization and adoption of techniques that enhance and improve Tableau dashboards' communicative and interactive abilities.
Steve's blog is here.
His article on the winner of Few's dashboard competition is here. In it, he wrote:

I’ve been troubled by both the premise and results of Stephen Few’s dashboard design competition as I think it celebrates the number of disparate elements that can be crammed onto a single dashboard rather than champion the display and positioning of the elements that really need to be present (see http://www.perceptualedge.com/blog/?p=1374).

I see it somewhat differently, that the either-or choice implicit in Steve's framing is a false dichotomy, that it's possible, even desirable, to build dashboards that can be information-dense and highly effective at communicating the most salient information. I'll go further: my personal belief is that any dashboard that doesn't do both is only excused on the grounds that the media it's presented in compromises one or both principles.

Dashboard design schools.

There are a couple of schools of thought in dashboard design, that split along the dimensions of size, scale and density of dashboard information presentation.
Please note that as far as I know there aren't any official schools—this is only how I see things, and I don't speak for Edward Tufte or Stephen Few.

The traditional school.

Stephen Few is, I believe, a member of the analytical information design school that holds that effective designs can, even should, be sized sufficiently large enough to be effective at presenting all the information relevant to understanding the particulars and relevant context of the situation under consideration. Edward Tufte is the most famous of this school.

Members of this school advocate the design of rich, comprehensive, highly detailed dashboards that convey the full span of information someone needs to have simultaneously visible in order to fully comprehend the situation.

This design sensibility assumes that the dashboard media are capable of such presentions. In his workshops Tufte has talked about the roughly half-million data point available in simple technologies like 11"x17" paper that can be printed on any standard business printer or presented on monitors with the equivalent size and pixel density capability.

The new school.

On the other side is the small-format school who emphasize the need to design dashboards that can be rendered effectively in small formats, e.g. laptops, iPads, mobile devices, and the like with Web browsing, blogs, and native apps, etc. This school emphasizes the need for a few clear visualizations coupled with rich and effective interactivity to enable the user to easily and effectively browse through an information space exceeding the device's display dimensions.

The divide between the schools seems largely a consequence of the timing of entry into the marketplace of the small-format school. People whose first or highly predominant exposure to analytical information design came from building dashboards with one, two, maybe three or four charts for delivery in blogs or on laptops or iPads, quite naturally assume that their design paradigm is the right and natural one. Those who came to dashboard design in an earlier time sometimes look askance at designs that needlessly waste or misuse space that could be profitably used to communicate information.

Effective dashboard design challenges have substantive commonalities and differences in both camps. Each has its place, and its strenuous advocates. In many cases the believers in one form aren't aware of, or believe in, the strengths and advantages of the other. For example, large-format designs provide the opportunity to keep related information in sight, but they're largely unworkable on small-format electronic media where the consumer needs to look at the information through a small viewport, however easily scrollable. Small-format designs cannot take advantage of the full range of the human visual cognitive field - our binocular field of vision can take in more information than can be presented in small formats.

I believe that the large-format camp is more suitable for the Teacher-in-class scenario in Few's contest. Being able to print out a double-sided 11"x17" page with information front and back would provide the information the teacher needs in a form that s/he could keep readily at hand, and put into a logbook at day-end that would provide the historical record over time. Tufte talks about this scenario—when I took his workshop in D.C. he called it the daily briefing sheet for the Admiral; there was a large military contingent in the audience and I suspect he tailored the example to fit.

About Tableau's Dashboard Design Philosophy

–or– to which school does Tableau most naturally align?

Tableau's design strength lies in the small-format world, creating dashboards with a limited number of charts and tables, with interactive features dominating the expansive use of space for information presentation. I'm not privy to Tableau's design philosophy in this realm, but think it's a natural outcome of its inception and evolution in (relatively) small media, and with the drive to incorporate social media and mobile devices the pressure will be to push improvements out into this space.

I keep hoping that Tableau will incorporate those features that directly address the needs of information-dense information designs.

Chief among these is a sophisticated dashboard layout manager capable of control and precision in the placement and behavior of the components, both individually and collaboratively. Tableau has come a long way in its dashboard design abilities, but it still has far to go. There are plenty of excellent examples of layout managers in the world to use as examples.

Another big ask is for better bullet graphs and true sparklines. Tableau's bullet graphs are overweight and bulky—they need a slimming and toning program. On the positive side any such program will also likely improve Tableau's mark sizing and control abilities, which will upgrade the visual effectiveness of other presentation, particularly bar charts. Simulating sparklines with Tableau line graphs is a coarse approximation of clarity and crispness of Tufte's sparkline original design and specifications. Again, improving Tableau in this area should provide ancillary benefits in other visualization types.

First thoughts post-TCC 2012

The annual Tableau Customer Conference—TCC 2012—was a lot busier and more jam-packed than I thought it was going to be. Last year in Las Vegas there were 1,400 attendees, this year: 2,000 people came. I was on the full go from early on until quite late, barely managed to squeeze in my birthday dinner, and that a day late.

Tableau people are great ambassadors.

As always, everyone from Tableau was engaged, helpful, and committed to helping the attendees have a successful experience. Having worked for a BI software vendor, and with experience of many others, the enthusiasm and passion, the sheer verve, with which the Tableau people approach their work, and their appreciation for their customers, is really good to see.

The game-changing announcement.

This year the big news was transformational:

In-browser, on-Server editing of published Workbooks.

Dashboards and Worksheets can now be edited without downloading them.

This is going to shake up the entire Tableau world once it starts bubbling out. There was a demonstration of it during the main keynote, and it looks great. It opens up the door to all sorts of new possibilities. It also has the potential to dramatically alter the licensing and governance landscapes. I didn't see any information on how they will be affected beyond some recognition that the permissions system will need to accommodate the new Use Cases.

Other stuff.

New chart types

Several new chart types were demoed:

• treemaps are really going to be handy and useful;
• treemaps doubling as bar charts open up exciting new opportunities;
• bubble charts are exciting, particularly if they work with pages and have trails a la Hans Rosling (http://www.ted.com/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen.html);
• word clouds are interesting and certainly crowd-pleasing, particularly for the social mediaistas

Forecasting

Tableau now offers forecasting - with an existing time series data set Tableau will extrapolate into the future. The presentation was very cool - a ragged, highly variable series projected forward, and the projected data was a good visual match. They told us that there's a lot of modeling going on behind the scenes. I'm going to be very interested in seeing how this plays out going forward, how today's projected data can be captured and used as history as time passes in real-world scenarios when Tableau's forecasts can be compared to historical fact-will there be a feedback opportunity to improve forecasting over time?

Desktop

Tableau Desktop has a new Marks card that appears to clarify the visualization characteristics for improved interaction and configuration, making it easier to get what you want.

The People

I didn't get to meet everyone I wanted to, or spend enough time with the people I did manage to get together with. But I did get to spend some really good and fruitful time with some of the people I have tremendous respect for. The Tableau community is one of its great strengths, and I'm frequently humbled by the range and depth the people who make it up.

That's about it for now. More will bubble up once I get ruminating on it.

Unhide that Worksheet!

Cross-posted from Tableau Friction. Please head over there for a look at how easy it is to unhide the Worksheets in your Workbooks.

Mining the Web: Ruby + Tableau = Data Gems from Raw Content

Mountains of information.

The web is chock full of information. Completely, utterly stuffed full of interesting facts about pretty much everything and anything. Most of the information is not in the traditional record-set form of data.

Tableau and the Web

Tableau is a superb tool for exploring record-set data, and for communicating the interesting insights that can be refined from it.

Happily, Tableau is able to recognize some of the Web's information as data and make it available for examination, inspection and exploration.

Sadly, Tableau's abilities in this area are pretty limited, e.g. copying and pasting the contents of HTML tables—and not any old HTML tables, only those that are "well-formed" in a narrow sense particular to Tableau–see here

Mining the Web

Fortunately, pretty much anything on the Web that's regularly formed can be mined and refined into data that Tableau can understand. Tunneling through the Web and extracting the information gems and processing them into data is much easier than is commonly thought, if the right tools for the job are used.

Enter Ruby

Ruby is a terrific tool, as proficient in its domain as Tableau is in its. Ruby was designed to remove the barriers between programmers and their ideas and goals in very much the same way Tableau was designed to remove the barriers to data visualization.

Accessing Web content with Ruby is simple and easy, and transforming the content into data is similarly straightforward, dependent of course upon the complexity and regularity of the content.

"Show Me," you say?

You want proof. Fair enough.

A while back I was listening to some music and browsing through Rolling Stone's 500 GREATEST SONGS OF ALL TIME for inspiration and reminiscing. Each song has its own page, with lots of interesting information and buttons to the previous and next songs in the list.

Here's song #500: link, and below.

As I was browsing through the songs I started keeping a list of them, copying and pasting their names, rank, and artist into a spreadsheet so that I could use Tableau to organize them and answer questions like: which artists had the most songs in the list; how many songs did the Stones have in it; and so on and so forth, and such like.

I wanted to be able to use Tableau to help me answer these questions, along the lines of:

It didn't take long before I was annoyed with all the copying and pasting. It was a huge pain—boring, mechanical, slow; error prone, and unrewarding. Worse, it detracted from my listening enjoyment.

I needed a better way.

What if, I thought to myself, the information in the individual pages is coded consistently across the pages? If so, it should be possible to dig into them and extract the songs' information and capture it as data in a form that Tableau can recognize.

As it turns out, the individual songs' pages are coded consistently and it was pretty easy to write a Ruby program to do exactly what I needed. Here it is:

---

RSSongs.rb

require 'rubygems'
require 'nokogiri'   # Nokogiri in an add-on, installed with: gem install nokogiri
require 'open-uri'

$root      = 'http://www.rollingstone.com'
csvHeader  = 'Record #,Reference,Rank,Artist,Song,Link'
$recordNum = 0

HEADERS_HASH = {"User-Agent" => "Ruby/1.9.3"}

topOfList = 'http://www.rollingstone.com/music/lists'\
            '/the-500-greatest-songs-of-all-time-20110407'\
            '/smokey-robinson-and-the-miracles-shop-around-19691231'

def pull_song songPage
   doc          = Nokogiri::HTML(open(songPage, HEADERS_HASH))
   reference    = doc.xpath("//div[@class=\"listItemDescriptonDiv\"]/h3").text
   artist, song = split_title reference
   place        = doc.xpath("//span[@class=\"ListItemNumber\"]").text
   csvRecord    = "\"#{$recordNum += 1}\","\
                  "\"#{reference}\","\
                  "#{place},"\
                  "\"#{artist}\","\
                  "\"#{song}\","\
                  "#{songPage}"
   $f.puts csvRecord unless $f.nil?
   get_next doc
end

def split_title reference
    parts  = reference.split(/, [\']?/,2)
    artist = parts[0]
    if parts[1] =~ /.*'$/
       song = parts[1].chop
    else
       song = parts[1]
    end
    return artist, song
end

def get_next doc
   nextNode  = doc.xpath("//a[@class=\"listPaginationControls next\"]")
   nextHref  = nextNode.xpath("@href")
   nextItem  = $root + nextHref.text
   if nextItem == $root || $recordNum > 501
       nextItem = nil
   end
   return nextItem
end

puts "Starting with: #{topOfList}"

$f = File.open('RSSongs.csv','w')
$f.puts csvHeader unless $f.nil?

nextItem = pull_song topOfList
while nextItem
     nextItem = pull_song nextItem
end

$f.close unless $f.nil?

---

The Ruby - Tableau Partnership

OK, it's not really a partnership. Neither of the actors knows of the other, so it's more like a happy (from my perspective) convergence of functionality, but that makes a lousy section heading.

RSSongs.csv

The common element in this data mining system is the CSV file "RSSongs.csv". The Ruby script creates it. Tableau accesses it and makes its contents available for analysis. There's nothing magical about the name "RSSongs.csv" either, any other would do but I had a bigger plan and sensible naming is always a good policy.

Go ahead – give it a go.

I hereby release the Ruby code into the wild. It's free, as in speech and beer. Take it. Run it and get your own data set of the Rolling Stone 500 GREATEST SONGS OF ALL TIME.

The usual caveats.

RSSongs.rb works but it's definitely not bulletproof and hardened. Running from my home it purrs along perfectly. Running it from my hotel the data before TCC 2012 it grabs a bunch of the songs and then fails, with an error I think has to do with proxies or the specification of a User Agent in the URL open (see here), but I don't have the time to dig into it.

I hope it works for you, but make no guarantees. If you do use it and make improvements I hope that you'll post them back here as comments so I can learn from them, and hopefully other people can benefit from them too.

The Rest Of The Story

Mining these songs was a really interesting exercise, one that freed me from the shackles of a too-rigid conception of what Tableau-analyzable data is. Once I got this little project working I found myself wanting more and richer information to explore and investigate.

There will be more articles in this vein, starting with an examination of this Ruby code and a description of the process of writing it.

Discussing Deciphering Tables #1

This post is a comment to the previous post: Tao of Tableau - Deciphering Tables #1 - Simple Features that got too long. (blogger only accepts HTML <= 4,096 characters). It started off continuing a thread that Joe Mako started with his insightful comment on that post and then it grew its own legs.

One of the things that I loved about Tableau right from the start is that it made analytical data access and visualization really easy and straightforward. And it got so many things so very right: drag-and-drop and double-click data organizing; using the right type of chart; highly effective color schemes; good data-ink ratio; and so on.

But Tableau, as good as it is, as much as a leap forward as it was, isn't perfect. There are some things that could, that should, be better. For example I've always thought that "Columns" and "Rows" aren't the best terms for the shelves, with "Across" better than "Columns", but there's no equally good simple alternative replacement for "Rows" ("Down" is close) as long as the shelf is itself horizontal, and re-orienting the shelf imposes its own UI space and usability problems. But I digress. A bit.

It almost feels like trivial and senseless grumpiness to point out what are in one sense minor blemishes on such a lovely complexion. But then again, they stand out because their surroundings are so clean and clear and good.

It's sort of like warts on a toad. Nobody cares about a particular wart on a toad because it's already full of them. Any particular wart is pretty much indistinguishable from its neighbors. (I know. They're not really warts. It's poetic license.)

But Tableau was hatched pretty much wart-free. So those it does have look and feel, well, warty when one comes across them.

The examples: "Naked viz" – the worksheet framing lines vanishing when displayed in a dashboard; and "2H Cell Table" – when the Column Dividers are set to "None" in a single Dimensional organization; are like this. In isolation not too bad, maybe even an OK choice for the particular case, but as the exceptions to Tableau's otherwise clear complexion they stand out like as oddities, anomalies. Warts.

About "Naked viz".

From a larger design point of view, the presence of the "Drop field here" flags and framing lines (hints) in an empty Worksheet are enormously helpful in alerting the User to actions they can take to achieve something. I very much like it.

The design breaks down in the larger context of the same worksheet's presentation in a dashboard. Worksheets and dashboards are different environments, and need different presentations. In one sense this discussion is about what the differences should be, and why they should be that way.

Tableau's Design Paradigm

Tableau Software has been very clear in their desire to provide a single environment for creating and consuming Tableau analytics. There are very strong and good reasons for this philosophy.

However, in not displaying the worksheet hints in a dashboard presentation Tableau is violating their basic premise of not separating development/authoring and consuming into distinct operational modes. Unless of course one considers that worksheets and dashboards are different environments, each with its own separate mode, in which case we're discussing what the different presentations of the same viz in the different environments should be.

Fair enough. (But it feels like a thin argument, and once there's a crack in the ice...)

Dropping the "Drop field here" hints in dashboard worksheet presentations makes good sense because there's no dashboard mechanism to add content to worksheets. If the functionality isn't there it makes little sense to hint for it.

I don't like the dropping of the framing lines because, to me at least, it says "there's nothing here", which is a very different message than "this is a place for a viz to be but there's no data being presented". (I wanted to say vizzed but that's pushing it).

There is a great deal of value in providing a consistent presentation for the same thing, to the limit of it making sense, across a product. One of Tableau's great attractions when it came out was that this pretty much held true. It continues to be pretty much the case for Tableau Desktop—in this discussion we're contemplating what differences make sense for a couple of specific cases. On the other hand, Tableau Server has far too many different presentation idioms for similar things; this makes it much less approachable, much more difficult to become proficient with than it should be.

I believe that there is a legitimate need for separating authoring and consuming activities, e.g. the authoring features of a dashboard are intrusive and annoying for someone who's only consuming it. And that opens an entirely different can or worms of another color.

About Smart Defaults.

I'm in full agreement with Joe about Tableau's double-edged nature. When it works, and the great majority of the time it works beautifully, it's a marvel and a delight. It's pruning off the warts that gets a bit vexing.

It really would be useful to be able to configure the smart defaults. It would complicate things, but if it were done smartly the burden wouldn't be too great. I can do a lot of this stuff today with hacking the XML but that is risky and grows wearisome.

Why care about these things?

As much as I love Tableau, and I really do, making my living as a BI/Tableau consultant, I'm aware that it's biggest danger is in becoming one of the products it disrupted. Its singular grace—approachability, usability, low friction, etc., is fragile and easily neglected. If Tableau doesn't take care and continue to expunge its warts, or if you prefer the sand in the gears, it will inevitably lose ground to competitors who are what made Tableau successful: being a faster, easier, less expensive, more effective tools for accessing, organizing, and visualizing data.

Note: this post has expanded into territory better suited to the Tableau Friction post, so I'm moving it over there.

Tao of Tableau - Deciphering Tables #1 - Simple Features

Tableau is extremely powerful, flexible, and easy to use for creating tables. Drag a measure into the pane, a dimension or two into the Rows and/or Columns, maybe double-click another measure, two, or three, and presto! voila! you have a nice table containing the measures' values sorted and organized according to the dimensions' members' default sorting.

Easy, nice, neat, and tidy.

Except that it's not quite so simple. Tableau has a particular philosophy about how tables should be decorated, and this isn't always exactly in tune with what many people expect. This post is the first in a series that examines Tableau's table layout schemes and provides some (hopefully) useful clarity to the whole endeavor, with guidelines for achieving the table presentations you need.

First up, the embedded Tableau Public-published workbook below shows a simple series of tables with the default Tableau presentation along with some notes on interesting aspects. As is pretty clear, for a simple set of very closely related tables there's quite a variety in their presentation.

Powered by Tableau

On Cognitive Fluency and BI

This article from The Atlantic considers the causes of popular misquotations. It contains the following observation:

"Our brains really like fluency, or the experience of cognitive ease (as opposed to cognitive strain) in taking in and retrieving information. The more fluent the experience of reading a quote—or the easier it is to grasp, the smoother it sounds, the more readily it comes to mind—the less likely we are to question the actual quotation."

Cognitive fluency is the hallmark of good BI. Information presented well is easily observed and understood; the barriers to comprehension are low. The same information presented poorly, or even less well, is not as readily absorbed.

Cognitive fluency in BI tools has two primary facets:

• In the tool itself — the tool must be as simple and obvious to operate as possible in order minimize the cognitive load on someone seeking to analyze data;
• In the analytics created with the tool — they must conform to the well-established standards for analytical information design. The defaults must embody AID best practices and the ability to create suboptimal or ineffective analytics must be, if present at all, subordinate and require more effort.

Beware the Either/Or False Dichotomy.

A universe with two mutually exclusive entities is a dichotomy. Nature is full of dichotomies. So is humor—"there are two kinds of people..."

Someone recently posted a poll on LinkedIn with this question: "Was your BI choice a Business or Technical decision?"

From a business intelligence perspective, this question is problematic. It's premise is that there are only two choices-Business and Technical, and that they're mutually exclusive. It's a dichotomy. It's also a false dichotomy.

Asking this question a classic example of preemptive framing - structuring a question in a form that forces responses into a set that's narrower than the actual domain contains.

In any given situation, it's likely that there are Business and Technical components, but it's almost never, nor should it be, an either/or situation. Both realms have an interest in and influence upon the decision, and there are other forces at play.

As a general principle, BI is properly concerned with inquiring into the nature of data, discovering interesting facts and patterns—correlations between elements, and seeking to reveal their causes.

In order to do this, one must approach the situation with an open mind, knowledgeable enough to be able to identify business entities and their relationships, flexible enough to adapt to the situation at hand, and open enough to be able to recognize novel and unexpected things.

The either/or false dichotomy is a simple manifestation of an approach to BI that's inherently flawed, one that seeks to predefine the problem domain into a structure that isn't appropriate.

If you encounter someone who claims to be a BI professional and presents you with an either/or choice like this, or even a longer list of OR choices, you can be fairly confident that, although they might have some tool skills, they're lacking an essential ingredient and you should look for someone else.

Analyzing Tableau's Menu System

With the release of v7.0 Tableau sported a significantly changed menu system in response to user interaction research.

Having better organized menus is a good thing, but major structural changes present a challenge to users for whom the previous menu system is deeply familiar. For them, figuring out where to look for things is in some ways more difficult that for new users who don't have to remap what they already know.

Fortunately, Tableau Software published a table of changes, indicating where to look in the new menu system for old familiar features. Look for it on this page: Where are they now? Some things have changed in Tableau 7.0..

Unfortunately, although only slightly so, this information is presented in a hard-coded HTML table, so it's inflexible and difficult to obtain different organizational views of the information.

So, as is normal practice when faced with new data, there was no question but that it would be interesting to pull the data out of the web page into Tableau so it could be flexibly analyzed, with new relationships revealed and new insights obtained.

The Tableau Public-published workbook embedded below is the result.

This one is better viewed after being downloaded – like many workbooks that deal primarily with textual data the individual vizzes tend to be wider than can conveniently be embedded in a blog post.

Welcome to Better BI's new home.

I've recently moved the Better BI blog here from its old home.

The reason: I can embed Tableau Public-published Tableau content directly into this blog. The old blog didn't have this ability and the workarounds weren't acceptable.

Finding Poetry in Data - Revealing the Rhythm of the Tides with Tableau

We don't normally think about BI being the path to beauty, but sometimes the practical pursuit of information takes us to unexpected places.

Tide Time

The tides do not tick-tock
to our diurnal clock
in their steady march
across the times of day.

Our daily rhythms are joined
in rolling harmonies;
today the rocky spit
is covered at morning coffee,
tomorrow the waves break and foam.

The ocean's song evolves,
the earth, moon, and sun
tuning the great liquid bell
in geologic time.

Two months on the Panamanian Pacific coast. The beach is right below us, the surf a constant presence.

Living right on the ocean has it’s great benefits. The beaches are strikingly beautiful; the surf intermingles black volcanic and white sand into fantastic patterns visible from space (or at least in Google Earth and maps). The ocean has shaped the beaches into a steeply sloped upper section, and a nearly flat lower zone wonderful for all types of activities. A time lapse video of the receding high tide in the early morning is above.

It's hot. Not absolutely blisteringly hot, but hot enough to avoid strenuous outdoor activities during the middle of the day.

The tides are quite high, averaging almost 15 feet. It's important to know the tides so that you can plan your beach activities.

Fortunately, the local community has posted the tides online in a series of web pages, one for each month; March, 2012's page is here.

Unfortunately, the tides are presented in a table that, although it contains the data, is minimally useful. As shown for April 2012 (partial) below, in addition to the obvious analytical impediment of it being a table, each Months' tides are presented on a separate page, and the time and height values are commingled in the table's cells.

I was faced with the classic BI situation: plenty of data, little insight. My challenge was to come to grips with the data and render it in an engaging, approachable form that provides the information people need.

What to do? What to do?

The usual: a little creative data munging to pull the tides data out of the HTML tables (straightforward stuff) and then a little exploratory data analysis with Tableau to see what the data tells us, and how we can create some visualizations that communicate the information we (and others) need.

The data munging stuff is interesting. There are a number of ways available for pulling data out of web pages for Tableau analysis. In straightforward cases a simple copy-and-paste works wonderfully well. Beyond that it can get very interestingly complex. But that's for another post, this one's about poetry and beauty.

Rhythm and Pulse of the Tides

I grew up in Shelburne, Nova Scotia, with one of the best harbours in the world at the end of my yard. Next door was a shipyard where the last of the wooden open ocean commercial fishing boats were built by men using centuries-old traditional methods.

My boyhood was spent at the ocean's edge. I was a pirate, sailor, fisherman, an explorer sailing off for exotic lands.

The tides were as much a part of life as mealtimes, school hours, and all the other regularly scheduled daily activities. Knowing when the tides were high and low, and when to expect them to be bigger and smaller mattered. For me it controlled the size of my playground, for many people knowing the tides was central to their existence.

People born to the ocean know the tides. They don't need graphs and charts and tables and schedules. The tides infuse life, their rhythms organically intertwined.

Here on the Panamanian Pacific coast the information about the tides is much for more prosaic uses, at least for the recreational ocean users. At low tide the beach is available for all manner of recreational activities. At high tide there's much less opportunity, e.g. it's really difficult to run on steeply sloped soft sand. At very high tides there's virtually no beach.
Knowing whether you'll be able to run on the beach at sunup, after coffee and before breakfast, is nice.
Knowing where the tides will be for this week, next week, next month, helps to plan your activities.

How to help people understand the tides? Understanding them not as a list of figures in a table, but as the dynamic, regular, but variable system they are.

How to help people internalize the nature of the tides, so that they can adapt to their ebbs and flows, risings and fallings? Their rhythms.

Enter Tableau

Once the data's available it's straightforward to do some basic visualization with Tableau. Straight away it becomes obvious that there are regular patterns to the tides. High and low tide times move forward from day to day, the time from high to low a little over six hours.

Powered by Tableau

What We See

The tides are the long, slow, resonant beat of the gravitational dance between the Earth and the Moon, with harmony from the Sun. The dance is eons old; the partners know each other well, their movements intimate and comfortable.

Visualizing the tides with Tableau clearly reveals their dynamic structure. Although there is a regularity to their oscillations they are not strictly mated to the cycles of day and night. The tidal patterns stand out clearly in these visualizations, confirming and exposing our innate sense of the tides' haughty disregard for our clocks and convenience.

Daily Tides

Daily Tides shows the tides wrapping themselves around the days in a double helix. The large scale structure mirrors the Earth's rotation, the tides the ocean's response to the moon's beckoning.

The vizualization clearly maps the tides to the 24 hour day, advancing by almost an hour from each day to the next. If low tide at sunup is your pleasure, you're in luck—it comes around every sixth day. If you like high tides, they occur a little over 6 hours apart.

Tide Height

In their celestial dance the moon swings close, pulling the tides higher, then steps back, letting the tides subside. All the while the Sun smiles, attracting and influencing the oceans—sometimes in step with the Moon, sometimes not.

The polyrhythms of the dance—Earth's rotation withn the Moon's orbit, both in Solar orbit, show up clearly in the eternal cycling of the tides high then low then high.

Earth - Moon - Sun Tidal Relationship

source: Wikimedia

BI is not an IT activity.

The gulf between the information needs of real human people and IT is almost universally experienced. It's helpful to recognize the drivers for this situation in order to attempt to correct it. Some of these have been mentioned in previous posts.

There's a fundamental, unrecognized, nearly fatal flaw in the ointment, revealed in the term "IT" itself: the casting of information acquisition, management, understanding, use, and communication as a technological activity, hence "Information Technology".

It's not.

Information is a human property. Casting it into the realm of technology presupposes that it's a physical resource that can be effectively processed with an industrial assembly line approach, given the acquisition of the appropriate machinery, the installation of an adequate industrial-production control model of oversight and management, and staffing up with the appropriate level of resources (not people, revealingly). Once everything's set up, the big green "Go" button can be pressed (metaphorically) and he wheels will turn, the gears will mesh, the data will be pumped in, and the information the business decision makers need will come out.

If you've been underserved by your IT department in getting your questions answered, your information needs satisfied, almost everything you've experienced, all the trouble getting results from IT, is caused by the application of this paradigm. And almost all the solutions suggested are applications of more of the same to address the weakness inherent in the model.

One example: the creation of a Business Intelligence Center of Competency (BICC) as the solution to the problem. It can work, but only if it's not just the addition of another mechanical/operational command-and-control structure with the intention of assuaging the pain causing by the existing environment.

In reality, too many BICC initiatives start out well, then crumble into the same industrial dust as the IT departments whose functions they're replacing. As soon as friction sets in, and it will, usually in the form of someone important not getting something they want as soon as they want it, the impulse is to add mode control systems to manage the submission of requests, the analysis required to understand them, and the prioritization and queuing systems to manage their satisfaction.

All of this misses the essential, central truth: business intelligence - the analysis of business data in order to achieve information and insights from it, and to understand the stories it has to tell, are human cognitive and intellectual skills.

It's important enough to repeat: BI requires human thinking skills. It's not an industrial process.

Business people who need to understand their own data understand this, which is why they use Excel, Access, and increasingly, the new (now 5+ years old) generation of direct-access, low-friction highly effective data analysis and visualization tools to help them understand their data. And they're increasingly frustrated with their IT organizations, which don't get it.

Recasting the concept of BI into its proper form is an essential element in solving this problem. Layering on more industrial management processes only compounds it.

Successful BI occurs when it's recognized as a professional practice, requiring of its practitioners the appropriate combination of aptitude, interest, knowledge, training, and experience. Then the barriers can come down and the myriad distances between real human people and the business intelligence locked up in their data can be freed.

Tao of Tableau - The Amazing Mystery Tooltip

While I was preparing a series of dashboards visualizing the tides on Panama's Pacific coast for ocean activities planning I came across an unusual situation: one of the visualizations I created has two distinct and separate tooltips, only one of which I put in place. The other shows up and there's no way I've found yet to get rid of it. Here's a stripped down version of the workbook showing this oddity:

Powered by Tableau

This is a weird little anomaly. The explanation for its occurrence, as far as I can tell is contained in the "The Explanation" dashboard, and follows here:
As near as I can figure out, the mystery tooltip is an artifact left over from the construction of the visualization.

This viz is a dual axis graph, with the left vertical axis presenting the line graph, and the right axis presenting the marks as circles. This is a pretty common technique for creating line graphs with emphasized marks for the actual data points.

The Worksheet's Tooltip, the desired one showing Event, Tide Height, and Tide Date and Time, is configured for the circle graph. The intention is to provide tooltips that expose the desired information.

The line graph has an implicit tooltip, the Mystery Tooltip.
Given the construction on the viz, it is inaccessible for configuration, and presents itself when the user is looking for information.

The line graph tooltips are activated when the mouse comes within range of one of the graph's line segments. This activation range is wider than the activation range of the circle's tooltips, so the line graph tooltip first when the mouse approaches a circle.

This presentation of the Mystery Tooltip is problematic for a number of reasons, the most important being that it's a source of confusion for the person viewing the viz. Sometimes they see one tooltip, sometimes another; this is bad.

Everyday BI - Tableau helps with learning Spanish

I've been in Panama for a couple of months, and trying to learn Spanish. The classes I've been taking are very helpful and I'm much further ahead than I'd otherwise be.

The past few lessons have become increasingly difficult—we're learning verbs, and there's a fair bit of complexity in the relationships between gender, conjugation, subjects, objects, verb stems (some get changed in conjugation, some don't) and so and so forth and such like.

I've been hand-organizing lists and patterns as we go, and this week reached a point where I see something of the "how" of verbs, and it occurred to me that if I could get a list of Spanish verbs and their characteristics it might be helpful to see if I could use Tableau to collate and organize them, and provide lookup  functionality to help find the right verb quickly.

After looking around the web a bit I came across multiple site listing Spanish verbs. So I picked one that seemed reasonably complete, pulled the data off, munged it up a bit, and created a Tableau workbook, which I then published to Tableau Public (below),

It didn't take long to get this up. The bulk of the time was spent munging up the data (a topic for another post), followed by the inevitable fiddling around with presentation and functionality. It's not perfect—there are data problems to be fixed, and I'm undecided on whether to make the verb-finding functionality more capable, but as a first blush effort it's not too bad.

The is an illustration of how the principles of BI can be applied in local, personal situations to help real people (me) achieve information and insights from raw data. BI isn't just for Big Companies any more, it's for everybody.

Powered by Tableau

Better BI's new home.

This Better BI blog has been humming along on another blogging platform (here), but there's something I need the blog to do that the other platform doesn't allow: embed data visualizations I publish to Tableau Public. So I'm trying out Blogger to see if it's possible, and hopefully easy.

About Tableau, and why I need to embed visualizations.

One of Better BI's tenets is that information is best unlocked from data when the barriers to discovery and communication are minimized. Tableau is the best tool I've found in 25 years in BI for use in exploring data; it's not the only tool in the box, but it's the first one I reach for, and the most used.

Discovery
Using Tableau, I can instantly start exploring new (or familiar) information, and discover valuable things about it.

Communication
Tableau provides multiple options for sharing analyses, ranging from copy/pasting images in documents, to producing PDFs, to distributing functioning Workbooks with the free Tableau Reader (similar to Adobe's PDF reader).
But the best option for sharing is to publish to Tableau's publicly available and free server product: Tableau Server. Once published, the analyses are web-available to the public.