dan-menard.com

I noticed a disappointing post via Slashdot the other day; apparently Namco has decided to force MIT to remove a PacMan clone made in Scratch. At face value, that probably doesn’t sound like a big deal to you, but that’s probably because you’ve never heard of Scratch. Allow me to explain.

Scratch is the future of programming education.

I’ve been teaching kids to program using Scratch for years (through OCRI). The reason we often choose Scratch is that it was made by MIT with the express goal of introducing students to programming and programming concepts (check out the About Scratch page if you’d like to learn more). The idea is that students who have never programmed before can create real, working software applications and share them online for other students to gain inspiration and learn from.

This is very similar to how real software development works. These students pour their heart and soul into creating something they care about, and proudly share it with a community that reacts to their ideas — adding features, remixing concepts, pushing the boundaries of what can and can’t be done. This is exactly how the web works. This is how kids learn.

Of course, if you’re Namco, that’s less important than preserving the copyright of a game that is older than almost everyone that uses Scratch (myself included).

Why is a Pac-Man clone important?

Several reasons:

First and foremost, it’s something kids recognize and can relate to. The tutorials for Scratch make some pretty bland applications, so to really push them to create something incredible, it’s important to show the students something they find impressive. The go-to applications for this are game remakes like Pac-Man and Tetris. Why? Because these games are instantly recognizable, and get students hooked on the idea of Scratch. They realize that with a bit of hard work, they can make something really cool.

Second, game remakes help the creative process. When you start with a blank slate, the idea of making something fun or interesting can be very daunting. Where do you even begin? For students, this can lead to frustration. Encouraging them to draw from other things they like helps narrow their focus without robbing them of choice. They can make something that they want to make, focus on solving the programming problems for that specific game, and make whatever creative changes they see fit along the way.

Finally, polished games are extremely difficult to write in Scratch (even something as basic as Pac-Man). These examples always contain interesting techniques and approaches to problem solving that show some really neat aspects of Scratch that I’ve never seen done any other way.

What does NAMCO get out of this?

You tell me. Do they really think people were lining up to play a Scratch version of Pac-Man? Are any of these (likely non-existent) people going to go out and buy a copy of Pac-Man from Namco now that the Scratch version has been removed? Other than ruining something that means almost-nothing to them and a whole hell of a lot to people like me, what exactly does Namco expect to accomplish?

What if they took the opposite approach. What if they decided that, copyright be damned, it’s awesome that 30 years later people still find the original Pac-Man fun. What if instead of being appalled, they were honoured that someone chose to learn to program by reproducing one of their games. Can you imagine a world where rights holders and every-day people with no intention of ripping anyone off worked together to promote culture and innovation? Because that’s not what I see here. I see a company that has its priorities so ass-backwards that it’s targeting a platform whose sole purpose is to help children learn.

Don’t they have better things to do?

Let’s talk about re-estimating software projects. Here is a situation I find myself in every now and then:

Say I’m the lead/best/only developer on a project, and partway through that project, we realize that we’re going to miss an important deadline. My manager will come to me with a question that I absolutely dread:

How much longer will it take?

It’s a perfectly fair question. Since I’m the lead/best/only developer, I’m in the best position to estimate how much more time is necessary, and my manager needs this information to make important decisions (add more people? talk to the client? etc). But it’s extremely difficult to answer! If the initial estimates (which I either came up with or approved) are wrong, how am I supposed to magically come up with better, more accurate ones?

The most important thing is to not answer on the spot; a great manager once told me that the best answer any time anyone asks you for an estimate is always “I’ll get back to you” and he’s completely right — there is absolutely no way you can put together a sensible estimate off the top of your head. Ever. You’ll always have to do a bit of math and take a few things into consideration, so give yourself time to do those things.

Now, let’s talk specifics. There are three main approaches I’ve seen myself and others use to re-estimate a project. For the following examples, let’s pretend that you’re in charge of a project that was initially estimated at 10 weeks, and after 5 weeks of work you find yourself 1 week behind schedule. How much longer will it take?

