Screenshot

I’m supervising a capstone project right now where students are providing data analysis and visualization support for a local organization, and the following set of links have been queueing up in my feed as to-read items for me related to that project (and, hopefully, to-read items for them):

eagereyes has a nice summary of ISOTYPE (International System of Typographic Picture Education) which in the roughest strokes is those charts where the number of an item is represented not by a bar but as a collection of images or icons representing the thing being counted. But it’s a lot more complicated than that, including guidelines about the design of the icons.

The same site also has a nice, short illustration of how visualizing something makes it real in a way that just seeing/reading the source information or data does not. To me, this highlights the importance of being thoughtful about what you are presenting and the accuracy of the analysis behind your visualization.

In a similar vein, I enjoy Junk Charts dissections of poor data presentation; this critique of bubble charts via a self-sufficiency test analysis is a nice example and serves as a good model for a simple way to assess your own visualizations.

If you’re thinking about data visualization to monitor something (which my students are), you probably need to think about if a “dashboard” would be helpful. juice analytics has put together a collection of innovative dashboard designs, and also have a helpful link to a white paper they wrote on dashboard design at the top of the article.

We’re also probably working with some maps in our project, so this list of common problems in maps from cartonerd could be useful, as could the linked collection of UK maps which is recommended as a tool for looking for ideas of what not to do. The key focus here is on persuasiveness of the maps; the overall message is ultimately narrowed down to the question “is the map as it stands capable of properly supporting policy-making”?

On the tool front, the announcement that students can now download and use the full desktop version of Tableau for free got a fair bit of fanfare recently.

My colleagues and I teach a number of courses where we hope students will go out and find their own data sets to work with – Quandl looks like it will be a great source to share with them. It’s a searchable collection of free and open datasets, normalized into a standardized format which can then be output in a range of useful formats (right now, Excel, CSV, JSON, XML or R). I love that you can browse the data online and even see some basic graphs of it without downloading, though. This is a site that some will use to look at data and get answers directly, not just a repository to download from.

My security class is talking about the types of commonly seen mistakes that can crop up when writing programs that lead to security flaws, and while I usually introduce the ideas using “normal” programming examples because it is the common background I can assume my students have, I’m trying to help the students map these ideas to what they’ve seen of database or web development as well. So I finally went back in my saved links and read through a Google blog post from a month ago about security issues in hosting user content, specifically web content.

After a brief but reasonably nice survey of the problem they’re trying to address, they include this interesting statement, contrasting the current state of affairs to the old days of hosting static HTML: “For a while, we focused on content sanitization as a possible workaround – but in many cases, we found it to be insufficient. For example, Aleksandr Dobkin managed to construct a purely alphanumeric Flash applet, and in our internal work the Google security team created images that can be forced to include a particular plaintext string in their body, after being scrubbed and recoded in a deterministic way.”

I’ve been trying to make the argument to our digital media (as I get opportunities to talk to them) that they really ought to think of security as a good elective to round out their major, particularly those focusing on courses in web development and mobile application development. I’m sorely tempted to print out a copy of this article and go over and paste it on their lab door – or at least remind their professor to do another advising push towards the course on its next offering. These problems are perhaps outside the scope of what most web developers would encounter, but I wonder if rejecting the importance of understanding these issues would be analogous to an application developer believing that only someone working in operating system design really has to understand security.

This security critique of the Tesco website is a hoot. It walks through an increasingly deep, and increasing damning, look at what is wrong with their setup, and how you can tell. The critique is well peppered with links to additional content about the problems being described, so it’s not a bad starting place to learn something about web security. It is also an accessible illustration of the type of exploration and deduction that can be used to profile a system and its vulnerability. Finally, to me, it reads as a nice lesson in why you can’t just “throw some security on your site” without real expertise. I like the concept of “unconscious incompetence” being used to describe the situation where incompetence (here about security) is being compounded by a lack of awareness of the incompetence. If you at least know what you don’t know, you’re moving a step in the right direction!

I really enjoyed this assessment of how a speedometer both breaks a ton of good-visualization rules, and yet is a great visualization given its purpose and context of use. I particularly liked its discussion of why you would want to change scale halfway through a visualization in this setting. Obviously, don’t break the rules until you understand them disclaimers apply, but it’s a really elegant example of how blindly following rules alone also doesn’t make good design.