Thursday, March 11, 2004

Nintendo's New Portable

(originally posted at

The Register has an interesting story about what could be some leaked specs on the new Nintendo portable system - possibly dubbed the Nintendo Nitro.

It had been confirmed early on that this would be a double-screened device, which led me to question where the buttons would reside if it were a clamshell design.  The possibility of a tri-fold device dawned on me, but just didn't seem too likely.  The leaked document claims the device will have at least one touch screen.  This makes a whole lot of sense, but I'm not sold on whether it's a good idea.  Let's explore...

Nintendo's GameCube controller has one main "A" button and on diminutive "B" button which are the basis for most menu-driven game controls.  The "A" button (cleverly colored green) accepts a selected menu item and the "B" button (just as cleverly colored red) cancels selections or backs out of the menu.  During normal gameplay, these buttons (along with X/Y support buttons) take on a "virtual" quality - where their use is context-sensitive.  Their current context is usually displayed on the screen in the form of "A will now attack!" and the like.

Couple this with Nintendo's use of the GBA as an input device and support screen for some GameCube games.  In Legend of Zelda: The Wind Waker, the GBA is used as an extra menu system, but also shows maps and meta-data that you wouldn't normally have access to in the game.

So ask yourself, what lessons might Nintendo have learned from these experiences?

It sounds to me, that with the use of a touch-screen, Nintendo is looking to take input to a completely new level by making it completely virtual - an experience to be programmed by the game designers, not limited to the hardware.  You'd have a clamshell device with a main screen on one side and a support/input screen on the other.  This would allow developers to create input zones of arbitrary size and number, and at the same time use the input screen to display gameplay meta-data.  Sound neat, sound innovative?  You bet.

Here's the problem: people like the tactile sensation of mashing buttons with their fingers.  No, I don't have any evidence to back that up other than common sense and a myriad of gameplay hours since I was young.  What's more, with the GameCube's controller and virtual button setup, you could instantly pick up any GC game and almost instantly know which buttons do what.  If developers are allowed to go wild on interface design, that level of cohesion is lost.

Also in the specs are shockers like 802.11 and hardware-accelerated 3d graphics.  But those are side issues for me.  What's up with the touch screen, Nintendo?

Monday, March 08, 2004

iChat Wishlist

(originally posted at

About a week and a half ago, Apple responded to my iChat feature requests.

First and foremost I asked them to support XMPP-Core now that it's an IETF proposed standard.  This would effectively make iChat a multi-protocol instant messaging application.  During development of the first rev of iChat, the developers used the Jabber protocols as a model while the biz-heads worked things out with AOL.  Here's a post iChat's history.

Secondly, I asked them to fix their implementation of buddy groups.  Currently they use a drawer with checkboxes for the displaying of buddy groups.  Most other clients on the market use a tree-view, folder-list metaphor.  With their innovative implementation, Apple "fixed" something that wasn't really broken to begin with.

They responded by calling both items "known issues."  Obviously the lack of XMPP support is "known" - as it was simply a design choice.  But calling the current state of the buddy group implementation a "known issue" really surprised me.  Either they didn't really read what I wrote, or they're admitting that they made a mistake.  Either way, I hope I don't have to wait until 10.4 for the next rev of iChat.