Zhephree

We're Not Paying Enough for Apps

I definitely agree with the sentiment of this article, but the author is still an idiot. He still never bought the app, even after being convinced that the cheaper, free apps were lower quality.

Finding the sweet spot of app pricing is an art. Price too low, and you’re undervaluing your product. While a low price may move more units, your profit is roughly the same (as evidenced by Steam’s data in the article, and my personal experience). And, with a lower price, you now have more users. As a solo or indie dev, this means your quality of support and frequency of updates suffers, which means your customers get an inferior product.

Pricing your app higher, though, does make life easier. You’ll sell fewer copies of the app and likely drive up the amount of piracy (though, in my experience, people pirate my $1.43 app as often as my $3.99 apps, which is to say a lot). However, having fewer users means that the personal level of support my customers are used to can continue. And, if I’m supporting fewer users, I can have more time to improve the app and push out updates.

If I have 100 users that bought my app at $3.99, I can support the 10 or 20 of them that will ever contact me for support and still have free time to live my life, time to improve the app, and time to make more apps. However, if I drop the price to $0.99, I’ll now have around 400 users. I have now made the exact same amount of money, but now I have more users to support and more users expecting updates. As a solo developer, this means my ability to support users dwindles and my time to improve the app dwindles. This sucks for everyone.

In fact, if you look at the gross sales of a $3.99 app to 100 users (100 is a quick, round number to do some math on), it’s around $400 (before app stores take their cut). So, you make $400, your users love the app, they get personalized support direct from me via Twitter or email, they get frequent updates, and I have time to hang out with my wife. Everyone’s happy!

Now, let’s say I drop the price of my app to $0.99. The lower price point means more users are likely to download the app and give it a try as there’s less to lose if they don’t like it. In my experience, this is exactly what happens — lower price equals more downloads. However, the amount of extra downloads rarely (if ever) exceeds enough to increase my profit. At $0.99, I garner about 4x’s as many downloads, yielding 400 users. 400 users at $0.99 means my gross sales is still $400. 

By lowering the cost of my app, I have higher download counts and more users, but still have been compensated the same amount as if only 100 users downloaded my app at full price. The only difference is now I have four times as many users to support, which means four times as many users with problems and issues. The 10 or 20 users that might contact me for support before has now increased to 40 or 80 users contacting me. My response time on support requests increases, which makes for angrier customers. This also means that I’m now spending time fielding support requests instead of developing and improving the app. This also means that my free time dwindles. This also means that my happiness drops, destroying the very reason I develop in the first place.

And what do I have to show for all that added effort and stress? The ability to say 400 people downloaded my app rather than 100. No additional revenue. No new features. No extra praise. Now, consider this while using real download numbers. 1000 vs 4000, 10000 vs 40000. The problems increase exponentially (400 to 800 requests, 4000 to 8000 requests).

Not only that, but more users means more hits to my web server for data retrievals and log ins, image uploads, etc. More hits to my server means more bandwidth usage, which equates to more money. I am now receiving a net profit that is less than the higher price point with fewer users, in addition to the headaches outlined above.

Obviously, money isn’t the main reason I develop. I love doing it. I like creating things. But, I have bills to pay and my stomach’s growling is pretty loud, so I tend to enjoy putting food into it.

Additionally, I enjoy making something that other people enjoy and can use every day. I can’t do this when I’m spending all my development time answering emails or engaging in a Twitter conversation.

I’m seeing this in just 4 days of lowering Wooden Rows to $1.99 for a 1 week promotion with HP. I’ll probably never do a sale like this again as a result, but we’ll see how it turns out by Thursday when the sale ends.

So, for me, as an indie developer, I’d prefer to have fewer users at a higher price point than more users at a lower price point.

Update: @tross1312 on Twitter raises an interesting question: 

Do you think people who buy at $1 but not $4 bring different expectations? Perhaps a difference in type, not just numbers.

I definitely think this is the case. If an app is priced at $3.99 and a user decides the app isn’t important enough to them to spend that amount on it and doesn’t purchase the app, but will buy it if the price is dropped likely doesn’t see the value in the application as a whole. The odds that users that only buy at a sale or lower price will contact you for support are higher. I’ve had more support requests and more negative reviews of the app since lowering the price. Users willing to pay the original asking price (be it $4 or $1) are more likely to understand the value of the app are less likely to require support (except for legitimate bugs in the the development of the app).

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. 

