Wednesday, 14 September 2016

Iron Viz - Device Designer

Tableau Public recently announced the last of the three entry contest for the 2016 Iron Viz, so I thought I'd have a crack!

Update: all entries are now up here and if you like mine you can vote by tweeting #MobileIronVizpgilks

This contest was a bit different from others because the instruction was not based around a data topic but instead you need to show that you have used the new Device Designer feature, and design a single dashboard that work on both mobile and desktop - and the data topic is open ended!

I found this contest much more of a challenge to get started with than previous contests. One reason was the open ended question of what data set to use - where do I even start and what hasn't been done before? When I enter a contest like this I like to try and do something completely original, but the Tableau Public library is becoming crowded, especially with things like Make Over Monday happening, and it can feel like the number of unexplored datasets is quickly diminishing.

After much handwringing I decided to go back to an idea that I had ages ago, back in 2013, just after I made this viz about the tallest buildings in New York. And that was to do something about the most extreme roller coasters in the world. So I thought I'd revisit this topic, and at the very least if it didn't win it would scratch a long standing itch. I don't have as much time for Tableau Public as I used to and so its nice to use the time for something I have had on the to-do list for a good while.

The other tough bit about this was using the Device Designer to make a mobile friendly dashboard as I haven't done that before and needed to get used to the new feature. I learned a few things about it which I'll detail below.

Below is the finished design - you might note that its pretty simple, and this is purposeful. I wanted to challenge myself to see if I could make an engaging dashboard that could fit onto a single phone screen without scrolling. My thinking here was that, to put it bluntly, most people can't be bothered to scroll. And scrolling with interactive dashboards can sometimes cause click confusion. Of course in order to achieve a single screen view, it needs to be very simple and pared back.

Of here's a screen shot of the mobile version and the desktop version, and an interactive version is below. This will change depending on how you are viewing this blog!



Data is sourced from rcdb.com

!!! Update: I just tested this blog post on my phone and the viz below looks all screwed up, please click this for how it should look if you are browsing my blog on a phone 




So what did I learn making this viz?

1. Keep things (even more) simple

I'm a big fan of simple straight forward design in Tableau, but with mobile you have to taker that to another level. A couple of tips that I took from Dash Davidson's blog post were to ensure I lock my map and to use only actions as filters and avoid quick filters and other drop downs. Drop down menus can obscure everything on mobile so are best avoided. I also tried to keep my sheet arrangement simple so I could be sure it would look consistent across different platforms, and to avoid potential confusion brought in by things like hidden sheets that pop out.

Tooltips are also hard to use on mobile because of the space constraints and so I limited these to only the bar chart and used highlight labelling instead on the map.

The challenge of keeping things really simple actually turned out to be quite worthwhile - it's easy to get carried away building fancy things in Tableau almost for the sake of it. The restrictions of designing for mobile focus the mind on what's really useful. I have even more respect for app designers now!


2. The order that you make things with Device Designer matters, a lot

In my first attempt at this viz, I went straight to the 'Phone' setting on the Device Designer and designed a viz that would look good on a phone. The thinking here was to design 'mobile first' as mobile is these days the primary route to the web, and because the contest was introducing a mobile component.

The difficult thing about this was what happened when I tried to take this as the basis and go and build out a desktop version.

The rookie mistake I had made was not to build the 'Default' dashboard first, and so everything I had done on the phone version was not there for other versions and I had to try and build things back up from scratch. I got pretty confused with the workflow and ran myself around in circles.

Eventually I decided to scrap my efforts and start again. This time I designed 'desktop first' within the Default view, and then adapt to phone. From a practical point of view this proved to be much easier. But it also meant that everything I was doing I was also having to think one step ahead to 'what will this look like when I switch to phone'.

3. Font sizes are tricky!

Even though a desktop screen can be really big, and a phone screen is really small, your fonts used within sheets are not going to automatically re-size. I wanted big fonts on desktop and small fonts on mobile, but this would have meant making multiple versions of the 'Default' view and would have negated the purpose of the Device Designer. So I spent some time trying to pick font sizes that looked reasonable on both devices.

4. You can't use new sheets, but you can use new objects

The way the DD works, only the sheets in your default view are available to you to use in your device specific versions. So you can't have a 'big bold' version and a 'small simple' version of the same sheet. At least I don't think you can without doing something clever with hidden sheets. I didn't want to get involved in that kind of trickery so I worked within the limits most users will experience.

You can however add new images, text objects and web objects, so this gives you some flexibility with titles and pictures. I tried to utilize this in my viz.

5. You might have even less space than you think - always test the reality

