Development on webOS is, for the most part, a dream come true. It’s fast, and if you have web development skills, it’s easy to learn. If you’re used to designing for the web, you’ll know that it’s generally pretty acceptable to style every widget or control, or even create your own widgets and style them however you like. No two web sites look alike. However, when designing native applications for a specific platform, there are certain things that users expect to happen or look.
For instance, if you develop an application that will run on Windows and OS X and you make a custom title bar at the top of your window, you’ll want to place the close button in the upper-right corner on Windows and in the upper left corner on OS X. If you kept the close X on, say, the right, Mac users would continually move to the left to close the window, and vice versa.
Or, look at web browsers, for instance. While Firefox, Chrome, and Safari all support reloading a page by pressing Ctrl+R (or Cmd+R), they all also support refreshing by pressing F5 because for years, most users were used to Internet Explorer using that shortcut for refreshing.
As you can see, desktop applications tend to follow a model to make it easier on the user. However, that’s not to say you shouldn’t stray for the norm. If you couldn’t stray, Firefox never would’ve had tabs, or Disco, the disc burning app on OS X, wouldn’t be semi-transparent and have smoke effects during the burning process. Breaking the mold is a good thing, but within reason.
Mobile applications have similar issues as desktop applications, except for the fact that you know (for the most part) every user has the same resources and hardware available to them. And not only that, you know that their mobile OS works the same across the board, at least that’s the webOS case.
When designing a webOS app, one should take in standard webOS conventions and appearances, while still offering a beautiful and intuitive application. I’m going to walk through a few key elements and give some examples of acceptable use.
Just Type
I’m not talking about the upcoming webOS 2.0 feature. I’m talking about the Just Type mentality instilled throughout webOS. webOS developers have the unique position of knowing that every one of their users has a hardware keyboard. Open up Contacts on your phone. Start typing a name. Boom, it starts searching. This idea should translate into your app. Foursquare does it by allow you to Just Type on the nearby venues list to start searching. Bad Kitty does this to allow you to start tweeting or searching for a user from any screen. Make sure you employ this in your app if applicable.
Scene Transitions
There are two types of transitions between scenes on webOS: zoomFade and crossFade. They are not interchangeable; they each mean something. zoomFade is for opening new scenes that are appearing at the top of the scene stack, such as dialogs or preferences, or a tweet or e-mail compose scene. crossFade is for swapping scenes, such as moving between scenes along a toolbar (like in foursquare, going between the Places view and then the Check-ins view).
Back Swipe
Another unique hardware feature for webOS is the gesture area. In other mobile platforms, like Android or iOS, apps have to use a back button on each view to allow users to move back to a previous scene. On webOS, users can simply swipe to the left on the gesture area to close a dialog or move to a previous scene. Do not place Button widgets on your scene that cancel or go back. This wastes real estate and breaks the mold too much. In fact, Palm will often reject apps for using back buttons instead of the back swipe.
Forward Swipe
This one is a bit controversial as it isn’t an officially supported requirement, but it’s useful and a few apps already use it. Forward swiping in the web browser moves forward through your history. However, in apps like foursquare and Bad Kitty, the forward swipe refreshes the current view, and TweetMe uses forward swipe to bring up a menu to refresh and scroll to top or bottom. It’s quick and easy, and removes the need to have a refresh button on your screen.
Buttons
webOS has native Button widgets. They have a few different kinds: primary (medium grey color), secondary (light grey color), affirmative (green), and negative (red). You really shouldn’t use these just to match your color scheme, instead use them for their intended purposes.
Let’s say you have a Twitter app and on your tweet view scene you have two buttons: Retweet and Reply. You want to encourage a conversation, so you want to make Reply a primary button. You’d then make Retweet a secondary button so that it doesn’t pull focus away from the Reply button, but also doesn’t look disabled.
If you had two options in a text editor app, Save or Discard Changes, you’d make Save affirmative and Discard Changes negative. This differentiates the two very different commands very plainly. The red lets users know right away that something bad will happen upon tapping it.
However, because these styles exist, it does not mean you shouldn’t innovate. For instance, Gowalla uses orange buttons for their primary actions, and I use bright green in foursquare for the same thing.
Honestly, this is perfectly acceptable. As long as you don’t misuse the supplied buttons, I see no harm in creating your own button colors to match your app’s color scheme. Speaking of color schemes…
Color Scheme
webOS uses a light blue and grey color scheme throughout. It’s not ugly by any means, but UI designers should absolutely improve upon this and make their apps personal. Look at the Amazon MP3 app — dark blue background with green dividers. The App Catalog — dark blue background with yellow/orange dividers and accents. There’s nothing that states you must use only the default colors and default widget styles.
However, there are exceptions, like Bad Kitty, which uses the grey and light blue color scheme to its advantage.
Custom Widgets
This area is also a bit controversial. While I think sticking with the native widgets, styling them to your liking is great, but sometimes, you need to create something totally different. For instance, Twee has its own Command Menu widget across the bottom and a custom-styled header.
Bad Kitty has a custom Command Menu as well, not to mention its totally custom horizontal menu.
Facebook brought with it a slew of custom widgets, one obvious one is the status update box below the header.
Another major custom widget is the header and navigation menu. The header is actually just a custom-styled ViewMenu widget. Tapping the far-right ViewMenu item displays the navigation menu, which is just a DIV styled with the palm-panel image. I used this same method for the foursquare navigation menu as well. This keeps with Palm’s idea that commands stay at the bottom and views stay at the top.
But then, you have the radicals, like Bad Kitty who have completely changed the way you navigate. Another great example of an app taking control of its own personality is Palm’s own Featured Apps. This app shows what great style can do for an app.
Featured Apps has a custom translucent header and nice light source coming down from the top. Viewing actual apps is nice with a custom horizontal scroller for screen shots.
Take Control
The overall point of the post is to inspire you to reach out further than what Palm gives you. Palm gives you the paints and the canvas and even the model, but it’s up to you to make it into something beautiful. I hate to conjure up other OSes, but take a look at iOS apps — many of them are beautiful, even the single-purpose apps.
Everyone should take control over their app’s personality. Should every app employ a graphic designer, or make use of drop shadows or artificial light sources or custom widgets? Absolutely not. However, there should be some personal style in your app that differentiates it from the others while still maintaining the design guidelines set by Palm.
I believe this so much so that even neato! is getting a UI redesign for the next version.
Don’t break the mold, but do bend it and stretch it out a bit.