I started this rant on Twitter, but I want to expand on some ideas here. I started this off with:

Companies only producing mobile apps for a single platform to promote a product is the modern version of “Best Viewed in Internet Explorer”

To clarify, I’m talking about apps that are basically advertisements masquerading as apps, like Absolut, Abercrombie & Fitch, Ford, and Tic-Tac. These apps exist to essentially buy ad space in the iTunes App Store. They generally just sport in-app viewing of TV commercials, store locators, etc. Nothing a mobile website couldn’t do already.

It’s a smart idea: give users something cool and fun, while advertising your brand like crazy.

There are two schools of thought for advertising: get as many eyes as possible on your advertisement, or, target a specific demographic.

In some cases, like Abercrombie & Fitch, their brand is probably targeting the iPhone crowd: people with more disposable income than most and like to stay up on what’s popular and trendy. It makes sense for them to have an iPhone app.

But what of brands like Tic-Tac and Ford? Tic-Tacs are affordable for anyone and people of all demographics eat Tic-Tacs. Why target the iPhone demographic? Same with Ford — most Ford truck drivers aren’t the iPhone crowd. 

Let’s look at some numbers. 91% of Americans use a cellphone of some kind (feature phone, flip phone, pay-as-you-go, smartphone, etc.). So, if you’re trying to hit a big market, targeting cellphone users makes sense. In theory, you’re hitting 91% of citizens.

Now, let’s say you decide to make a smartphone app. You then cut out feature/flip phone users and most pay-as-you-go users. You are now servicing 27% of cellphone users. Looking at the previous number, that means you’re targeting 24.57% of all Americans. Not terrible.

So now that you’re deciding to target smartphone users with an app, you have to choose a platform. You decide on iOS. 25% of smartphone users have an Apple device. You are now targeting 6.75% of smartphone users, which translates to 6.1425% of all Americans.

By targeting iOS only, you have brought the potential from 280 million people to see your advertisement down to 19 million. Now, this is still a great number of people, but then look that 34.4% of smartphone users download apps. You now are targeting 6.5 million people.

Does that really make sense? Out of the 6.5 million possible users, a smaller percentage will actually download your app. That number drops yet again.

Targeting only iOS makes no sense. Creating an Android version of your app adds another 15 million potential downloads — more than three times as many potential users.

Obviously, multiple platforms yields higher development costs. But, what if you could write code once and make it work on multiple platforms? Try PhoneGap. Write your apps in HTML, JavaScript, and CSS (which means you might be able to develop the app in-house, reducing costs) and then compile for iOS, Android, BlackBerry, webOS, Windows Phone, and Symbian. If your branded app is a simple app that doesn’t rely heavily of native features of the device, PhoneGap and frameworks like it can save you tons of cash and produce a larger number of potential users, yielding a much higher ROI.

It just makes sense this way. Yet, for whatever reason, everyone keeps making branded iOS apps.

I came across this article on carpeaqua. It details how he handles his apps in the Apple App Store, but he’s feelings are universal, regardless of your app market.

He holds three truths when it comes to apps:

1. I will never read the reviews of my apps.
2. I will never put a $5 app on sale.
3. I will never blindly throw promo codes out via social media services.

I never really considered these mindsets before, and the more I think about it, it makes sense. 

I’m gonna cover reviews only because that’s the biggie.

I’ll be honest — I read reviews of my apps often, every couple of days I check them out to see what people are saying. All of my apps have good or great ratings. growlr has a 4.7 rating, neato! has a 4.6 rating, and foursquare has a 3.6. I can theorize why each of those have their respective ratings, but I won’t. I know one thing: my apps have good ratings.

Consider foursquare, since it has the lowest of my three apps: a less than 4-star rating. It’s a great rating. A 3.6 means that more than 50% of the people who have used foursquare really really liked it. It also means less than 50% either thought it was okay or sucked. Consider that last part: less than half the people that use it think it’s just “okay” or sucked. That’s awesome!

Foursquare is an app built on top of someone else’s API and service. While I get really close support from the foursquare team and get early access to new features, I still have someone else to wait on for some things to be fixed or changed or added. Users don’t know this and they don’t care. Users see an app, download it, and use it. If it isn’t want they thought it’d be, they’ll either never use it again, or go give it a bad rating and never use it again. No amount of educating will solve this. In fact, the ONLY thing between potential users and yourself is the app’s description in the Catalog and I will guesstimate that about 25% of users actually read ALL of the description and fully comprehend it. If you mention in your app description that it is for webOS 2.x only, in all caps, on a line all by itself as the first sentence, you will STILL get users asking why it won’t work on their 1.4.x device. You could personally call every webOS user and speak to them on the phone and tell them your app is webOS 2.x-only and you would STILL get people complaining that it won’t work on 1.4.x.