The Naive Method

The knee-jerk reaction that you might even say out loud if you answer on the spot is that you’ll need 1 extra week for a total of 11 weeks. The naive thinking here is along the lines of: “hey, we’re 1 week late, so give us 1 extra week to make up that work and everything will be fine”. The problem here, of course, is that if you have been late on your initial estimates for the first 5 weeks, you’re probably going to be late on your initial estimates for the next 5 weeks as well. We need to account for more than just the time missing so far. This brings us to:

The Logical Method

You may be thinking that the correct answer is 2 extra weeks for a total of 12 weeks, since if you need 1 extra week after the first 5 weeks you’ll probably need 1 more extra week on the 5 remaining weeks. That’s no longer a naive answer (it’s indeed logical) but your math is flawed and we can do a bit better.

Look at it this way: it took 5 weeks to do 4 weeks’ worth of work. So after 10 weeks, we’ll have done 8 weeks’ worth of work. Historically, if 4 weeks’ worth of work takes 5 weeks, then that last 2 weeks’ worth of work will actually take 2.5 weeks. So what you should be asking for is an extra 2 weeks and 3 days (always round up) for a total of 12 weeks and 3 days.

Now we have an entirely logical answer, and by all accounts you should be able to tell your manager with confidence that the project will be done after 12 weeks and 3 days. But here’s the thing — you’re probably still wrong. The fault lies in the very concept of estimates: you’re assigning a logical, mathematical number to the actions of real people with real lives and real feelings. If your team was entirely composed of robots, then yes, the logical answer is probably a great estimate, but that’s not how teams work. There are a number of estimate-affecting factors that the team dynamic adds:

• Some people will work longer days, evenings or weekends.
• Some people will “speed things up” by skipping test cases or code review.
• Missing milestones affects team morale.

None of these are always going to be good or bad for the project schedule, but it is foolhardy to ignore them outright. That’s why I believe in:

The Human Method

This is where it pays to know your team.

The idea is to take the proper logical answer, 12 weeks and 3 days for our running example, and tweak it based on the team dynamic. Does one of your fellow developers step up her game when the project falls behind schedule? Knock a day or two off the re-estimate. Do you have a teammate that gets easily overwhelmed? Add a day just in case. Is a stakeholder in the project going to want to have frequent meetings about why the project is late? That’s another day or two as well. You might be surprised at how things stack up: maybe it’s not as bad as you thought, maybe it’s much worse. But at least now you know.

Of course, you can’t always predict everything about your team, so sometimes you have to ballpark the team-dynamic chunk of the re-estimate. The best thing to do in this case is to err on the side of caution and add a buffer — something in the 20~30% range. For our example, that means adding another 25-ish% of the 2 weeks and 3 days that we’ve already added, call it 3 more days, bringing us to 3 weeks and 1 day. This means that our originally-estimated 10 week project is actually going to take a little over 13 weeks. Probably longer than what your manager was hoping for, but at least now we have some numbers to back it up.

And what’s your alternative, really? Make something up off the top of your head?

Let’s talk about motivation.

I recently joined Stack Overflow (here’s my profile) and one of the things I noticed right away is how easy it is to spend time there. I think I’ve checked in every day since I joined, and in ten days I’ve already answered fifteen questions. Now, before we discuss whether or not I’m developing an unhealthy addiction to social networks, I’m sure some of you are wondering what Stack Overflow is — let’s sort that out first:

Stack Overflow is a place where people can ask highly technical questions about computer programming and related topics, and get answers from a community of well-qualified geeks such as myself. When I log on, for example, I scan over a few dozen questions and answer any that I feel qualified to weigh in on. It’s free, self-organized, and completely voluntary.

Now, back to the issue at hand: why would I choose to volunteer my valuable free time answering other people’s questions? Or more specifically:

How does Stack Overflow motivate its community of users?

