Zhephree

So, some time has passed since the open-sourcing of the Enyo framework and I’ve had some time to put aside my “Oh my god! Oh my god!” excitement and start formulating a plan and to reflect on what being a webOS developer has afforded me.

Let’s Take a Step Back
Mid-2009, Palm shows off the first webOS device, the Palm Pre, at CES. I happen to be in the market for a new smartphone. 

Actually, let’s take a few more steps back.

I’m a problem solver when it comes to the way I use computers. I’ve been a developer in some capacity since the second grade (built a Tic-Tac-Toe game in BASIC). Once I discovered Visual Basic 6 (using a “borrowed” copy from my uncle), I discovered that any time a program frustrated me, I’d just make my own that didn’t. Hated the calendar application in Windows 95, so I wrote my own to pop-up reminders for important events, like birthdays. The idea that I could fix something by creating something new excited me.

It was around that time that I got into web development. My first major web project was in high school where I built an online community around (yes, I know…) “new metal”. Yep, a community for Korn and System of a Down and Coal Chamber fans to post lyrics, photos, music videos, etc. It got pretty large. All of it was static pages. I’d take e-mail submissions and manually update the HTML files. A few things were done by copy-pasted widgets, but it was mostly static.

As I got older, I got into ASP, and later PHP, where I started to make websites for friends and family. I’d eventually start my own side business developing websites professionally, once my design and user experience skills increased. By 2009, I had been a professional web developer for about 10 years, both as a freelancer and for my day-job.

Now that you have my background, we can jump back to 2009.

So as I saw and read about webOS I instantly knew it was for me. Why? Because I could develop my own apps for my phone! I had never considered becoming an app developer by any means. I wanted to write apps for my old Windows Mobile 6 device, but frankly, I didn’t want to learn something new.

webOS opened a door for me to make my life easier, not only because the OS was, as I saw it, ahead of its time, but because I could make little apps that did things for me when I found things I didn’t like in existing apps.

And so I began writing the foursquare app for webOS. I wanted foursquare, but webOS users were out of luck. SMS was a terrible way to check in, and the mobile website required you to search for the venue, which wasn’t very helpful or speedy. So, I started writing the app, got some big help from a couple of other guys (Chris van Buskirk!) and the foursquare team (Naveen has had a huge hand in my success as a mobile developer as a result), and people liked what they saw. I made it prettier, made it more like the Android and iPhone experiences, and I got the confidence I needed to build more apps.

It’s important to note that I never intended my foursquare app to be used by anyone but myself. It was, in my eyes, a stop-gap until foursquare eventually developed one in-house. Unfortunately, partly because of my diligence and partly because of webOS’s lack of market-share, that never happened. So, as a result, I kept building to make the app what it is today.

The same thing happened when Google built Chrome-to-Phone for Android, an app that allowed you to send URLs from your web browser to your Android phone. I loved this idea and wanted, so I set out to build a little utility for webOS that did basically the same thing. Again, I was aiming to just make something for myself. But, people wanted the tool themselves and so I expanded its capabilities, made it prettier, and neato! was born.

Not much later, I did the same thing, only because Untappd’s mobile web interface couldn’t get GPS coordinates in the webOS browser, webOS users couldn’t add their location to their beer check-ins. So, to work around that, I built growlr, a little app to let you check-in to Untappd and attach your foursquare location to your check-in. I actually got the very first API Key for Untappd’s API to develop this app. Greg Avola, the CTO, had to add me into the database manually!

These three apps and the support from the webOS community made me realize that I was, sort of by chance, a mobile app developer.

Coming to Terms
Once I realized I was mobile developer, I needed new ideas. I also needed to make some decisions. 

I had come up with my latest idea — incredible!, a sort of aggregator for a user’s social media accounts — and I absolutely wanted it to be a webOS app. At this point, my then-girlfriend-now-wife Rhea was a Pixi user, I was a Pre user, and the murmurs of what webOS was going to be were loud. HP had purchased Palm and all we heard about was what great things were going to happen with this revolutionary mobile OS.

So, because of all of that, I put all of my eggs into the webOS basket and started development for incredible!. This felt like a good idea. Sure, webOS was barely fighting for 3rd place in the mobile market, but everything felt like it was going to advance. It felt like my choice was a smart one. As an indie developer, making the leap to crossplatform is expensive, what with developer program fees (about $100 on most platforms) and the cost of buying devices for each platform (and, in most cases, phone and tablet devices for each platform). It didn’t make financial sense for me to go cross platform at the moment.

So I stuck with webOS. And, despite HP killing off webOS hardware, despite webOS never reaching 3rd place in market or mind share, despite people laughing any time I said “webOS”, despite the quick buck being an iPhone developer made you at the time, this was the best decision I ever made.

I’m Ahead of the Game
You see, because I wrote my apps as webOS apps first, I probably missed out on some cash. That sucks. But, because the webOS community is so good and strong and supportive, and because the webOS Developer Relations group is so good and strong and supportive, I was somewhat successful. I have some dough in my PayPal account. Not much, but it’s there. 

But, because I chose webOS as my target platform, I’m ready for what 2012 webOS will bring. With the open-sourcing of Enyo, I can easily port my apps to iOS and Android using the same code base.

