Bagel Belly Blog

On Ranting

I nearly pulled my developer engagement rant from the publish queue yesterday, since Aral did a much more eloquent job of describing the problems of working with developers. But I'd been working on it for quite some time, basically jotting down frustrations and annoyances after each developer event I went to. A colleague convinced me there were enough points of differentiation to make it worth publishing as well. So it's finally hit the wires.

Still - I highly recommend you go read Aral's post:

Let me use the tools and technologies I already know instead of forcing me to learn a whole new set. Give me some open web technologies to play with and I might just stay the night.

Excellent.

Incidentally, it's not all bad - one event I went to had two highly passionate and entertaining speakers (to quote someone: "their talk was fucking ace"). Another event saw me whipping up a widget using standards-based technologies (XML, JSON, HTML, CSS) and easily deploying over bluetooth. But there's still an uphill struggle most of the time, even though it's not rocket science to get this right.

Top 10 Crimes of Developer Engagement

(This post originally appeared over on the LiMo blog)

1. Call a spade a spade

Before I even get involved, I want to know: what's in it for me, and why should I care. It's amazing how many organisations talk about addressable market or target technologies or available devices. Blah blah blah. I want to know: what's the future of your platform, how quickly can I be productive, and how can I get my apps in the hands of users. Seriously. Cut the fluff, cut the marketing, you're talking to a technical person here. We detect bullshit for a living. So: tell us what we get and when we get it. Clearly. Concisely. It's not difficult! In return, we might buy into your platform, and then you'll have an army of evangelists more useful than a thousand glossy corporate brochures.

2. Captain Awesome

There's a commonly-held myth that everyone develops for the iPhone because of the fantastic tools, or the fantastic documentation, or the promise of becoming an App Store Millionaire, or because the Reality Distortion Field made them do it. Well, they may all play a part, but the number one reason is this: a compelling device that people want to use. Compared to all that came before it, the iPhone was all about usability - even in the early editions of the operating system. If you don't have a compelling, awesome device, please stop asking me to develop for it.

3. Hide and Seek

So you have a compelling device. You want me to invest in your platform. You push me to your website. But then you're not prepared to let me see the details of that platform - technical documentation, wiki pages, forum searches - without forcing me to register. Why should I have to give you all my personal details when I'm not even sure your platform is viable or of interest until I've had a chance to review those materials? How are us developers supposed to share hints, tips, and pointers to useful information if it's all behind a registration wall? What's so top secret about those device APIs that you can't make them public?

4. Please Hold

The rest of the internet has accessibility-crushing CAPTCHAs and automated email verification ("click the link to confirm your account"). But your site is special, and so you give each and every sign-up request that personal bit of attention. You really want developers for your platform, which is why you make me wait 72 hours before I can login and download the material I seek. But honestly, a cooling-off period is good. You don't want me to hastily rush in and adopt your platform and start being productive. I need to take some time to reflect on my decision - time I can spend evaluating your competition. Just don't expect me to be back after those 72 hours, mmmk?

5. No really, who are you?

Please enter your login and password. My login might be my email address. It might be a username you asked me to create. It might be a randomly generated username from your firstname.lastname.integer mashomatic. I will never know, and you will provide no hint. Oh - and as a special bonus, I need a separate username and password for the forums, the download site, and the wiki. Because single sign-on is, like, so last century.

In fairness problems 3-5 are common to all sorts of websites, not just for developers. But you'd think if they got 1-5 nailed, it would be all plain sailing here on in. Dream on! As if that wasn't bad enough …

6. README.txt

I can almost guarantee your developer kit is not available for my chosen developer environment. (Hey, Linus, we'd love you to build cool stuff with our Windows SDK! Steve, old pal, try this Eclipse plugin! Balmer, dude, you'll really dig this XCode tutorial!) And if it is … what are the odds of a simple installation? If I want to develop for three different platforms, all of whom use Eclipse for their SDK? Why yes, I would like to install three personalised copies of Eclipse, thank you very much. That sounds tremendously efficient and much smarter than using a plugin ecosystem.

7. The dotted line

Please read the following license agreement carefully:

Use of this SDK is subject to the terms and conditions of our SDK license agreement. This agreement is between you ("YOU") and big faceless corporation ("THE MAN"), a company incorporated under laws in a country far far away. By accepting these terms you give us all rights to your code, to your firstborn child, to 10% of your annual income in perpetuity and furthermore you acknowledge full responsibility and warranty and fitness for purpose of your application. You will be liable for the sum of one billion dollars ($1000000000) and forfeit any right to talk about THE MAN without express consent for ever and ever, amen. Please indicate your acceptance of this agreement by depositing a litre of blood here: [ x ]

You want me to develop for your platform, and you start the relationship with 35 pages of legalese? Seriously?

8. Goodbye Cruel World

The quickest problem to describe, the hardest to solve. How long does it take from access to the website to being productive and seeing "Hello World" in an emulator? How much documentation do I need to read? Is everything self-evident, following common methodologies and best practices? Does it all fall into a typical developer workflow?

9. Deploy.

Assuming I got my "Hello World" working, how easy can I get it on my real live actual phone? My neighbour's phone? Share it with everyone in my office and gather useful feedback from them? Beware: if your answer is "send them to the app store", my neighbours and colleagues will all demand you give them bundles of cash to spend there.

10. Unconference

So, you told me why I should write for your platform. You have a compelling device. You made all your content readily available and accessible. You had a speedy sign-up, and let me pick sensible login details. Your tools were lightweight and fitted with my normal workflow. Your licensing terms were reasonable. I could become productive quickly, and get my app on several phones without too much pain. Now I want to take the next step, and meet the others who are developing for your platform, to become an active member of the ecosystem. I want meetings, get-togethers, hackathons, and conferences. You've kindly arranged all of these, but … do I get to talk technical, or will I be in a room full of suits? Will it all be glitz, glamour, vapourware roadmap and marketing, or will you concentrate on nuts and bolts and real world problems? Is there all the power and wireless I could ever need? Do you have ALL your developer materials handy (like on a USB stick) to save me waiting a day for the download? Can I run off with one of your devices, or some developer-specific test hardware? Will you have passionate spokespeople who are engaged in what they talk about, or marketing drones wheeling out the corporate message? Will it be Death by PowerPoint, or Death by Pizza?

The Palm Pre

(Fri 13 Aug 2010: This was supposed to be posted back in 2009, but for some reason sat in ecto's drafts queue ... posting it now for completeness, posterity and so I can link to it in the future.)

I went to the O2 Litmus / Palm Pre developer event on Tuesday night, and was delighted when they gave a Palm Pre to each attendee at the end of the talks. I'd been trying to get my hands on one, but sadly o2 refused to allow me to upgrade from my iPhone until end of December, and the Pre is only available on a pay monthly contract.

I've been using the Pre on and off over the last couple of days, trying to get to know it and understand where the Palm WebOS platform is going. Herein my first impressions from the Pre.

Firstly: it's a beautiful device. The iPhone could be considered cool, but the rounded edges and organic smooth stone style of the Pre is really nice. There are some rough spots - the slider to mute the device feels cheap and fragile, and the back panel is seriously flimsy when you take it off to get at the battery. But on the whole, it feels really nice. The little fabric case that Palm ships with it works really well, and clears up the smudges on the screen nicely while in the case. The case also seems to emphasise how small the phone is.

Speaking of size - it's deceptively heavy for what appears to be a small device. Coming straight from the iPhone, the display feels small, but after a while I got used to the stunning brightness and colours, and the iPhone when I went back to it felt big, with a lot of wasted space on screen. What really helps is the Pre's ability to have a background desktop picture - not particularly revolutionary, but one up on the iPhone. It feels nice, and personalised.

What about WebOS itself? Well, it took a while to figure out, there's a few paradigms that need learning (cards are like tabs, swiping backwards to shift between tabs or go back in an application, pressing the silver ball is Alt-Tab, flick up to exit). Palm have been even more Apple than Apple in enforcing how the device works - the modifiable preferences are sparse almost to the point of non-existence. This is both blessing and curse - it makes the phone super simple to use, but limits customisation.

Update: I just found out the Palm Pre on o2 is running WebOS version 1.1.3; the state of the art is 1.2.something, so maybe the problems I'm experiencing are solved in the latest version. Come on Palm, o2: get us up to date!