Dubroy.com/blog

There are a few things I’ve been meaning to write about for a while now, and in a burst of inspiration today, I realized I can probably tie them all together in one post. Here goes.

Fennec

Fennec is the name of the upcoming mobile Mozilla browser — think Firefox for your phone. I’ve been keeping an eye on the development for a while, especially the UI design discussions that Aza and Madhava have been having. Things are really coming along…last week Madhava posted a walkthrough of the first alpha version:

Fennec Alpha Walkthrough from Madhava Enros on Vimeo.

One of the coolest things about Fennec is that it dedicates the entire screen to web content. Pixels are precious on small screens, so you don’t want to waste them on controls that you aren’t using. On the iPhone version of Safari, the title and URL bar are fixed to the top of the page, so that as you scroll down, they disappear. But the navigation bar — with the back, forward, and bookmark buttons — remains fixed at the bottom of the screen. In Fennec, the title and URL bar also disappear when you scroll down the page, but the other controls aren’t at the bottom — they’re accessible by dragging the page to the left or right. Check out the video to see what I mean.

Edward Tufte would be proud: “the content is the interface, the information is the interface — not computer administrative debris.”

Computer Administrative Debris

In his critique of the iPhone interface, Tufte praises the iPhone interfface for minimizing “computer administrative debris”: the buttons, menus, labels, etc. that steal content space away from the users. This is becoming a serious problem as we continue to shoehorn our desktop interfaces into smaller and smaller screens. For example, take a look at an Asus EeePC running Excel:

Barely half of the available screen space is actually taken up by the content.

On larger screens, losing a little content space is not a problem. But then, I find it causes another problem: it’s distracting. My monitor is too big to run apps at full screen, so I have no choice but to work with clutter all around the window I’m focusing on.

Debris on the web

Inspired by Tufte’s coinage, Ryan Tomayko redesigned his web site to remove all of the “computer administrative debris” earlier this year. When I saw it back then, it caught my attention. I thought it was definitely an interesting experiment, but I thought it went a bit too far, although I couldn’t quite pinpoint what I didn’t like about it.

Earlier this afternoon, I was procrastinating on my thesis work, looking for inspiration for the long-promised redesign of this blog. I want to stick with something minimal, and I remembered Ryan’s site, so I swung by to check it out again. This time, I was able to put my finger on what I don’t like — it’s the missing title and navigation bar.

The thing is, without a title and navigation bar, the user is missing a lot of important context. When I visit a web site, I’m happy to see a small banner across the top with a few navigation links, because it quickly gives me some important context about the content I’m looking at, and about the site itself. It’s not strictly necessary, but that’s fine as long as it doesn’t get in my way, and lets my focus on the content. And the way most sites implement a navigation bar, it disappears as soon as you scroll the page, like the URL bar in Fennec. So it’s not persistently in your face, or wasting important screen space.

The other thing a navigation bar does is give you some idea about where the links lead. When I follow a link labeled “about” from someone’s blog, I have a pretty good idea where it’s going to take me. But if I just click on the person’s name, I’m not sure — maybe it’s a mailto link (note: I’m guilty of this one too).

So, by all means, let’s eliminate useless administrative debris. But be careful; you aren’t just moving functionality, you’re also removing important contextual information.

I just saw that my post Oversimplification is Confusing from a few weeks ago got posted on Signal vs. Noise. Coincidentally, I posted yesterday that things should be as simple as possible, and then some. Well, well, well. Sounds a little contradictory, doesn’t it?

As Ralph Waldo Emerson put it, “a foolish consistency is the hobgoblin of little minds.” But actually, I don’t think the two posts really contradict each other. When I talked about oversimplification, the example I gave of the Photoshop dialog box wasn’t actually a problem with oversimplification, it was a problem with not enough simplification. Or, wrong simplification — take your pick. Presumably they “simplified” the dialog box by not including a full explanation of why you would ever choose to uncheck the “maximize compatibility” box. They probably should have simplified further by removing the option altogether. Instead, they left a corner case baked into the UI. In other words, the overfitted their solution to the problem.

Maybe I should have stuck with my original title for the first post: Don’t Ask Stupid Questions.

This semester I’m taking a machine learning class with Geoffrey Hinton. The other day in class, he was talking about the balance between correctly learning a concept, and overfitting the data. Say you have a program that is trying to recognize people: an example of overfitting is if your program learns that only people between 5′4″ and 6′3″ are people, just it has never seen a person taller or shorter than that.