We’ll get to the answer in a moment, but before we do I’d like to take a moment to mention that I recently read Dan Pink’s Drive, a fantastic book about modern theories of motivation. I highly recommend this book. It’s an easy read that’s full of all kinds of useful information, and I’ll borrow a lot of its concepts and jargon in the remainder of this post.

Stack Overflow implements a wide variety of motivational techniques. For starters, all users have a “reputation” score which is basically a fuzzy measure of how well the Stack Overflow community trusts you. You earn reputation by asking and answering questions, so users that participate more actively in the community will get more reputation. Already that’s a form of motivation right there; the more you do for the community, the more reputation you build up.

Specifically, you gain reputation when you do positive work for the community. Users can vote on each others’ posts, so a good answer that gets a lot of votes will grant more reputation than a mediocre or weak answer (and likewise for questions). It’s very encouraging to see your answers get a lot of votes, and this sort of now-that reward (now that you’ve provided a good answer, we’ll boost your reputation) has been proven to be a repeatable tactic to motivate good behavior.

Similarly, good behavior is occasionally rewarded with badges. For example, if you answer a question and your answer is up-voted by ten different users, you earn the “Nice Answer” badge. This is known as an if-then reward (if your answer is accepted by many of your peers, then you get this badge added to your profile) and is historically a very effective technique for short-term motivation. Stack Overflow does a couple of things to keep badges relevant in the long term:

• Some badges are extremely hard to earn — I’ve seen a few that have only ever been awarded a few dozen times.
• Some badges can be awarded multiple times.

These conditions mean longtime users still have something tangible to strive for, so the motivational boost generated by badges doesn’t dwindle over time.

But rewards aren’t the only things that motivate us.

So far we’ve looked at the measurable ways that Stack Overflow motivates its users, but there are a number of non-measurable motivators as well. For example, the higher purpose of helping others and contributing to a database of valuable knowledge is a strong intrinsic motivator, and studies have shown this type of motivation to be the most powerful. On a basic, human level, we like to help each other out and do good work. Stack Overflow is an outlet for these tendencies.

Likewise, we enjoy pushing ourselves to master various skills. Like the carpenter who perfects his craft over years of experience, it’s rewarding for geeks like myself to hone the technical and communicative skills required to answer challenging technical questions. Not only do I learn something new every time I log on to Stack Overflow, I teach something new as well — this knowledge-transfer cycle is something I simply crave.

Let’s discuss this a little more.

If you’ve spent any time on Stack Overflow, I’d love to hear your take on this. Do you find yourself motivated by the factors above? Did I miss an important motivator that really drives you to contribute to the community?

Better yet, did you stop visiting Stack Overflow because you found it boring or uninteresting? What motivated you to leave?

As some of you may recall, I volunteer with the Ottawa Centre for Research and Innovation in a program that aims to teach high school students how to develop real, working software. I’ve mentioned this before (in fact, I have an entire page dedicated to what I do with OCRI), but I haven’t really been blogging about it much (read: at all) this semester.

Fortunately, my co-mentor for the past twelve weeks has. I present to you:

• An introduction,
• a feature,
• an update,
• and some remarks.

I’m not sure why I didn’t even check in once over the course of three months, but I’ll try to actively post about it next time around. This is something I like to talk about.

Finally, this season’s program ended last night with the annual showcase. This event allows students to demonstrate their final product, (hopefully) running on a real XO Laptop, to friends, family, mentors such as myself, students from other schools, and various representatives from OCRI. It was a fun time, and as always, the ability of students that are often being exposed programming for the first time to crank out creative, engaging applications is absolutely stunning. I couldn’t be more proud of the students I’ve worked with and the software we’ve created.

Ladies and gentlemen, allow me to share with you a tale of two photographers.

My fiancée and I were featured in a piece for our local newspaper a couple of weeks ago. The columnist wanted an image to accompany her content, so a photographer was sent to my apartment to take a photo of me and my bride-to-be.

This went down about the same way I expected. Some nondescript dude with a camera walked in, looked around the room for all of about six seconds, arranged a semi-interesting shot involving a mirror, snapped a few pictures and left. This took around ten minutes.

