dan-menard.com

Context is a very important factor in software development. Knowing the conditions under which your software will be used is an integral part of crafting a positive experience for your users. Many companies take this to heart and create truly engaging software that really connects with its users, but the vast majority miss the mark. While I’m sure I’d have no trouble pointing out a myriad of context-related issues in software made by Average Joe Developer, today’s focus will be on showing that even the top names in software aren’t perfect.

Exhibit A: The iPhone’s Clock.app

Let me tell you a story. A few weeks ago, the fiancée and I were scheduled to meet with a potential wedding venue early Saturday morning. Given that it was a bit out of the way and we tend to oversleep, we thought we’d be smart and set an alarm using the iPhone’s default clock app.

So Friday night, we set an alarm thinking it would wake us up Saturday morning. It did not; it turns out the alarm we set was for weekdays only! While this was entirely our fault, I’m still going to call Apple out on not taking context fully into account: when we set the alarm, why didn’t the app warn us that the alarm wouldn’t go off the next morning? I would imagine it’s very rare that anyone sets an alarm more than a day in advance. It’s much more likely that when someone sets an alarm at night, they expect it to wake them up the next day. This is a case where a neat feature is actually an annoyance because context isn’t handled as well as it could be.

Exhibit B: Google Maps

Continuing our story, while I was frantically trying to get ready I was loading Google Maps to get directions to our appointment. After punching in the address and asking it to route us there, Google Maps told me the trip would take over 9 hours. I freaked out! We don’t have 9 hours, we have 30 minutes; is this the right address? Did we accidentally book an appointment at a venue 9 hours out of Ottawa?

Actually, it turns out I had Google Maps set to give walking directions. Again, my fault, but again, where were the developers on this one? Did they really think I wanted to walk over 9 hours to get somewhere? Why not recognize that I was probably looking for driving directions and put a message at the top of the screen asking if that’s what I meant?

(For the curious, this story did have a happy ending: we made it there a slight 15 minutes late, and this was the venue we eventually chose for our wedding.)

Exhibit C: Firefox’s Spell-Check

Firefox is an incredible piece of software. It is currently the browser of choice for about one quarter of all internet users, and in many ways helped to revolutionize the web browser market. But one area where it hasn’t really advanced as far as it could have is its built-in spell checker. I don’t have a fancy story for this one; the data speaks for itself. Here is a list of words that show up as spelling errors in Firefox 3.6:

Some of the internet’s most popular websites:

• YouTube
• Facebook
• Myspace
• Flickr

Well-known web technologies:

• Skype
• Silverlight
• Webkit
• Wordpress, CMS
• PHP, CSS (it gets HTML)

Very common computer words:

• Inbox
• USB

Extremely successful desktop software:

• Photoshop
• PowerPoint

Apple products:

• iPod, iPhone, iPad
• Macbook
• iMac
• OSX (it gets Linux and UNIX)

These are all very common words in internet parlance, and it’s ridiculous that they are highlighted as possible spelling errors. Why not add them to the dictionary? A simple white-list that could be crowd-sourced to the community seems right up Firefox’s alley; I wouldn’t be at all surprised to see this addressed in a future release.

What can we learn from this?

My main take-away here is that context is a big factor in software development, and one of the hardest to get right. Even the big guns have room for improvement, which means the rest of us likely do as well.

This week’s entry is for the Apple fanatics, and iPhone owners (or potential iPhone owners) in particular.

There was a post over at TUAW last week encouraging readers to weigh in on what may or may not be present in the forthcoming iPhone OS 4.0. I missed their deadline for submitting comments, but read on to hear my thoughts anyway — I’m going to talk about a couple of things I’d like to see happen to the built-in Maps app.

Voice Navigation

There is a big market for GPS-like turn-by-turn directions on the iPhone, and plenty of companies both big and small have thrown their hats in with varying features and price points (an excellent comparison of such apps is available at Pocket GPS World). While this is enough to show that users really want voice-navigated directions on their phone, the big reason I think this will happen is that Droid users already have this behaviour built straight into Google Maps. This is a big feature, and the difference between having it available by default on the Droid and as a paid app on the iPhone is significant, and something I think Apple will want to address.

Augmented Reality