If you put all of the possible info in your app description, you supply help inside the app, you supply an email or contact form inside your app (not everyone uses Twitter!), you have fixed every bug you possibly can fix and you still get bad reviews, ignore them. You’ve done it. You’ve made the perfect app and made yourself accessible. There is nothing else you can do. Those users will write bad reviews regardless of what you change.

The majority of bad reviews for foursquare are because of GPS issues. I love you, Palm, but your GPS hardware sucks and Verizon’s crippling of it doesn’t help. I get better GPS accuracy on zeldamac’s iPod Touch than I do on my Pre Plus. Hell, I get better positioning from the old guy selling fruit on the side of the road (“Go up till you get to the fork in the road, then take it.”). I’ve done a lot with coding. I’ve done a lot with error handling. I’ve written blog posts and tweets with best practices for GPS accuracy and still, there are problems. I get users who post bad 1 star reviews because of this. My feeling about this:

I don’t care.

Seriously: I don’t. You know who I DO care about? The users that send me an @ message on Twitter asking me about GPS issues. The users that use the in-app contact form to e-mail me GPS issues (helped 2 people this week get better accuracy: one from twitter, one via email). These are users that care enough about your app to learn how to make it better. These are your users. Your users aren’t the 1-star reviewers. Those are guys that go around downloading every app they see, try it once, and if it doesn’t work, they give up. Honestly, chances are, if they didn’t leave then, they’d leave later.

You will always have angry users (or, “downloaders” in most cases). foursquare is continually featured in the Catalog. It has a 3.6 rating. It has been downloaded, uniquely, almost 90,000 times. It is often lauded as the best foursquare client, better than the in-house-built Android, iOS, and BlackBerry apps. It has been reviewed almost 1000 times. It’s a good app. Could it better? Absolutely! Could it be worse? Also absolutely!

Look, it’s a free app. If people wanna waste time complaining about a free app that lets them tell people that they’re buying groceries or drinking coffee, then so be it. That’s their right. I don’t lose money or sleep over the fact that John Z in WhoKnowsWhere thinks my app sucks. Besides, it’s not like I can respond to him. 

As for paid apps, I care slightly more, but not much. App reviews really don’t influence downloads. Actually, I’ll revise that: the only app reviews that influence app downloads are the 5 most recent. No one really scrolls and reads all the reviews. So, if you have 3 or 4 bad reviews in a row, wait it out — you’ll get some good ones that’ll push those out of view. Remember — users want things RIGHT NOW. If the top 4 or so reviews are positive, then they’ll likely download it. They don’t have time to scroll down.

So what if the user sees 5 bad reviews at the top? They’ll be back. If there’s a competing app in the catalog and your app is honestly better, they’ll come to yours. If your app isn’t better, well, then, they would’ve left and gone to the competitor eventually anyway. Stop making crappy apps.

The TL;DR Version: Ignore app reviews. Focus on making an awesome app and people will use it regardless of of the reviews. And make it have a pretty icon. Seriously — people will buy an app with a pretty icon over an ugly one, I promise you. (One of the biggest complaints I got from the newest version of neato! was they didn’t like the grey icon. They all wanted the blue one back. It’s still grey, btw.)

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.

For those with short attention spans, here’s the TL;DR version:

I am continuing development of incredible!, but I am going to finish the Mojo version quickish to get it in your hands, then build an Enyo version. I need pledges from you guys because I need the new hardware and building the app twice will cut into my freelance web design money. Pledging $5+ gets you the app for “free.”

I’m also freezing features of neato! and foursquare and just issuing bug fixes for them and will port them to Enyo later this year before Mojo support is cut off in newer devices. Any new apps I write will be strictly Enyo.

Here’s the deal: (And if you don’t know what incredible! is, check this PreCentral article)

As a webOS fan, you’ve no doubt heard the latest announcements from HP — three new devices (including a tablet). This all looks amazing!

