Robin's Interesting Thoughts

How…?

(source: Michał Kosmulski)

I’m re-reading David Allen’s Getting Things Done book and realizing that many of his ideas about productivity are in common with the design processes and observations of user experience professionals.

In particular, David’s section on “natural planning” emphasizes the trajectory:1. purpose and principles2. outcome vision3. brainstorming4. organizing5. next actions

Points 2-4 correspond fairly well with, say, Bill Buxton’s emphasis on prototyping (“outcome vision”) and the expand-then-narrow design process (“brainstorming” then “organizing”).

And David’s discussion of point 1 (“purpose and principles”) immediately reminded me of Tamara Adlin’s musings on “corporate underpants.” She has been a usability consultant for various companies, and observed that bad user experience often stems directly from confusion and baggage in the ranks of the management. David and Tamara both point out that the primary advantage of hiring a consultant is not special skills or experience but simply the fact that they come from outside the company and can therefore ask the “dumb” question: “why?” Since external consultants have no previous knowledge of the company, they are allowed to ask questions that probe deeply at the organization’s core goals and principles — questions that executives and VPs would never ask because they are too scared to admit they don’t already know. Tamara always claims that by far her biggest contributions as a user experience consultant have nothing to do with usability methods per se, but simply asking “dumb” questions over and over until the various stakeholders finally get on the same page and actually start “pulling in the same direction” as each other.

If you work in an organization, try to ask those deeper questions if the answers are not already clear. Why are we doing this? What is our goal here and what are our values? What will the outcome look like and why is that what we want? My experience has been that people are much more likely to thank me for clarifying the issues than dismissing the question as “dumb.”

The current health care debate is reminding me how upset I am that most Americans don’t understand Economics. Paul Krugman, the master of economics journalism, explains it well. There is no debate. There are some types of goods for which markets work well, and others for which markets don’t work well. The simple fact is, health insurance is one of those goods that is most efficiently provided as a government monopoly. Just like defense or public parks. This is not controversial among economists.

Yet somehow politicians get away with meaningless arguments like “we need competitive markets.”

It seems incredibly dumb to spend so much time arguing about a solved problem. Especially when there are millions of people with sub-par health care that have to continue to wait for progress.

Since OmniGraphSketcher is such a general-purpose graphing program, the possibilities are almost endless. So endless, in fact, that it took me until today to realize that making vertical error bars (a popular feature request) is actually pretty easy. Read more on the Omni blog:

It Turns Out You Can Make Error Bars With OmniGraphSketcher

I suppose that given a big enough forest, eventually one tree is bound to fall so precisely against another tree that it stays…

(I took this photo on Orcas Island, WA)

When I first noticed, almost seven years ago, that there was no good software for sketching Economics graphs, I never imagined that this small observation would grow into such a major project. After several independent studies, conference papers, a masters thesis, and an acquisition, today my little project has reached a new milestone: the official release of OmniGraphSketcher 1.0.

This software application has always proven somewhat tricky to describe. I think this is partly because it is the first product of its kind, and partly because the word “graph” has such a wide range of meanings. I completely reframed the description at least five or ten times while writing my masters thesis. But my new favorite summary is by Omni’s documentation and UI master, Bill:

OmniGraphSketcher is a quick, straightforward tool for creating graphs, whether you have specific data to visualize or you just have a concept to explicate. And it doesn’t assume that you have gobs of free time and attention to learn how to use it.

You can find out more about OmniGraphSketcher in Linda’s entertaining Omni blog post and on the official product page.

As for me, I want to acknowledge again all the friends, mentors, usability testers, beta testers, and users who have continued to give feedback, find bugs, and suggest further improvements. The software would never have come this far if they had not repeatedly convinced me that it was actually useful.

So thank you, and enjoy OmniGraphSketcher! It’s a different kind of graphing program. I know there are many possibilities for expanding its functionality, and I look forward to exploring them. Even after seven years, this is version 1.0 – just the beginning.

If you have any doubt that electric cars are the future of transportation, watch or listen to Shai Agassi’s TED talk.

Among his interesting points:

• Hybrid cars are inherently too expensive, because you have two cars in one. “It’s the trouble with a mermaid – when you want a fish, you get a woman; and when you want a woman, you get a fish!”
• The key to getting the electric car market going is to separate the battery from the car. Basically, treat it like gasoline. No upfront cost to the buyer, easy to swap in a freshly charged battery at a gas station, etc. This way, the battery only needs to have electric capacity for ~100 miles.
• A similar “energy crisis” happened several hundred years ago. Britain was confronting the problem of whether it was moral to have slaves. The main argument against abolishing slavery was the worry that it would ruin the economy. Some suggested making a slow transition, freeing only the children of slaves. In the end, they decided to abolish it outright, and within a year, the industrial revolution was well under way, dramatically increasing standards of living.

“If we do not make this modern transition away from fossil fuels quickly and decisively, we will lose our economy right after we lose our morality.”

This article caught my eye because it was in the MIT alumni publication yet was written by a Williams College professor — a rare collision of my two alma maters.

That was my excuse… but then it turned out to also be a really interesting article.  Author Morgan McGuire writes, “modern video games… are arguably the most complex systems engineered in any discipline, ever.”  That had never occurred to me before.  As one example, he points out that the US federal tax code is about a third the length of a standard video game’s source code (not to mention the graphics, textures, maps, etc. that accompany it).

Unlike most engineering disciplines (including software engineering) where the goal is to make the solution as simple as possible, in game design complexity is often desirable because it makes the game more interesting to play.  Often, amazing complexity can be achieved with just a few interacting rules.  I remember reading that the game designer behind the Sim series (SimCity, The Sims, etc.) was always looking for simple yet powerful sets of rules that put the user in control of an essentially infinite number of options — consider the limitless number of possible cities that can be built in SimCity.

McGuire’s thesis is that game design strategies should be better formalized so that they can be applied to designing or improving complex systems in the real world such as government policy, economic regulation, social and technical networks, etc.  We need to be careful with this analogy though, because the goal in most of these disciplines is still to simplify if possible.  So the hope is that by analyzing complex games, we’ll be better able to understand the complexities that inevitably arise despite our best efforts in real world systems.

I recently read an article in Communications of the ACM about making computer science in the classroom more socially relevant.  The author, Michael Buckley of U. Buffalo, points out that “there isn’t a textbook out of the 60 I have on my shelf that makes me see computing as socially relevant…. If I was a student, beginning these important four years, and I was taught programming via doughnut machines [, pet stores, and games — the types of examples he finds in the textbooks –], I would quit and go do something important.  Major in some field that had an impact.”

The author argues that when intro computer science is taught using silly, simple examples, students just don’t see the potential power and relevance of the tool.  “Even… pure mathematics has me counting and measuring planets and populations.”  He’s created an alternative set of examples that are much more socially relevant, involving for example voting systems (counting), pollution in the great lakes (2-d arrays), disaster evacuation (optimal paths), and drug interactions (databases).

These observations struck me as stunningly accurate.  I think a big part of why I was drawn to computer science was that I had a strong sense of the power of programming long before I took an actual CS class. I think I saw very early on that you could learn how to do math, and then you could program the computer to do that math a billion times in a second.  It could do all these things for you.  It just seemed like the ultimate tool.

Also, I remember thinking that the coolest part about taking Statistics 201 in college was getting to use all sorts of real-world data sets.  Historical SAT scores come to mind.  We ended the course by doing a project where we had to gather some data in the real world and analyze it with statistics.  My team looked at whether people’s close friends have the same sibling status (i.e. only child, older sibling, younger sibling).  Not rocket science, but certainly socially relevant!

Conversely, I remember spotting contrived examples from miles away.  In algebra and pre-calculus, you spend a fair amount of time learning how to do vector math, and most of the examples involve things like canoes in a fast-flowing stream.  It always seemed bizarre to me that we were spending so much time on something with so little real-world applicability.  Finally, I got to calculus and realized that the real reason we had to learn all that vector math was because it was vital for calculus, which allowed us to model physics, economics, biology, on and on.  My thought was “why didn’t you just tell us about calculus, instead of boring us with canoe examples?”

Mr. Buckley has gone even farther by setting up a lab where more advanced students work on “socially relevant” problems, including educational tools and devices for the disabled.  That’s fine, but it seems to me that the critical insight here is about how students are introduced to the field.  Once you’re advanced enough to work on real problems, you’re hopefully way past the point where you understand why computer science is interesting and relevant.

I share his outrage that none of the textbooks are up to the task. Let’s get moving.

A nice little sticky phrase:

It’s not what the software does.  It’s what the user does.