There are a lot of apps designed to help users find nearby points of interest. Some of the more recent ones have started a trend called augmented reality, which is when a live feed of the camera on the phone is used as the background and information is overlayed on top of it based on what direction the user is facing. With the iPhone’s accelerometer and compass, this technique has proven to be remarkably accurate and holds a lot of “wow” factor; something Apple has consistently been a fan of.

Since most of these apps are simply wrappers for the Maps app, why not cut out the middleman and blend an augmented reality feature into Maps by default? This would be Apple’s first entry into the growing augmented reality market, and would really up the ante for developers who currently offer augmented reality mapping features. Apple is all about shaking things up, so while this is probably pretty unlikely it wouldn’t be entirely out of character.

Your turn!

I’ve given my thoughts about the Maps app, which I think will net a big update come the next iPhone OS release. What do you think will be added/changed/removed in iPhone OS 4.0?

In the world of software development, I submit that the hardest thing to do is to continue developing your code after it has been integrated into someone else’s code, which they are also continuing to develop.

The challenge here is that you and this other person are now co-dependent. If you break the build, it’s broken for both of you, and vice-versa. If your next feature requires some "almost finished" feature from the other party, your deadline depends on their deadline. This isn’t so bad with literally you and one other person, but what if you’re part of a large team working on one product, and the other person is an entirely different team working on a different product altogether, with different priorities and different deadlines? That’s just asking for headaches.

Adobe has some kind of magic handle on how to do this really well. Let’s start from the beginning: for a while, they just did Photoshop, which was pretty neat. Then they added Illustrator, a great Photoshop companion. Interoperability was a bit rocky at first, but now it’s a piece of cake moving a design from one tool to the other.

Then from the opposite direction, they released Flex Builder. Web mark-up integrated with Flash. Adobe gets it right again, bridging the gap between two like technologies. But do you know what made things really interesting? Catalyst.

With the release of Catalyst, suddenly everything has to work together. Designs made with a combination of Photoshop and Illustrator have to be compatible with Catalyst, which has to play nice with Flex Builder, which relies on Flash. This is a lot of complex products interacting with a lot of complex technologies; it’s an absolute mess of dependencies. And you know what? They made it work. Seamlessly.

Take a moment and appreciate how awesome that is. Imagine what would happen if they wanted to add a new feature to Catalyst. First, there are the normal issues that may come up in Catalyst:

• Will this break any of Catalyst’s existing features?
• Does the user interface match the rest of Catalyst?
• Does it introduce any new bugs into Catalyst?
• Does it open up any regressions in Catalyst?
• etc

Then, you have to consider what this will do to any incoming Photoshop/Illustrator design files:

• How will new design files take advantage of this feature?
• How will existing design files react to this feature?
• Does the underlying design file format have to change?
  • If so, does that cause any bugs/regressions in Photoshop or Illustrator?
  • Who is expected to report/fix/test these issues? The Photoshop/Illustrator guys? The Catalyst team? Some combination of both?
• Besides that, is there any work at all required on the Photoshop/Illustrator side?
  • If so, do the Photoshop/Illustrator guys have time budgeted for it?
  • What parts of the Photoshop/Illustrator changes depend on what parts of the Catalyst changes?
  • Can any of the Photoshop/Illustrator work be done in parallel with the Catalyst work? How much?
  • How will this affect the deadline?

And of course, that same list applies to how this feature affects the content Catalyst exports for Flex Builder. And that’s just the obvious dependencies — it gets even worse:

• What if a team can’t fulfil their side of the changes? Reschedule? Cancel? Release anyway?
• If one team is late, what does that mean for the others? What if several teams are late? What if everyone is late?
• What happens if the release cycles between any of these products don’t match up?
  • Can we release Catalyst with its changes before the changes to Photoshop/Illustrator/Flex Builder/Flash are released?
  • What if a user upgrades one product but not another? For that matter, how backwards compatible is this for outdated versions of any of the products?
    • Aren’t there thousands of possible version combinations? How many should be tested? Who’s managing this?

And this is just what I’m thinking of as I type. I can’t even imagine what a mess it must be to coordinate features in all these applications. How do you even measure what effect a new feature in one product will have on any of the other products’ thousands of features?

I don’t know how Adobe does it, but they do it and they do it well. If they can keep this up, they’re going to be around for a very long time.