If you are going to make a mobile dashboard, you absolutely MUST test it on a phone. Looking at the view on Tableau Desktop, or using an emulator on your desktop is not going to do the trick. Your mouse pointer is very different from my fat fingers, and scrolling on your magic mouse is a lot different from scrolling with a thumb. If you don't test properly you might be kidding yourself as to how your viz looks and works.

When I opened my viz on my phone I noticed that the visible screen was actually much smaller than I expected because of the extra headers that Tableau Public adds by default. You can get rid of these headers by altering the URL to include &:showVizHome=no, check out the difference between these two links on your phone
https://public.tableau.com/views/RecordBreakingCoasters/RecordBreakingCoasters?:embed=y&:display_count=yes
https://public.tableau.com/views/RecordBreakingCoasters/RecordBreakingCoasters?:embed=y&:display_count=yes&:showVizHome=no


Thing is, you can't guarantee that people will see your viz with the URL changes, so design for the worst/smallest possible scenario. Below is a picture of how my viz looked on Tableau Desktop as per iPhone 6, and then for real on my iPhone 6.





Anyway, I think I finally got the hang of this, I hope my experiences above can help you get a head start on using this new feature. It is pretty cool to finally be able to know that your viz will be able to be viewed on a phone, and the restrictions of size are actually a welcome challenge that focusses your mind on simplicity.

 And I hope you enjoy exploring the worlds fastest, tallest, longest and most upsidedowny roller coasters...





Thursday, 21 July 2016

Olympic Medals

Here's another ReViz! This time Alex Duke through down the gauntlet of using Olympic medal data and came up with this Viz of the Day. Also Dash Davidson had asked me if I would help Tableau create some Olympic themed vizzes that could be used for an exhibition. I cheated a bit because Alex's data did not have 2012 medals, so I went and found them to be up to date.

So I decided to go for a pretty simple approach that could be printed out and used as a static image. I've also always been a fan of medal data that takes into account the size of a countries population for context, so I built in a switch to flip between total medals and medals per million people. If you are printing these out, you could place the two versions side by side.



Anyway, here it is:



Tuesday, 12 July 2016

Simple requirements gathering questions for dashboard design

Today I gave a bit of a tutorial to my team at work* about how to develop effective dashboards and I included a section on how I like to gather requirements from the people I'm making the dashboard for. I basically have a framework of simple questions, that once complete should give you the bulk of what you need to know to build an effective and useful dashboard.

I thought I'd share a version of it here. Please bear in mind of course that this is definitely a simplification - good requirements gathering is a conversation and entails a good deal of understanding of the subject and data - what I'm focussing on here is simply the content/structure of the dashboard.

So here's what I do, I ask questions. I definitely do not ask 'what do you want to see?' or 'what numbers do you need?' as these open ended questions often lead to over loaded monstrosities that somehow don't get to the heart of the matter. And I don't get people to fill out forms, because that's boring.

Here are some of the questions I ask, and how they can help me design a dashboard. I hope they help you too!





 *did I mention I got a new job? I'm now working in Product Insights at Spotify, yay!

Wednesday, 25 May 2016

ReViz - Tornadoes!

I recently joined the wonderful ReViz project with Matt Chambers and Alex Duke, trying to fill the very large shoes left by Nelson Davis.

If you're not familiar with the ReViz project I encourage you to check out the page and see the work that's been done so far.

Matt recently kicked off a new ReViz by taking the Torndao dataset used in the 2012 Iron Viz contest,  which was won by Anya A'Hearn and finding a new story which showed the five deadliest single days of Tornado outbreaks recorded in the USA.

When I got a hold of the data, I have to be honest I found it really hard to come up with another engaging story within the dataset that hadn't yet been covered. So instead I've created something that I hope is more of a striking visual. Taking inspiration from the famous US wind map (see below) I wanted to show visually the volume and power of the tornados and how they are clustered around specific parts of the country.

Wind Map:



I also wanted to show both just how common tornadoes are but also the degree to which fatalities from tornadoes come from a small number of very big instances. I also included some light interaction to let people zoom into their state, or to look at how things change over time.

Unfortunately the resulting map is pretty slow to load, and so to mitigate that a bit I only included the most recent 10 years of data. The result is below:




Thursday, 12 May 2016

The Usefulness of Unions in Tableau

Recently in some of my projects at work I've been making use of creating data unions before I bring the data into Tableau for ease of use and efficiency. This topic also came up at a recent NY Tableau User Group and seems to be a popular approach, so I thought I'd write up a quick how to on using 'unioned' data to your benefit in Tableau, with a couple of examples.

