Digression: One Key, Many Moves

In my previous comparison article on Android, iPhone, and WP7, the biggest controversy so far seems to be the one-line dialog box issue. I knew there would be opposition when I wrote that claim, but I decided to say it anyway. It seems necessary to explain my view in more detail. Still just one opinion, for reference only.

We all remember playing fighting games in arcades as kids—Street Fighter, King of Fighters, Samurai Shodown. The most powerful “special moves” were always the hardest to execute. I remember that in Samurai Shodown, Haohmaru’s Tenha Fūjin Zanken, if fully landed, could take off 70% of the opponent’s health. Do you remember how to execute it? It was ↘←↙↓↘→←↓↙+BC. People who could reliably pull off the Tenha Fūjin Zanken were considered legendary masters in our eyes back then.

As technology advanced, emulators like Nebula appeared, supporting online play. Another benefit of emulators was macros—you could program complex commands into a macro, then execute them with a single button press. This feature was incredibly powerful. With one button, you could unleash legendary secret moves. For someone like me who never could execute the Tenha Fūjin Zanken in the arcade, I could now unleash it freely at home on my computer. Amazing!

Caption: With one-key Tenha Fūjin Zanken, even the referee is no match for me.

Arcade emulators supported online versus play. Back in 2003, I played a couple of rounds of Samurai Shodown in the software school computer lab. It felt completely different from the arcade. In the arcade, if you were killed by an opponent’s Tenha, you’d look up to them with admiration. But online, thanks to “one key, many moves,” everyone could spam Tenha Fūjin Zanken at will. Two Haohmarus would be slashing each other with Tenha Fūjin Zanken—you do one, I do one. The game’s playability took a huge hit, and it wasn’t much fun anymore.

Why bring up this example? Just to illustrate that sometimes “one key, many moves” isn’t a good thing—it leads to abuse of the feature. Abusing Tenha Fūjin Zanken ruins Samurai Shodown. Of course, you could say to kick out people using cheats. But imagine if SNK had included a dedicated Tenha Fūjin Zanken button in the original game, with built-in one-key execution—would Samurai Shodown have become as popular as it did?

MessageBox may not be as powerful as Tenha Fūjin Zanken, but its effect is similar. Used well, it can enhance an application and show thoughtfulness. But overused, it has副作用 (side effects). For features with very low misoperation probability, constantly alerting users becomes annoying. Some apps even pop up dialogs for successful login or successful save. Some people even use MessageBox for debug output.

Compare this with Android’s notification system. In Android, there are several types of notifications:

1. Synchronous notifications that don’t require user intervention—like successful login messages. In Android, these use Toast, implementable with one line of code. Users don’t need to respond, and the Toast disappears after a few seconds. These notifications cause minimal annoyance, and even overuse is unlikely to bother users much.

2. Asynchronous notifications requiring user intervention—like missed calls or incoming texts. In Android, these use the pull-down Notification bar, which takes about 10 lines of code in the simplest case. These do annoy users, but users can ignore them. Those with洁癖 (OCD tendencies) who find notifications annoying can batch-clear them.

3. Synchronous notifications requiring user intervention—like password errors or batch deletion warnings. These use Windows-like dialogs, taking at least 20 lines of code for the simplest logic. If users don’t respond, the dialog stays on screen. If abused, these are the most annoying.

Every Android beginner has this experience: “I want to display something on screen. Based on experience, the most direct approach is a dialog box.” Then they Google it and think, “OMG, a dialog is this complicated? So many lines?” Then they discover Toast, which can also display something on screen with just one line. They use Toast instead. That’s guidance. As a platform designer, you should provide explicit or implicit guidance to platform users, minimizing potential misunderstandings between designers and users. That’s also one of the principles of HCI design.

I suspect that when Google designed the Android API, it wasn’t that they lacked the technical ability to make one-line dialogs. They probably故意提高 (deliberately raised) the bar for dialog creation, hinting to programmers that this feature might have side effects and should be considered carefully before use.

A Samurai Shodown where everyone abuses Tenha Fūjin Zanken is not a good Samurai Shodown. A platform where most applications abuse dialogs—what does that make?

One last thing: I’m not writing this to dismiss the Windows Phone platform, just discussing the one-line dialog issue specifically. One-line dialogs exist across all Microsoft platforms—from Win32 API, MFC, WinForm, WPF, Silverlight, etc. This might be technical inertia. If iOS also allowed one-line dialogs, the same critique would apply. Even if the dialog problem exists, it’s a minor issue—trivial compared to architecture, strategy, or marketing.