Could visualization help make better software?

December 18th, 2008 | Filed under: design, infoviz, programming | 4 Comments »

Writing software is incredibly hard. Every programmer knows this. The software we write is complex, unreliable, and difficult to maintain. And this isn’t a new thing — the term “the software crisis” was coined in 1968.

The thing about software is that it’s remarkably easy to write a program that mostly works. And it’s difficult to tell the difference between a quick hack and a stable, reliable, and robust system, because the software development process produces almost no visible artifacts.

When you look at a building, it’s easy to get a quick sense of how well-built it is. Which of the two buildings below would you rather be in during a heavy storm?

"christiania, glass house, august 2007" by seier+seier+seier on Flickr "This incredible house was featured in WIRED magazine!" by jonrawlinson on Flickr

Besides the program itself, the only visible artifact of the software development process is the source code. And that is only viewed by the programmers, through the tiny lens of the text editor. What if we could make the entire process more visible?

I’m thinking of visualizations along the lines of the comparison of system calls in Linux/Apache and Windows/IIS that I posted a while back. But this is just one idea. What other ways could we visualize Code Smells? (Maybe we could actually smell them!)

Aside from visualizing various aspects of the source code itself, could we show how well tested a piece of software is? We could show how many tests were run recently, what their results were, how good the code coverage is, the number of crashes encountered in the field, etc. With projectors and LCD displays being so cheap these days, there’s no reason a development team couldn’t have a few displays dedicated to these kinds of visualizations.

What do you think? Could this help improve the quality of software? What if companies openly published these kinds of things?


Sketchbook: Firefox session restore

December 5th, 2008 | Filed under: design, hci, usability | 10 Comments »

Since I’m doing a field study on how people use tabs in Firefox, you can imagine that I spend a lot of time thinking some of the smallest details of the Firefox user experience. One thing that’s been on my mind lately is the session restore feature. You know, when you start Firefox, and it asks you if you’d like to restore your windows and tabs from last time? That’s session restore.

It’s definitely a handy feature. I often use tabs like lightweight bookmarks, leaving tabs open to a page that I am planning to come back to. (And in my field study I’ve learned that lots of other people do this too.) If your browser crashes, or the Firefox process sustains collateral damage in a kill(1)ing spree, it’s a relief not to lose all the tabs your were saving.

The Problem

But the interface for session restore has always bugged me a bit. First, it uses modal dialog boxes, which are generally a bad idea. One of great things about Firefox 3 is that it eliminated a lot of the modal dialog boxes (e.g. “Do you want to remember this password?”) in favour of non-modal messages in the notification bar (see Alex Faaborg’s post about this from last year).

Not only does it use modal dialog boxes, but it’s asking me a question that’s usually unrelated to what I’m trying to do. “Do you want Firefox to save your tabs for next time?” I’m probably closing my browser for a reason, but I have no idea whether or not I’ll need these tabs next time. And asking me when I start up might not be the right time either…I’m starting my browser because I have something to do, and I can’t remember what I had open before, so how should I know whether to restore or not?

Either you’re part of the problem, or…

So I’m thinking — what if we got rid of these questions altogether? What if Firefox always remembered what windows and tabs you had open? But you might not want 15 tabs loading every time you start Firefox up.

A while back, Aza proposed making the new tab screen more useful. His proposal included a separate screen for restoring recently-closed tabs and windows, but it’s kind of hidden in his design. Most of the space in his design is taken up by contextual actions, but when you’re just starting the browser, these aren’t as relevant. Here’s a quick mockup of what a similar screen might look like on startup (mouse over to see the notes):

Firefox session restore startup page mockup

There are a few things to mention here. First of all, recently-closed windows are accessed from within a history list. Lately, I’ve been thinking that so much of what we do in the browser is revisiting pages that we’ve been to before, so a time-based view makes a lot of sense. Unfortunately, the history is pretty much hidden in most browsers. So you can see some inspiration here from Google Chrome, which presents the history like a regular web page. I think this makes a lot of sense, because it lets you use the same behaviours that you use on the web, whereas a separate history window forces you to learn a new UI.

Recently-closed windows are presented in a way that looks somewhat like they actually appeared in the window, maintaining the tab ordering. It probably needs to be made a bit more obvious than in this mockup, but you get the picture. Of course you could go a step further here, and make it look almost exactly like a screenshot of the tab bar. This mockup only shows one recently-closed window, but you can imagine having more than one, and they would appear in the history at the time that they were closed. I’ve also incorporated recently-closed tabs into this page. That’s currently available as a menu item under History->Recently Close Tabs, but to me, it’s always seemed kind of tacked-on there. You could also imagine using some of the space here for bookmarks.

What do you think? If you have any thoughts, please leave a comment.