Some of this will become less relevant when Tableau introduces cross database joins, and cross data source filters. But none the less it might be helpful for a while longer. It can help a lot getting around issues you may have with data blending, or with one to many joins or with avoiding having to resort to Parameters (which don't update with the data).

Example 1 - Dealing with data at different levels of aggregation

Let's say you have two lots of sales data

A. Sales per day for the last 6 weeks
B. Sales per month for the last 3 years

And you want to build a dashboard that allows you to switch between the two and/or you want to see data at both levels but have quick filters apply to both sets of data. Well the answer is easy - union that data!


So take the data from this:

A.

B.



(note American date format mm/dd/yy)

To something like this:





And then you can use 'Date Type' as a filter that lets you switch between the two:



And if you use 'exact date' as your date field, you can easily switch between Daily and Monthly views in a time series chart:






The main benefit to this is flexibility to the user, but also as you are using a single data source you don't need to worry about blends or joins, and you know that any filters will work with all charts.

Another benefit is that this can be a very efficient way of working when you are dealing with very large databases. Joins can be costly from a performance point of view, and blends can be both costly and cause functionality constraints, so using a single table with a filter can speed things up.


Example 2 - Dealing with data at different stages or that has some shared fields

In this case imagine you have two sets of data for application for, and sales of, mortgages. The data shares some fields.

A. Application data
B. Sales data

A.

B.


Again, there are different ways you could deal with this data to create a dashboard, or series of dashboards. But again using blending or joins might cause some difficulty with data source filters, or if you end up with one to many joins. So a possible approach again is to Union the data and use similar fields together, and just leave blank values that don't apply to that part of the data. The resulting data might look something like this:



And again, you can use your Type field to easily switch between views, or to show both views on the same dashboard or view with a single filter for Product that doesn't rely on (undynamic) Parameters.






And that's it! You can easily extend the logic here to build out more complex data sets for different scenarios. This approach can also help with performance against 'big' data, especially if you make you Type field numeric and use it as a sorted index in your database.

Just be careful to make sure you know how you are using the Type, or similar, field in each view so that you don't double count.






Monday, 25 April 2016

Iron Viz - Food Fight! Exploring the international trade of fruits and vegetables

The latest Iron Viz qualifier recently finished with the topic of 'Food Fight!' The winning design was by Russell Spangler and you can find all the entries here.

Unfortunately for me it was another fruitless Tableau Public competition (pun intended) but I'm still very happy with my entry. I try to abide by the 'Keep it Simple Stupid' approach, which Chris Love has so nicely vocalised with his #TableauKISS campaign, by combining accessibility and fun with depth and functionality.

The dashboard is designed to encourage interaction and to let you explore imports and exports by country and by produce type. Please click around the lower half of the viz to see what happens!

I hope you enjoy navigating the data and find some interesting trade patterns or learn something about where the food on your supermarket shelf comes from. 'Food miles' are a pretty hot topic these days, and I don't think we always appreciate the global network of growers and distributors that bring us our food. And of course feel free to download it to see what's going on under the bonnet.

The data was sourced from http://faostat.fao.org/ and includes all the latest import and export volumes across some 46 different fruits and vegetables and 211 countries. With all combinations this comes to almost 90,000 separate data points and my intention was to essentially follow the Tableau mission to help people see and understand the data.

Here's my entry - The Global Grocer


Wednesday, 30 March 2016

What's Peter Been Listening To? My first (mis)adventures with scrobbling




The viz above shows the top 20 artists I've listened to on Spotify so far this year - here's the back story:

For the last few years I've enjoyed reading Andy Cotgreave's blog posts where he takes a look at his listening habits by using data from Last.fm, here's a good example. And of course my pal Jewel has also played around with her listening data too. So I finally decided to get myself in on the action.

I should add also that this last year I've really fallen back in love with listening to music and discovering new bands. I was really into music as a teenager but kind of lost interest. But my Spotify subscription has really helped me get back into it and I probably listen to more new music than ever now - while still listening to all my old favourites.

So, first of all how to collect the data. Its pretty simple:

1) Get a Spotify account
2) Get a last.fm account
3) Link them on ALL your devices
4) Download your data here thanks to Andy's friend Ben https://benjaminbenben.com/lastfm-to-csv/

So to look at my data, first off lets check out the data quality:



As you can see, I've had a few problems. A couple of times last.fm and Spotify got disconnected. I kept an eye on last.fm and noticed it had stopped Scrobbling (Scrobbling by the way is just keeping a record of your listens). And then very recently I realised that it wasn't picking up my mobile listens - I didn't know I had to change the settings on my devices individually.

So I've lost quite a bit of data, but oh well. I'm also not 100% convinced its picking up ALL my Spotify plays.

What else have I seen?