Another announcement, unfortunately, was made: webOS 2.0 will not be delivered over the air to current users, which means even if HP offers a computer-based upgrade to 2.0 or offers discount vouchers or even free devices for existing users, a lot of users will still be stuck on 1.4.5 (or even 1.4.0 for those in Mexico!).

Another point is that these new devices won’t be out until spring (Veer) and summer (Pre3 and TouchPad). That’s a long time in the tech world.

In addition to new devices, a new development framework was released in alpha (Enyo). Enyo completely changes the game and is a welcomed tool for webOS developers. However, as of right now, Enyo will only be supported on Pre2, Pre3, Veer, and TouchPad. On the other hand, the current framework, Mojo, will be supported for a few months to a year on ALL devices.

SO WHAT ABOUT INCREDIBLE!?

incredible! is about 60% completed and is written in the Mojo framework. This means, if I finish it as is, it’ll run on all webOS devices, even the new ones, but for an indeterminate amount of time. However, because of the uncertainty of the 2.0 issue and because these new devices are still a ways away, I don’t want to jump to Enyo just yet (plus, Enyo’s still only in Alpha).

I do not want to abandon all of the webOS faithful by moving strictly to Enyo and making you wait who knows how many months to use the app. By the same token, I don’t to leave the new devices in the dark once Mojo support vanishes. In addition, incredible! is an app that’s just screaming for more screen real estate, so it absolutely must be tablet-ready.

So, I thought long and hard about this and talked the options over with my fiancée (@zeldamac), and I came to a plan.

THE PLAN

I’ll finish developing incredible! as a Mojo app and get it out there for everyone that’s been waiting and waiting for it. Once a non-beta version is completed, development on the Enyo version of incredible! will begin (or, maybe be developed concurrently).

I know everyone’s been waiting for this app, from foursquare users, to neato! users, to other developers (Inglorious Apps comes to mind), to pretty much the whole staffs at PreCentral and webOSroundup, to Rod Whitby, to a number of Palm/HP employees. And yes, I  did that half-assed name dropping to hype up the app even more.  This app has been touted and hyped about as much as, well, new webOS devices and its release keeps getting pushed back like, well…

I don’t want to leave you guys waiting and I don’t want you to get a crappy version of the app.

WHAT’S THIS HAVE TO DO WITH YOU?

Here’s where you guys come in: this isn’t free. I’ll need new devices for testing and developing, especially a TouchPad. In addition, because I’ll basically be developing incredible! twice, this will severely cut into my freelance web designing, which supplements my income right now. Basically, I’ll be putting that aside to develop incredible! for Mojo and Enyo.

So, because I’ll be missing out on that extra money from freelancing (which, after buying the house, about to get married, I really need… </shameless-guilt-trip>) and because new devices aren’t free, I’ll need some working capital to pull this off and give me incentive to stay awake for 8+ months straight and to take @zeldamac out to eat after I spend way too much time writing code.

So, I’ve set up a RocketHub project for incredible!. If you’re unfamiliar with RocketHub, it’s a website where people can pitch their idea or project and have people “back” the project by throwing money at it. RocketHub is all-or-nothing funding. This means that I only get the money if the goal I set is reached. If the goal falls even $1 short, I get $0 and your credit card never gets charged. It’s exactly like Kickstarter, except they don’t have a silly approval process to post your project.

What’s in it for you? Well, you’ll get the app. There’s also a bunch of various rewards depending on how much you pledge.

Plus, you’ll know you supported an independent developer and webOS. If I’ve got new devices, you can believe more kick-ass webOS apps will come from me.

I know this is a bit unusual, but right now, it’s an idea I had and I hate to let ideas just sit in my head. They get lonely by themselves in there. (THAT’S A JOKE ABOUT HOW EMPTY MY HEAD IS)

WHAT ABOUT YOUR OTHER APPS?

Good question! I am not stopping support for foursquare or neato!. However, I am freezing the feature sets of both apps. This means any foursquare or neato! updates you get will be maintenance and bug fix updates. So, don’t worry — if foursquare or neato! breaks, I’ll fix it in the same amount of time it currently takes me. 

This does mean, however, that down the road I will port foursquare and neato! over to the Enyo framework before support for Mojo apps is pulled from new devices. This is why I am not adding new features to either app. No sense in writing new code that will just have to be rewritten later this year. I don’t want to give a date for when the apps will be ported because, well, I have no idea when Mojo support will be dropped.