A few days later, the writer for the aforementioned article called back and asked if she could send over another photographer. Apparently the shot the first guy had lined up was too similar to a shot the newspaper was running on another article, on the same day, in the same section, so they needed a new one.

The second photographer was Christopher Pike.

Christopher ran things a bit differently. After introducing himself, he spent a few minutes looking around my humble abode and the surrounding area. He then asked my fiancée and I what we thought of a few potential shots, and started taking pictures. A lot of pictures. We posed on our balcony, on a bench, near a wall, next to a fence, under a tree, and probably in other places that I’ve since forgotten about. Every time Christopher noticed something that might make for a cool photo, he asked if we wouldn’t mind posing for it. In total, this process took over an hour.

It’s important to note here that the first photographer and Christopher were both freelancers hired by the newspaper. They were probably both paid the same amount. But while the first guy spent ten minutes taking a picture he had decided upon in advance, Christopher spent about seven times that long experimenting and looking for the perfect shot.

What does this have to do with programming?

Just like photography, programming is a craft.

That first photographer, the one whose name I can’t remember, was just in it for the job. The editor wanted a cute photo of a cute couple, so our unremarkable photographer took one and took off.

This is how a lot of equally unremarkable coders look at programming. You need a function that converts X inputs into Y outputs? Sure. Let me whip up a quick algorithm that does that. Done. What’s next?

Christopher, on the other hand, was there to take great pictures. He was passionate. He approached photography as a craft. Yes, the output was a photo that he could sell to a newspaper, but believe me when I tell you that’s not why Christopher is a photographer.

This is how I look at coding (and hopefully how you do too). You need a function that converts X inputs into Y outputs? Ok, let me consider the context, ask a few questions, then create a solution. Functionally, it will be the same as Joe-first-photographer’s solution, but as a programmer that cares about his craft, I took the time to:

• Verify that yes, a single function is the best solution.
• Keep future maintenance and extensibility in mind.
• Write clear, reusable code.
• Add useful comments where necessary.
• Refactor my function to be as simple as possible.
• Change all my spaces to tabs to match the existing code-base.

Which photographer would you rather hire? Which programmer would you rather have on your team?

Over the weekend, I picked up the Humble Indie Bundle, a pay-what-you-want download for five six games created by independent developers. I love these bundles! I get a bunch of cool software, the developers get a lot of blog coverage/followers/supporters/fans (let’s just call it social capital), and a cut of the proceeds go to a pair of great causes (Child’s Play and the EFF). It’s win-win-win. And it shows one of my favourite things about software:

Software is different.

No other industry can really get away with something like this. Can you imagine if those had been board games instead of computer games? Think of the logistics involved! Impossible. But software can get away with it, because once software has been developed, it costs almost nothing to make copies of and distribute. Different. Which reminds me:

Independent developers are special.

You don’t really see major publishers do this. You could make a case for Valve, because they really have this online-distribution thing figured out, but you’d never see EA partner with Blizzard for a heavily-subsidized package including Dragon Age and Starcraft 2, let alone see them donate the majority of it to charity. Independent developers can do this because they don’t operate under the same rules as major publishers, and they’ve found a loophole in traditional business beliefs that allows them to do something awesome that benefits them, their users and anyone touched by the charities they support. Special.

Now bear with me for a second, and let’s try to think of a market that sells and distributes software with a lot of support for, or even a huge bias towards, independent developers. Wouldn’t that be an ideal platform for more of these bundles? (Don’t cheat and say Valve; I know they’re cool, but that’s praise for another day and we’ve already singled them out above).

The App Store.

Apple’s App Store for iPhone/iPod/iPad contains around 200 000 applications* and is very popular among independent developers (I couldn’t find numbers for this, but polling my iPhone I’m going to wager it’s certainly a majority). With that many applications, developers could really use some extra exposure, and the visibility Apple is able to provide through the App Store is surreal. How long would it take for most iProduct users to hear about a group of independent App Store developers packaging a few apps together for the sake of charity if it was promoted directly through the App Store and/or Apple’s marketing team? Days? It would be a sure-hit.