You see, I, today, right now, have a working version of my next app, Wooden Rows, running beautifully on webOS on my TouchPad. Taking that same code, I built a PhoneGap application and have that same app running beautifully on an iPad. And, because of the open source nature of webOS, the Android community has managed to get Android running on the TouchPad, which means, for free, I have an Android tablet to test on. Which also means, in addition to my same code running on webOS and iOS, I also have it running on Android.

That’s such an amazing thing to me, I want to state it again:

I have the exact same code for my webOS app running on iOS and Android.

Is it perfect? Nah, I have to make a few tweaks here and there, but the point is, it’s there and it works, and it’s worth charging money for in the App Store and the Android Marketplace.

And what’s awesome further is that because of webOS and Enyo’s web-based technologies, making my apps scale down to phone-sized screens is pretty much a matter of making some changes to my CSS for the app to work on smaller screens. I’m about 60% done getting my webOS tablet app working at phone resolutions on 3 platforms.

This means that Wooden Rows will be available on:

• HP TouchPad
• Palm Pre (all)
• Palm Pixi (all)
• HP Veer
• iPad (all)
• iPhone (all)
• Android phones (as many as possible!)
• Samsung Galaxy Tab
• Amazon Kindle Fire
• Other Android tablets

And that’s just the beginning.

So, again, being a webOS developer means that I have a cross-platform app almost ready for the masses, and I have a free webOS and Android tablet device. All because I made a seemingly silly decision to stick with webOS.

Looking Into the Future
Since I’m well-versed in the ways of Enyo, I am head of the game even into the future. Once Enyo 2.0 is fully baked, I’ll start developing all of my new apps using it and targeting webOS, Android, iOS, and Windows Phone 7. 

I can build apps for pretty much any platform using everything I know right now, without having to learn a new language. I can sell my apps 3 to 4 times over. 

I can, for real now, feel like a mobile developer.

And I owe every bit of it to choosing that Palm Pre back in 2009 and never looking back. Thanks, webOS community. Thanks, webOS Developer Relations team. 

In all of my apps, I use custom-colored command button widgets. They add a little personality to your apps, and don’t detract from whatever theme you’ve come up with. the webOS SDK ships with a few different colors: 2 shades of grey, red, and green, plus a dark charcoal one for dark themes. These will work for most apps, but not all.

For instance, in foursquare, I wanted to use green buttons for all major actions in the app. The standard green (class=”affirmative”) button is too green. I need more of a lime/neon green to match the foursquare colors. So, I did some research and figured it out.

So, how do you do it? Well, first off, you’ll need to make the graphics. I use Photoshop.

Find the original grey button widget PNG in the Palm SDK files. It’s in (share/refcode/webos-framework/###/images in the Palm/SDK folder). The file we want is palm-button-medium.png. Make a copy of the file in your project’s images folder and open the copy in Photoshop.

Go to Image > Adjustments > Hue/Saturation. You’ll see this dialog:

Check the Colorize box in the bottom right corner.The image of the button will probably change color to a reddish tint (if it’s anything else, that’s fine.) Let’s make a blue button. Drag the Hue slider (the first one) around until the very bottom color stripe becomes your desired color.

That’s a decent blue, but I want something deeper, and vibrant. Slide the Saturation slider over (the second one) until you get a nice, bright color.

You can see the button looks pretty nice already! Now, our app is going to have a medium-grey background, so, let’s make sure the button looks good on that background, since the button is translucent.

Click OK to save your colorization of the button. Click Layer > New > Layer. You can name the layer anything you want — we’re going to delete it later anyway. As you can see, your new layer is on top of the image.

Simply drag the new layer (Layer 1, in my example) to be under the image layer (likely, Layer 0). Now, set the foreground color to whatever color your app’s background will be and fill Layer 1 with that color. You can now see what the button will actually look like.

That looks pretty good! Now, delete your background layer (or simply hide it by clicking the eye next to the layer). Make sure you save the image as a 24-bit PNG to make sure the transparency works nicely.

Now that you have finished the graphic work, time to code it up!

In your scene’s view, you’ll want to put the HTML code for the button widget just like you normally would, but add another custom class to it so we can style it:

<div x-mojo-element="Button" class="blue-button palmbutton primary" id="checkinButton"></div>

As you can see, I added the “blue-button” class to the button. Next, let’s go ahead and style it with some CSS.

.blue-button .palm-button {  -webkit-border-image: url(../images/blue-button.png) 0 17 104 17 repeat repeat !important;  margin: 0;}
.blue-button .palm-button.selected.primary,.blue-button .palm-button.selected {  -webkit-border-image: url(../images/blue-button.png) 52 17 52 17 repeat repeat !important;}
.blue-button .palm-button.disabled.primary,.blue-button .palm-button.disabled {  -webkit-border-image: url(../images/blue-button.png) 104 17 0 17 repeat repeat !important;}

.blue-button .palm-button-wrapper {  position: relative;}
.blue-button .palm-button-wrapper .activity-spinner {  position: absolute;  right: 5px;}

By adding a new class to the button, we keep all the original buttons in tact and we’ll be able to use them in our app for less important commands.
So, that’s all there is too it! Just some points:

• Don’t overdo it: don’t make every button in your app a different color. I only change the colors of primary actions on a scene (login, check-in, etc.)
• Make sure text is still readable on your button’s background color. You can alter the CSS to change the text color if need be.
• Don’t use annoying colors. Keep it in the style of your app.

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.