Now that we’ve got a couple of weeks under our belts, the discussions and implementations of iPhone apps have started to gain some serious momentum, most notably being the brainchildren of iPhoneDevCamp and Joe Hewitt’s iUI. And while both examples point to a thriving community and serious improvement over previous mobile offerings, the developer guidelines that Apple has offered are just plain….well, underwhelming. Why? What did Apple get wrong? Let’s take a look at 5 very common interface standards that were overlooked when the iPhone application environment was created.

1. Alarms and Status Updates
   In a normal iPhone application — say SMS or Mail — a user receives feedback whenever activity has occurred in the background, or when the phone is sleeping. Whether it be a chime, vibration or icon update (think number of unread SMS messages), a message is communicated to the user, indicating that there is new information available. Currently, if Safari is not in the foreground, the only means by which to receive a status update is to open the browser window and refresh the web page….err, umm…I mean “application.”

   Solution: Provide the same sort of “numeric” feedback to the Safari icon, showing that an AJAX update has been made to a page. Better yet, provide a Javascript hook that lets you send alerts to the system message window (more on that later).

   

   fig. 1. Phone and Mail applications indicate that the application has new information.

2. Fixed Positioning
   Much has been discussed of Apple decision not to support fixed positioning on the iSafari browser. Without repeating much that has already been said, wouldn’t one of the most fundamental parts of application development involved easily-accessed menus, ones of a fixed nature? I’ve heard an argument that it would have been difficult to implement such a feature, given the concept of the viewport and pinch technology. That said, most of the iPhone-specific apps out there are limiting the scalability of the viewport, and are designing for the resolution of the screen itself. If that were the case, then pinch and expansion would be a moot point.

   Solution: Just go ahead and enable it. Search boxes and fixed menus for all!

   

   fig. 2. Telemoose provides a great example where a static search box would be nice.

3. Bookmarking
   Though the plethora of iPhone launch pages is growing (here, here and here to name a few), requiring a user to perform a minimum 3 clicks to access an application (Safari -> Bookmarks -> Link) is less efficient than having them click once from the Home screen. In addition, home screen icons would help solve the problem of status updates (see problem #1).

   Solution: Allow users to customize their home screen, adding shortcuts to Safari bookmarks. Perhaps use a favicon.ico-like tag to grab the icon?

   

   fig. 3. Blue Flavor has created some great iPhone apps. Apple, why not let them be added to the home menu?.

4. EDGE and AJAX
   Lord knows everyone loves an acronym. Let’s not give Apple too much credit for bringing AJAX to mobile devices. I mean, Opera Mini has been doing it for a while, but the iPhone, through its iSafari marketing, is pushing mobile AJAX into the spotlight. Great, right? Sure, except for EDGE. The beauty of AJAX applications is to pull a sleight of hand on the user, and update information seamlessly, or at the very least provide cues that information is being loaded. And while providing visual indicators is important to all AJAX apps, there is a sense of burden when having to compensate for EDGE. It distracts from the otherwise elegant interface of the iPhone.

   Solution: Provide interesting loading indicators, and pray that Apple has 3G up its sleeve.

   

   fig. 4. Use a loading image to pacify users who are waiting for EDGE to send updates.

5. Javascript Objects
   If you’ve ever developed a Dashboard Widget for OS X, then you’re familiar with the widget and flipper resources provided by Apple. They are created so that you can perform certain functionalities which are inherent to most widgets. A framework, if you will. Why did Apple choose not to create said resources for iPhone app development, or if created, why did they not release it to the general public? Surely, they’re available. I mean, aren’t the Weather and Stock applications using them? These would be a perfect means to provide hooks into commonly used objects: search boxes and — dare I say it — static menu bars.

   Solution: Let us in on the resources that the big boys are using. Or, if not available, develop ‘em.

   Secondary Comment: Don’t you wonder why Google and Yahoo! haven’t provided iPhone-optimized versions of their search pages? For cryin’ out loud, you have to pinch to view Google search results. They MUST have been privy to iPhone dev before the rest of us schmoes.

   

   fig. 5. Apple provides a Javascript widget object for controlling such common tasks as onhide and onshow events.

All in all, I have to say that the ingenuity of developed applications has been impressive to say the least. Kudos to all that have been given lemons and have made lemon sorbet.

Please feel free to add to the conversation below with other irks and oddities that may have been left out.

This entry was posted on Wednesday, July 18th, 2007 at 8:26 am and is filed under Design, Mobile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.