Users would get more great software in a convenient, affordable, socially-rewarding package. Developers would get more copies of their app out there, and a compounding amount of exposure (word of mouth is big on iProducts). Apple would get some much needed love from their developers and their users (if anyone is hurting for karma right now, it’s Apple). And just think of the fantastic interface Apple’s brilliant designers could craft by integrating bundle-purchasing straight into the App Store!

There is a huge opportunity here.

Am I the only one that sees this? Tell me I’m not crazy.

* They announced at the iPhone OS 4 event back in April that they were over 185 000, so if 200 000 hasn’t been reached yet it’s not far off.

The other day, I came across a problem I frequently seem to encounter. I had a group-chat in Skype that I wanted to follow, but not necessarily contribute much to, and due to how often it was updating, it was getting annoying to have to constantly stop typing in my full-screen IDE and alt-tab back to Skype. I realized that it would be much more efficient if I could somehow temporarily designate that Skype window to always stay on top of the screen, the same way Task Manager does. That way I could be working away in my IDE, and when there were new messages in Skype I simply had to glance over, rather than alt-tab.

Naturally, I assumed this was a problem that was already solved, and a little Googling led me to a handy always-on-top toggle script that is activated using a hotkey. Perfect! Download, install, run, and within a few seconds I had my desired functionality… only the hotkey that the script uses to toggle the always-on-top property is ctrl-space, the same shortcut used for the absolutely-necessary auto-complete feature in Eclipse.

The script doesn’t provide any means for changing the hotkey, so I had to get a bit more creative. I set out on what I thought would be the difficult quest of figuring out how this script was made and re-making it with a different hotkey (I ended up using caps-lock). To my utter disbelief, it only took about five minutes. There were a few reasons why this was so easy to do, which I’ll get to in a moment, but first here is the script in case it might be useful to anyone else:

Download my Capsatop utility for Windows XP

No, I didn’t test it in Vista or Win7. Yes it might still work; please let me know if you try it. If you’re curious about doing this in linux or OSX, you’re on your own, but I’d love to hear about that too :~)

Now then, the rest of this post will be about why this was so easy to do, with a few lessons about good software tool development practices. For starters:

It helps when things are open-source.

That handy page I mentioned earlier was kind enough to mention that their ctrl-space script was made using a tool called Autohotkey, which I’d never heard of, and that it was only one line, which they provided:

^SPACE:: Winset, Alwaysontop, , A

So I downloaded Autohotkey, and braced myself for the impending learning curve. Fortunately, I was in for a shock:

Autohotkey is an incredibly intuitive tool.

It literally took me under two minutes to install Autohotkey, grok how it worked, and recreate the script with the line of code above. I credit this entirely to Autohotkey’s development team for putting together a really easy-to-use slice of utility software. Here are the things it got spot-on:

I gave a talk today at work about Flex and BlazeDS, and in particular how to scale both to perform well during high-volume, real-time communication with a Java-based server (in the area of thousands of messages per second). Here are the most helpful bits from my presentation and the ensuing discussion:

Stick to StreamingAMF.

When it comes to real-time data transfer, StreamingAMF is really your only choice for a high-performance endpoint. It offers two simple advantages:

• Streaming connections allow for true push, rather than less-effective fast-polling.
• AMF is a binary protocol, so less data is transferred across the wire.

If you need a more thorough round-up of endpoints, I highly recommend DevGirl’s excellent endpoint explanation.

Batch messages going through BlazeDS to save bandwidth.

BlazeDS adds significant overhead to each message sent across the wire. With thousands of messages per second, this adds up to a very significant amount of bandwidth usage, to the point that performance will be adversely affected.

To compensate for this, buffer consecutive messages together and send several at once. Even a simple timeout that buffers message content for 10ms before sending it all as a single message will save an incredible amount of bandwidth, and a smart buffer that adjusts its timeout based on message activity will do even better.