As for any new apps (Yep, still got a bunch of ideas for new ones), if I even have the time for those this year, I’ll start those off in Enyo for new devices only. It just makes sense. Sometimes, you have to move on.

WHAT HAPPENS IF YOU MISS YOUR GOAL?

Also a good question. I’m not sure about this yet. We’ll have to see where things go. For now, this is the plan. I’m not sure if it’s a good plan. I’m sure some people will think it’s stupid and think I’m wasting my time, or I’m begging for free money. Who knows, maybe I am. I just want to develop for webOS and having the devices in hand would be a big help.

NOTES

Sure, I can develop without devices, but nothing beats debugging and testing on a real device. My Macbook is far more powerful than any of the new webOS devices, so I won’t know exactly how fast the app is, or if it lags. Plus, the emulator just isn’t 100% exactly like a device.

Also, since if you donate over a certain amount, you get the app anyway without having to buy it later on, you can think of this as a preorder or a “Groupon”.

CLICK HERE TO HELP FUEL INCREDIBLE!

Foursquare co-founder Naveen Selvadurai asked me to give my perspective on developing against the foursquare API. I’ve been using the API since before it was fully public and I’ve seen it go from often inconsistent infant to a fast, secure, and predictable (in a good way) adult. I went on a poorly thought-out ramble in an e-mail to him, and he asked me to blog about my experiences so it could benefit other developers (not just webOS or foursquare developers either).

I started developing against the original early pre-public v1 API in late 2009, when the company consisted of 4 people. I had just gotten a webOS phone and no foursquare app existed, so I took it upon myself to make one. Foursquare had an API, but it wasn’t really ready for prime time. The JSON responses were pretty inconsistent, and not just between endpoints — the same endpoint would return data in different formats, seemingly willy-nilly. With some suggestions from other developers and myself (and foursquare’s own findings), they cleaned up the v1 API and things got better. Data was mostly consistent, but some special bits of data required some guess work or discovery of undocumented features. I had to look out for 3 or 4 different data structure scenarios just to get nearby tips or something basic like that. Aside from that, I was new to webOS, so I was learning two things at once.

Late last year, foursquare (now some 40 people strong) released v2 of their API which uses OAuth 2 (woohoo!) and returns only JSON responses (double woohoo!). Data is extremely consistent. For instance:

