Zhephree

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.

I’m going to launch a snap-judgement on Facebook’s new Places feature, merely because I haven’t used it yet.

I echo Dennis Crowley’s comment that if Facebook wants in, then that means location will be a big platform for a while. That’s a good thing for foursquare and others like them.

But I am a bit nervous for foursquare. They were the only location-aware platform that is a Facebook “partner” that didn’t get early access to the Places API. This means foursquare is the only one without any integration into Places right now. (Well, not in development, at least).

But here’s the thing: I don’t think many people will leave foursquare for Facebook Places. Will lots of people use Places? Of course! It’s Facebook, that’s how it goes. If Places does anything, it will keep some people from joining foursquare. However, I’m willing to bet the majority of those people wouldn’t have ever joined foursquare in the first place, so it’s sort of a moot point.

Most people right now think sharing location data is a breach of your personal privacy, hence PleaseRobMe, and the wealth of blog posts whining about it. Most people hide foursquare check-ins that appear in their Facebook News Feed, and I see people whining about foursquare check-in tweets on Twitter daily. Right now, location is a niche and foursquare is at the center and top of that niche right now.  They’re offering an experience not available on any other social network: not Gowalla, not Yelp, not BrightKite, and not Facebook. The gaming aspect is better, the integration with real-world businesses is better, and they’ve already got a huge database of tips and tags and categorized venues.

A lot of people are worried about Places killing foursquare. To them, I ask “When has Facebook ever killed anything?”

When Facebook changed their stream to echo Twitter’s, people said it would kill twitter. Twitter still has millions of users and more and more businesses and individuals are joining every day. 

When Facebook launched its Marketplace, everyone said it would kill eBay and Craigslist. Does anyone even use Marketplace? And eBay and Craigslist are still going strong, and Craigslist is inching more and more into the public consciousness every day.

Facebook has been reported as the largest photo sharing site. Flickr, Picasa, and Photobucket are all still flooded with millions of images and users.

Facebook has also been reported as the largest video sharing website. YouTube and Vimeo are, like the photo sites, filled with millions of videos and users and grow every day.

When link sharing came to Facebook, people thought it was the end of bookmarking websites. Delicious is still huge and has millions of links posted to it.

And here’s why: few people generate original content solely on Facebook. Facebook has evolved into a Grand Central Station of social data from your friends. They cross-post statuses to Twitter and Facebook. They import their blog’s RSS feed into Notes. They crosspost photos to Flickr, Picasa, and Facebook. They bookmark links on Facebook and Delicious, and share them on Twitter and Facebook. They upload videos to Vimeo and YouTube and then post the link on Facebook.

I see location data being the same thing. Foursquare users will start using Facebook Places, no doubt about it, but they’ll be using Foursquare to initiate that data.

To many casual web users, Facebook is the entire Internet. In some ways, it is: it has so many features that, if it had a better search function, you could theoretically find any info you need on Facebook because someone most likely has posted a picture, video, link, or status about it. It’s the Google of social networking and adding in location data is a natural progression. I see Places as opening naysayers’ minds to accept location data as an acceptable thing to share with their friends and it will likely open them up to more specialized services, like foursquare.

Foursquare is a giant in its niche and I don’t see that changing. Places won’t make your mom or dad start checking-in, and it won’t make privacy zealots start checking-in either. It will, however, make those on the fence give it a shot. I post photos to Facebook and always have (and still do), but one day I needed something better, so I started using Flickr. I suspect something similar will happen with foursquare.

Synergy: it’s possibly the best thing about webOS. I can access multiple phone numbers, e-mail addresses, IM accounts, and Facebook account for a single contact, all in one place. After adding my Facebook account, I can upload pictures and video direct from the OS.

But Synergy can be so much more. For instance, look at Facebook: without a patch, adding your account doesn’t enable Facebook chat through the Messaging app, like AIM and other accounts do. 

And Twitter — there’s really no support for Twitter built into the OS, save for Universal Search.

Here’s my proposal to Palm: have an Accounts app where I can add my Facebook, Twitter, and other social media accounts. Let me send and receive Facebook messages through the Mail app as an account in the app. Let me chat through Facebook chat. Create a Publish app that lets me send pictures and text to Facebook and Twitter separately or cross-post to both. Build this into the OS.

And, allow apps to post through these accounts and get info from a user’s social graph. Similar to how apps ask to use Location Services, an alert that asks the user if, say, Bad Kitty can use your Twitter account. No need to go through the OAuth steps for every app that uses Twitter. Same goes for Facebook.

Now, obviously, this poses a problem for app branding. Facebook and Twitter each allow apps to have links below each post saying “via App Name” and that links to the website of the app, which promotes the app with each Tweet or status update. If every webOS app used the already-linked accounts in webOS, every app would say the same “via webOS” tagline. Not that helpful for developers. However, if I had both my professional account (zhephree) and my personal account (sirgeoph) already linked to webOS, a Twitter app like Bad Kitty could query the list of Twitter accounts and say “Authorize these accounts with Bad Kitty?” and as a suer taps on each account, they walk through the OAuth (or XAuth if webOS stored both the username and password) path to authorize the app to use those accounts, which then gives us the normal “via AppName” bylines.

While that might not save actual time, it does make the process seem easier. If I just had to tap on a few buttons to link an account that’d be way better than typing in my username in each app.

Or, if webOS stored the username and password for each account, an API in the SDK could have a method for connecting via XAuth. An app could initiate Mojo.Social.authorizeTwitter(“zhephree”) and then webOS would handle exchanging the username and password for a token which is then passed back to the application. This way, the app never gets the credentials, but it does get an authorization token so it could perform actions on behalf of the user. This makes things a bit more secure as you only give your phone your credentials and they could be encrypted and each app never sees the actual credentials.

This would require no typing from the user, just tapping a few confirmation dialogs. This would allow even more rapid development on webOS AND help make the OS more Synergistic. 

Just some thoughts.