1. How not to delay a release

The thing about deadlines is that sometimes, even when you’ve done everything you possibly could, they still get missed. It’s not always your fault, but nobody cares; once it’s late, everyone will blame you. And if you’re Valve, they will be loud and bitter and increasingly annoying.

But that doesn’t mean it’s ok to be stupid about how you postpone the release.

For those who of you who weren’t sitting on the edge of your seats from Tuesday afternoon until Wednesday evening, here is what happened:

• Oct. 23rd 11:30 PST — Valve announced that the Left 4 Dead 2 demo would be available on Oct. 27th for anyone who pre-ordered the game.
• Oct. 27th (early morning) — The release was scheduled for noon PST.
• Oct. 27th noon PST — The release was postponed until 1pm PST.
• Oct. 27th 1pm PST — The release was postponed until 2pm PST.
• Oct. 27th 2pm PST — The release was postponed until 3pm PST.
• Oct. 27th 3pm PST — The release was postponed until 11pm PST.
• Oct. 27th 11pm PST — The release was postponed until Oct. 28th at 6am PST.
• Oct. 28th 6am PST — The release was postponed until 1pm PST.
• Oct. 28th 1pm PST — The release was postponed until 2pm PST.
• Oct. 28th 2pm PST — The release was postponed until 3pm PST.
• Oct. 28th 5pm PST — The demo was finally released.

This demo has been heavily anticipated for weeks, so needless to say people were very excited about it. After the first delay, most people were probably still too excited to care. After the second and third, the general populace was getting annoyed, but still had faith. But by the time it was delayed until 11pm (that’s 2am for us east-coasters!) people were starting to get quite upset. What was Valve doing that suddenly needed an extra five hours after already pushing the deadline by one hour several times? The comments on the official steam community group were shut down due to the sheer rage of Valve’s loudest fans.

When they missed the 11pm deadline, that’s when things got bad. Imagine living on the east coast and staying up until 2am to play the demo the moment it’s released only to find that shortly thereafter, Valve delays it until the following morning. Then waking up that morning only to find the deadline pushed until the afternoon!

And it didn’t end there. Even in the afternoon, Valve promised one more hour twice, then stopped updating anyone altogether before finally releasing the demo two hours later after a grand total of 8 missed deadlines in under 30 hours.

Now the proper way to handle a missed deadline is to give it one solid push, not to string it along for a day and a half. If Valve had come out on Tuesday and said “Sorry everyone, but we’re making some last minute changes to our servers and the demo won’t be ready until Thursday” then sure there would have been a bit of backlash, but nothing like what actually happened. Since this is the first push, the community can still have confidence that the new deadline will be met. And imagine how excited everyone would be when on Wednesday evening Valve releases it earlier than they had cited!

This was a serious mistake on Valve’s part. I’m not sure what went wrong or why they kept thinking they could fix it in under an hour, but they should have known better. They should have given it a big estimate with plenty of buffer in case more things went wrong — this would have been less stressful for everyone, and if it really only took an hour to fix, they could’ve just released it anyway.

2. Why it’s important to make awesome products

Because it makes people forget about things like a botched release date.

There’s no denying that the demo delivers. The new content is fantastic, and there’s just enough of it to give gamers a sense of what the full game will contain. It’s all kinds of fun, and the nature of Left 4 Dead means that the two levels available will be worth playing plenty of times — easily enough to satiate the cravings of many between now and the full-game release. A smashing success!

But back to my point. The blog coverage for the Left 4 Dead 2 demo between the afternoons of October 27th and October 28th was completely negative. Anger about the constant delays, blind rage directed at Valve, and users feeling that they could no longer trust their favourite publisher. How’s the blog coverage now? Very positive — everyone’s talking about how great the demo is. A couple of days’ worth of gushing is already drowning out all the bad press from the release. In a week, when the demo is opened up to the public, will anyone care that the pre-ordered version was a touch late? Of course not! It’s here now, and it’s awesome.

This is the power of a fantastic product. The power to overthrow 2 days’ worth of bad press and replace it with accolades.

What’s your take?

Can we draw any other lessons from this experience? Will Valve? Are you still pissed about how long it took the demo to come out? Leave a comment — I’d be glad to hear about it.