{
   meta: {
      code: 200   },
   response: {
     groups: [
     {
       type: "trending",
       name: "Trending Now",
       items: [
       {
         id: "49bc3b0af964a52020541fe3",
         name: "Whole Foods",
         contact: {
            phone: "2123496555",
            twitter: "WholefoodsNYC",
         }

That’s the beginning of a response on a venue search. The meta object gives you the HTTP status code and any error messages you might have. ALL responses have this field. Makes for catching errors very easy. After that is the response object that contains the actual response. Again, ALL responses have this. Most arrays have a groups object that always has a count parameter which gives the total count that exists in the collection, followed by the items array that gives you the actual items you want.

Replace venues with users, photos, tips — it doesn’t matter. They all follow this pattern. It takes the guesswork completely out of the equation.

But enough about how great the API is — what general things did I learn?

When I was still using the v1 API at first, I was making regular old prototype Ajax.Request calls to download endpoint data from foursquare. No big deal, it worked. But by doing that, I had to copy/paste error handling code. I had to duplicate a lot of code throughout the app. Not only that, sometimes the JavaScript engine would garbage collect the request and you’d get no data.

So, I created a wrapper function for GET and POST operations. I won’t go into the code of the actual function, but here’s what a call looks like:

foursquareGet({
  endpoint: 'users/self',
  requiresAuth: true,
  parameters: {some: param, some: value},
  onSuccess: successFunction,
  onFailure: failFunction
});

Basically, you supply the endpoint and some parameters and the function builds the URL for you. If the call requires an acting user, it’ll also append the HTTP Basic Auth header to the request (remember — still talking v1 here). It also handles all HTTP and data errors first by displaying an error dialog to the user that displays the error text and gives the endpoint name, for debugging. After the user acknowledges the error dialog, the function then calls the supplied failure function you’d normally call (Display an empty list, disable an element, etc.). Successful calls quietly move on to the onSuccess function.

By wrapping it, I didn’t have to remember to add the Auth header, and it kept the response from getting garbage collected.

This was a BIG help later on down the road when foursquare added HTTPS to their API. All the URLs had to change from http://api.foursquare.com/v1 to https://api.foursquare.com/v1. Because my wrapper functions built the URL for me on each call, I only had to change the root URL twice: once in the foursquareGet function and once in the foursquarePut function. It saved me a lot of time from having to search and replace thousands of lines of code in a bunch of different files.

I also added an optional debug parameter to my wrapper functions. If set to true, the function outputs the raw response string to the console.
It took foursquare’s team to port their apps from v1 of their API to v2. So, how did I accomplish it as just one man with a fulltime job and still be able to spend time with my fiancée and friends and family? Well, one, I’m obsessive about it, and two, I just had to change those same two wrapper functions to point to the new API base URL (https://api.foursquare.com/v2), and instead of setting the Authorization header with Basic Auth, I just appended the oauth_token to each request. After creating a dead-simple OAuth dance with an embedded browser widget, I had a working API v2 app in a couple of days. (Not counting adding in new features like photos and comments)

I also never expect data types. If foursquare says it’s being returned as an integer, I check for both integer AND string forms. (i.e., I check for value==1 || value==”1”). Yes, it’s more work, but it ensures you that you can always handle the proper response. I learned this the hard way. Way back in the early v1 days, foursquare changed the “saveToTwitter” setting for a user from string literal “1” to an integer. When that changed, no one could log in to the webOS app because it was checking for a string. I had to push out an update to the app ASAP and luckily Palm reviewed, accepted, and published the fix in less than two hours. Since then, I check for both types (even booleans: value==true || value==”true”). There’s probably a better way to do this, and if there is, do that. Just don’t expect data to always be the same type forever.

So, the short and skinny of this is that when developing against a web service API, think forward. Expect the URL to change. Expect the parameters to change. Expect the servers to be down. Expect servers to be overloaded. Expect only certain endpoints will fail while others still work. Always expect the worst and most time-consuming scenario.

You want to make it easier on yourself should things change. Changing a URL in two places is better than changing it in 100 places. Expecting a server to be possibly be down is better than your users giving you bad reviews in your respective app store/marketplace/catalog/world. Expecting bad data is better than displaying bad data.

By expecting all that, you are making things easier on Future You. If you’re a programmer, no one hates you more than Future You. 

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.

Apple released their new Development Guidelines for iOS apps. There’s some good stuff in there (like the line “We don’t need any more fart apps.”), but a lot of it is ridiculous and stuff Palm openly allows. So, without further ado, here’s Apple’s stuff followed by palm’s take on the same topics.

Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected.
Palm doesn’t allow use of undocumented APIs, but nothing about easter eggs in apps.

Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them.
Palm has an open ecosystem and every type of app goes through. Hell, there’s an entire category in the Catalog devoted just to Twitter apps. If that’s not asking for variety, I don’t know what is.

Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.
Nothing official here, but since the PDK allows developers to do anything, Palm won’t stop you from building a web browser.

Apps with metadata that mentions the name of any other mobile platform will be rejected.
Numerous apps mention iPhone or Android in their descriptions, and I’ve seen a few games say “Hit iPhone Game!” right in the title! Palm doesn’t mind it at all. 

Apps which appear confusingly similar to an existing Apple product or advertising theme will be rejected.
I’m sure if a developer copied the exact interface of a Palm app there might be some issue, but duplicating a Palm app is a-ok.

Apps that misspell Apple product names in their app name (i.e., GPS for Iphone, iTunz) will be rejected.
Officially, Palm says not to use “Palm” or “webOS” in your app’s name, but there are plenty in the catalog, for instance “My webOS Apps”. Also, The Yammer client, Yalm, is one letter away.

Apps that look similar to apps bundled on the iPhone, including the App Store, iTunes Store, and iBookstore, will be rejected.
“Look similar” is subjective and I’m sure if you copied an interface exactly like a bundled app, Palm might reject it, but looking similar doesn’t seem to be a big concern to Palm as long as the app is clearly noted as being developed by a third party.

Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected.
Several of these already exist in the catalog. And with webOS 2.0’s Exhibition Mode, I’m sure we’ll see even more.

If your user interface is complex or less than very good it may be rejected.
I’ve heard anecdotally that Palm looks out for this sort of thing, but for the most part, as long as the app works and doesn’t crash, it’ll pass.

In general, the more expensive your app, the more thoroughly we will review it.
Can’t say I know if this is true or not, but considering there’s a $50 app in the catalog called “This App Does Nothing” I doubt it’s true.

Professional political satirists and humorists are exempt from the ban on offensive or mean-spirited commentary.
Palm allows all political satirists, professional or amateur submit content, based on the numerous “NObama” type apps.

Apps that include games of Russian roulette will be rejected.
I don’t know what this means, but I can’t see Palm rejecting this as long as it’s done well.

Apps containing pornographic material, defined by Webster’s Dictionary as “explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings”, will be rejected.
Palm blocks nudity, but there are lots of lingerie and Playboy apps in the Catalog already.

Apps that contain user generated content that is frequently pornographic (ex “Chat Roulette” apps) will be rejected.
As long as the app states this is a possibility, it’ll fly. Though, I’m sure with enough complaints Palm would pull such an app.

Apps that enable illegal file sharing will be rejected.
There’s a uTorrent remote control app in the Catalog, though I’m not sure that’d be in this category. And since the SDK nor PDK can access the music library on the phone, you can’t send that data, so I’m not sure what Palm’s stance on this would be.

Apps that download code in any way or form will be rejected
Tons of apps use external JavaScript libraries. Both my foursquare (Google Maps) and neato! (PubNub) apps do and they’re both sitting nicely in the Catalog.

Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected
Palm has an entire Beta channel in the Catalog! And there are plenty of trial and demo versions of paid apps in the main Catalog.

Apps that are not very useful or do not provide any lasting entertainment value may be rejected
“This App Does Nothing” falls into this.

Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc
Not only do webOS apps actually run in the background, but they can use EVERY service the SDK offers them while in the background.

Developers “spamming” the App Store with many versions of similar apps will be removed from the iOS Developer Program 
Brighthouse.

Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request 
Palm’s official stance is that you should not use this content in your apps unless you have the right to do so. However, it is the developer’s responsibility to know this and not Palm’s. Palm will allow apps using copyrighted materials and forward all DMCA and Copyright violations to the developer.

Audio streaming content over a cellular network may not use more than 5MB over 5 minutes 
No caps.

Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines may be rejected 
Palm recommends you use native widgets, but skinning native widgets or creating your own are perfectly allowable.

So there you have it. If you’re an iPhone developer and are looking to have a little more breathing room, come over to webOS! With the PDK, you can take your iOS app and port it over in just a few hours! Palm focuses on their developers and they love them and support them. Can you @ message someone in Apple’s Developer Relations team that reviewed your app? You can at Palm. Nothing beats Palm’s love of their developers and it shows.

Come over to the orange side!

I tried to submit an update to neato! tonight, but couldn’t. The Palm developer portal told me it contained features which weren’t available yet. The reason is that I have the 2.0b SDK installed, and while neato! has absolutely no 2.0 features in it, the packager brands it as a 2.0 app, so the Portal rejects it.

So, to package your app as 1.4.5 to get it submitted without having to uninstall 2.0 and reinstall 1.4.5, here’s what I did: (NOTE: This is on Mac OSX, so the steps will be different on other OS’s but you might be able to accomplish something similar)

1. Download the 1.4.5 SDK from Palm here
2. Open the disk image (.dmg) and copy the .pkg file to your computer.
3. Download Pacifist
4. Run Pacifist and click Open Package
5. Select the 1.4.5 SDK .pkg file from earlier and navigate to:
   - Contents of Palm_webOS_SDK-Mac-1.4.5.465.pkg
   - - Contents of opt.pkg
   - - - PalmSDK
   - - - - 0.1
6. Select the bin and share folders and click the “Extract to…” button the toolbar.
7. Extract them to somewhere on your computer that you’ll remember.
8. Now, instead of just typing palm-package to package your app, you will have to type the full path of the 1.4.5 palm-package binary

For instance, I navigate, in the Terminal, to my neato! folder and enter:

/opt/PalmSDK/0.1/bin/1.4.5/bin/palm-package ./

Since I created a 1.4.5 subfolder in the 2.0 SDK’s bin folder.

The newly packaged .ipk installed on my 1.4.5 Sprint Pre just fine and I was able to submit the update to Palm without an issues.

Let me know if you have any questions!

Edit: On Windows, you can’t extract the files from the installer. To do this on Windows:

1. Uninstall the 2.0 SDK
2. Download and Install the 1.4.5 SDK
3. Copy the bin and share folders to a new location on your computer
4. Uninstall the 1.4.5 SDk
5. Reinstall the 2.0 SDK

Not as easy, but it’ll work.