As mentioned earlier, I have met Garr Reynolds of presentation zen fame in Malmo, Sweden last Friday. What was to be a quick 15 minute interview became a 2 hour lengthy discussion on presentations, charting, excel, data, Japanese culture and of course our pointy haired dilbert blog. Garr liked my site alot that he tweeted about it immediately.
I am only posting portions of the interview here.
Q: Powerpoint and presentations are great way to communicate. But most of the time we deal with raw data and numbers. How to present such complex and diverse information without cluttering?
A: There are two types of people (1) the quantitative folks and (2) the design folks. For too long we had just these 2 types of people, one who can program, create great stuff and the other who are really good at designing fantastic things. But now, more than ever, the need is to combine both skills in one person.
One of things that I observe in my university MBA students (and most others too) is that, when it comes to presenting data (either through charts or tables), people go too fast. They just show one piece of information after another without spending time to discuss. Data doesn’t mean anything until we choose to talk about it.
I always recommend my students to have a lengthy Q&A where the facts are dissected and stories are brought out. We should always approach the charts (and data) with “yes this is what it is, but what does it mean? Anyone can make a chart, only intelligent can poke it”
Q: What are the raw (formatting) tips you can give to my readers? People always wonder about things like what color should I use, should I use grid lines or labels? Should I use several colors or shades of one color? Which font should I use?
A: Those are lot of questions [chuckles…]
My mantra is “maximum effect with minimum means”. That is what Tufte or Stephen Few says.
So, grid lines, often we don’t need those as they are implied. If you use them, I say use a very light color.
As far as choosing color, if it is a bright building or room, then a white background works. If it is a darker room we can use a black background.
Colors, as few as possible. These are the common mistakes that I see. I think using different shades of same color works well. You need to realize that lot of people are color blind, so it is safer to use shades of blue or gray than using lot of colors. There are really no hard and fast rules for colors. Don’t just spend too much time on the graph. Yes, it should be aesthetically pleasing, but the more important thing is you and what you want to say.
Q: Your opinion on dealing with situations where there is lot of data?
A: As you can see, most of my charts are very simple. But often we need to deal with lots of data. I am big fan of tables (as long as they are not too lengthy). I also recommend using handouts. If you have lots of data, it is better to take a printout or send the files so your audience can read the data, understand what it means and then you can have a discussion with them.
I recommend reading this article on NY Times about Steve Ballmer’s new meeting style where he says (quote inserted by Chandoo)
[Ballmer] … most meetings nowadays, you send me the materials and I read them in advance. And I can come in and say: “I’ve got the following four questions. Please don’t present the deck.” That lets us go, whether they’ve organized it that way or not, to the recommendation. And if I have questions about the long and winding road and the data and the supporting evidence, I can ask them. But it gives us greater focus.
Thank you Garr for the wonderful interview.
(that is me with Garr on the right side, excuse the poor quality of the image, but we are using webcam on my Toshiba Satellite A300)
But, the most interesting part of this is, actually meeting him and discussing openly about charting, visualizations. We discussed alot about the kind of mistakes people make when creating charts (he *loved* the article 6 charts you will see in hell and the new chart doctor series we announced). We discussed about his new book – presentation zen design.
There is another exciting thing that I am not announcing now, but you will soon know.
Read our earlier interviews with John Walkenbach | Charley Kyd
One Response to “SQL vs. Power Query – The Ultimate Comparison”
Enjoyed your SQL / Power Query podcast (A LOT). I've used SQL a little longer than Chandoo. Power Query not so much.
Today I still use SQL & VBA for my "go to" applications. While I don't pull billions of rows, I do pull millions. I agree with Chandoo about Power Query (PQ) lack of performance. I've tried to benchmark PQ to SQL and I find that a well written SQL will work much faster. Like mentioned in the podcast, my similar conclusion is that SQL is doing the filtering on the server while PQ is pulling data into the local computer and then filtering the data. I've heard about PQ query folding but I still prefer SQL.
My typical excel application will use SQL to pull data from an Enterprise DB. I load data into Structured Tables and/or Excel Power Pivot (especially if there's lot of data).
I like to have a Control Worksheet to enter parameters, display error messages and have user buttons to execute VBA. I use VBA to build/edit parameters used in the SQL. Sometimes I use parameter-based SQL. Sometimes I create a custom SQL String in a hidden worksheet that I then pull into VBA code (these may build a string of comma separated values that's used with a SQL include). Another SQL trick I like to do is tag my data with a YY-MM, YY-QTR, or YY-Week field constructed form a Transaction Date.
In an application, I like to create a dashboard(s) that may contain hyperlinks that allow the end-user to drill into data. Sometimes the hyperlink will point to worksheet and sometimes to a supporting workbook. In some cases, I use a double click VBA Macro that will pull additional data and direct the user to a supplemental worksheet or pivot table.
In recent years I like Dynamic Formulas & Lambda Functions. I find this preferable to pivot tales and slicers. I like to use a Lambda in conjunction with a cube formula to pull data from a power pivot data model. I.E. a Lambda using a cube formula to aggregate Accounting Data by a general ledger account and financial period. Rather than present info in a power pivot table, you can use this combination to easily build financial reports in a format that's familiar to Accounting Professionals.
One thing that PQ does very well is consolidating data from separate files. In the old days this was always a pain.
I've found that using SQL can be very trying (even for someone with experience). It's largely an iterative process. Start simple then use Xlookup (old days Match/Index). Once you get the relationships correct you can then use SQL joins to construct a well behaved SQL statement.
Most professional enterprise systems offer a schema that's very valuable for constructing SQL statements. For any given enterprise system there's often a community of users that will share SQL. I.E. MS Great Plains was a great source (but I haven't used them in years).
Hope this long reply has value - keep up the good work.