There’s a famous Einstein quote that goes something like: “Everything should be made as simple as possible, but no simpler.” According to Prof. Hinton, the principle in machine learning is more like: “Everything should be made as simple as possible, and then a bit simpler.”

This also seems like a good approach for designing software. Make things as simple as you can possibly bear, then remove a few features. Without fail, whatever you consider upon to be an absolutely minimal feature set, you can still remove a few features.

Today Mike and I went to see Joel Spolsky talk about FogBugz in Toronto. During the Q+A, there were two questions that I really liked Joel’s answer to:

1. Does FogBugz support cloning bugs?
2. Can FogBugz support create dependencies between bugs?

The answer to both was really “no”, but Joel said “Sure, just type ‘clone of case 123′” and “Sure, just type ‘depends on case 123′.”

That’s a perfect illustration of what I’m talking about. If someone was coming up with a list of features their bug tracking system must absolutely have, there’s a good chance they would include those two features. But specifically adding features to do those things is an example of overfitting — really, linking achieves 95% of what you need anyways, and it’s much simpler.

So my new design mantra is “as simple as possible, and then some.”

This morning Signal vs. Noise linked to a post by Paul Stovell called We are what we repeatedly code:

The best developers I know write great quality code every time they touch an IDE. This is because they realize that writing good code is something you have to practice, something that you have to do over and over again to be able to do right. They realize that writing great code is something you do all of the time, not something you save for a party trick.

I agree with him on this. But what exactly is “quality code”? Paul uses an example of a small, throw-away tool he wrote recently:

I could have written the tool as one huge Main method in a console application. Yet, instead, it’s all nicely factored. There are base classes, adapters to reduce the dependencies on the outside systems, encapsulation, interfaces, a couple of occurrences of the strategy pattern, and even the odd XML-doc comment thrown in here and there. Hell, I even gave the DLL a fully qualified company namespace.

I get what he means: write every piece of code as if it will ship. But I can’t agree with any definition of quality that is measured by the amount of design patterns you use. All the things he described — encapsulation, interfaces, design patterns — are all well and good when used appropriately, but their abundance, or even mere presence, does not indicate quality code, any more than the presence of salt and pepper indicates a good soup.

I’m reminded of my first co-op term at IBM on the SWT team. Steve Northover, the SWT technical lead, has a couple of golden rules. One of them is “that which obscures my code is bad”. Encapsulation, interfaces, the adapter pattern, the strategy pattern…all ways of solving specific problems, but also ways of obscuring your code. So many people seem to believe that adding more structure will produce better results. We see a similar pattern in government (endless bureaucracy), education (standardized testing), and business (meetings, reports, yearly reviews, middle management). These things begin with the best of intents, but often end up causing more harm than good.

In software development, there’s a growing movement of people who believe that “less is more.”

Joel raises a good point in his post Choices = Headaches. His complaint is that Vista has WAAAAAY too many options for saying “see ya” to your computer: sleep, hibernate, shut down, restart, log off, and switch user. I agree with him here. I was just thinking the other day how silly it is that there is even a restart option. It’s basically only there because of brain-dead software, and if you really, really need to restart, couldn’t you just turn the computer off then on again?

Joel’s solution is a single action, which he calls b’bye:

When you click b’bye, the screen is locked and any RAM that hasn’t already been copied out to flash is written. You can log back on, or anyone else can log on and get their own session, or you can unplug the whole computer.

He calls it b’bye, but it’s just another name for off. If you implement it the way he described though, you’re still missing a true reset option. Sure, it may be a cop-out for poorly-written software, but I think it’s still necessary.

The big-picture idea that Joel is touching on here is that more is less. Having too many options is a bad thing, because you actually have to invest significant mental effort to choose between them. Sometimes this can be enough to turn you away altogether. I procrastinated on buying a digital camera for years, because it was such a monumental effort to just learn about the choices I had. Too many choices can also make you feel belittled, because you don’t understand the differences. The menu at Starbucks has this effect for many people.

In software, adding a configuration option is the ultimate design cop-out. I’ve seen this happen many times with Eclipse since I was a developer in pre-1.0 days. Would you like to double-click to open files, or single-click? Would you like to use curvy tabs or square tabs? Having so many options makes it really difficult to find the important ones. (In fairness to the Eclipse developers, they have a very diverse set of stakeholders, and this is the only way to keep most of them happy)

What it really comes down to is having the courage to make those tough design design decisions. By removing those unnecessary options, you risk alienating a certain group of users — the people that actually want them. But would you rather by stuck in the zone of mediocrity?