This is easy to implement, and likely the biggest performance optimization available in a high-volume situation. Definitely worth doing if bandwidth and performance are a concern.

Override default BlazeDS connection settings.

BlazeDS sets two interesting connection limits too low:

First, the <max-streaming-clients> property is used to limit the number of clients that can simultaneously stream from the same server. BlazeDS limits this to 10 by default, so if 11 users connect to your application at the same time, that 11th one won’t get through. This is a serious fault, but we can raise the limit as long as we’re smart about how high we set it.

The reason there is a limit at all is that all connections in BlazeDS use blocking IO. This means that the maximum number of connections Blaze will support is limited by the maximum number of threads in the application container, since it will always require one thread per connection. Fortunately, modern containers support much more than 10 concurrent threads; Tomcat 6, for example, reserves 150 by default and even that can be boosted.

So the rule of thumb here is that you don’t want your connections in BlazeDS to outnumber the threads in your container, and that’s what you should base this limit on. If you require more than a few hundred concurrent connections, you’re out of luck and you’ll have to either wait until Blaze implements non-blocking IO connections, or upgrade to LiveCycle.

The second, much-less-serious configuration is the <max-streaming-connections-per-session> property, which is used to limit the number of concurrent streaming connections a specified browser can support. If this number is exceeded, new connections will not open on the same client. BlazeDS defaults this value to 1 for all browsers, so if a user opens two instances of your streaming app at the same time, on the same machine with the same browser, the second instance will not open.

This limit is dependent on the browser, and many do actually have a hard limit of one single streaming connection at a time. However, newer versions of Internet Explorer/Firefox/Safari, most versions of Opera, and all versions of Chrome support multiple concurrent streaming sessions. To take advantage of this, override the limit in your services config; I’d suggest looking at Patrick Heinzelmann’s awesome RemoteServices example to grab the specific browser numbers and a nifty code sample.

Get low-level with Flash Player.

There are probably a lot of neat Flash Player performance hacks that I’m not aware of, but here are two I’ve figured out so far:

The default frame rate in Flash Player is not very high. I’m not entirely clear on what it is; I’ve seen some sources say 24fps, some say 12fps, and some say it’s completely dynamic. Depending on what you’re doing, you may consider boosting it to draw more often. In particular, this can lower the worst-case latency between a message being triggered, processed and displayed. The flip-side here is that a high frame rate will raise your CPU usage, so that’s a trade-off to keep in mind.

Secondly, for the longest time I was updating the screen whenever I had new data to display. In retrospect, this was ridiculous. How do I know if I’m updating more often than the screen is being refreshed? How do I know how long it will be until this update is actually blitten* to the screen?

A much less naive approach is to make screen updates on the ENTER_FRAME event. This is dispatched right before Flash Player refreshes the display, so it ensures that whatever you do here will be instantly reflected on-screen. As long as this is the only place you’re doing screen updates, you know that you are doing exactly one update per screen refresh, which is ideal provided you’ve calibrated your refresh rate to match how often you receive updates.

The Profiler is your friend.

After all the above tricks have been exhausted, if you still need a performance boost, there’s always code-level optimization. Things like unrolling loops and minimizing allocation using the “new” keyword will add up eventually. A good way to find out which areas will benefit most from such refactoring is to use the profiler that comes with Flex Builder.

The profiler will allow you to view object allocation stacks and method performance. The former is a great way to find memory leaks and the latter is fantastic for finding out which methods are the slowest and thus most qualified for optimization. If you have any curiosity at all about this sort of thing (and you should!) I heartily encourage you to open up the profiler and fiddle around with it a bit; it takes a bit of ramp-up but once you have it figured out it’s a totally indispensable tool.

Hopefully this will be helpful to someone out there. Flex and BlazeDS are both very well documented by Adobe, but these were the handful of cases where I had to go well out of my way to find workable solutions.

* blitten: Past tense of blit.

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?