To AIR or not to AIR – Pizza Hut

I read some posts over the weekend about PizzaHut’s new AIR application, “Pizza Hut Shortcut“. I quickly downloaded it, installed it and made myself hungry.

My first impression was good – it’s a neat looking app:

What I like about it:

  • Good concept – frequently needed, useful, practical, etc.
  • Good looking artwork, icon, etc.
  • Great use of branding – bringing brand to the desktop
  • If all pizza lovers install AIR, we’ve won!

Disappointments:

  • Other than some locally saved options and the ability to receive pushed ads, it doesn’t really take advantage of any AIR features such as local file access, local database, drag and drop, etc.
  • The actual ordering interface is just a tiny web browser – too tiny! – and lacking in any RIA features. It feels like a mobile phone browser! The Pizza Hut regular web-based ordering UI is actually much better than this AIR version. This is the opposite of what I expected! I was really hoping for a cool, graphical, drag-n-drop pizza-building interface! Talk about a Rich UI opportunity! Oh well… maybe in v2.0? 🙂
  • The application is set to automatically start at boot time and to “Alert me with new coupons and deals“. Although this does take advantage of some AIR features, it concerns me and could become a terrible trend that will give AIR apps a bad reputation. The last thing we need is a reputation of creating more advertising noise! I’m always interested in good pizza deals, but I don’t need them pushed at me! I’ll check for deals when I’m in a pizza mood!

So, this raises the big question – When should applications be written for AIR vs. left as a browser application?

Technical Considerations:

An application is a good candidate for AIR when any of the following are true:

  • Offline capabilities are required. This is the classic requirement that makes AIR ideal. AIR apps can detect network presence and react accordingly. AIR provides a SQL database and local file access allowing sophisticated data-related features to be implemented.
  • There is true value in leaving the application running in the background independently of the browser – such as notifying the user of status changes, alerts, etc. A good example of this is the FedEx Desktop – it provides real-time status updates for shipments. AIR even provides the ability to create taskbar/OS X Doc icons.
  • Local data provides significant performance gains, reduced server load or added privacy (allowing the user to add data that is not stored on the server). A great example of this is Matt Giger’s Earth Browser.
  • Desktop integration simplifies the application. The classic example is file drag-n-drop interfaces such as upload/download. There are many other good use cases for this feature such as allowing the user to select specific data/objects to drag to the desktop or another application.
  • Operating system integration is required. AIR provides OS integration that is just not possible with a browser application, such as creating file associations, tracking user presence (this can partially be done in a browser app), auto-launch, etc.
  • Multi-monitor support provides needed screen real-estate. Large dashboard-type interfaces can benefit from this. I’ve yet to see an AIR application utilize this.

(All of the doc links above are part of the Developing Adobe® AIR™ Applications with HTML and Ajax LiveDocs. Similar pages for Flex developers building AIR apps are available here.)

Non Technical Considerations:

There are also non-technical aspects to choosing AIR. Developers should ask themselves the following questions:

  • Will the AIR application truly be more useful than a browser version of the app? If not, why not leave it in the browser?
  • Will the desktop advantages be obvious to the user? It better be obvious or your app won’t stick around.
  • Am I making an AIR app primarily to put my logo on the user’s desktop without offering any real value over a web-based app? (If so, DON’T DO IT….PLEASE!)
  • Do I really need a desktop presence? Why?
  • Most important: Will the user agree that I need a desktop presence? This is critical. Users have a very different “policy” when it comes to installing software. It’s more “personal” than hitting a web page. There have to be clear advantages, otherwise your app becomes trash quickly.

There are plenty of great reasons to deploy AIR desktop applications. We’ve only just begun to see the true potential. The Pizza Hut app has some fun potential and could easily become a showcase AIR example. I hope v2.0 is already in the works!

~ by gregorywilson on May 28, 2008.

4 Responses to “To AIR or not to AIR – Pizza Hut”

  1. That’s a shame – it would have been awesome to have a whole online / offline ordering system with it downloading a copy of the menu into a local database. Oh well – I hope they make a version 2!

    And eesh! – horizontal scroll bars, whose fault is that?!

  2. […] Link: https://gregorywilson.wordpress.com/2008/05/28/to-air-or-not-to-air-pizza-hut/ […]

  3. […] Link: https://gregorywilson.wordpress.com/2008/05/28/to-air-or-not-to-air-pizza-hut/ […]

  4. i like it. pizza hut the best

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: