funkatron.com

Unlike some others, I only participated halfway in CodeWorks 09, doing the east coast leg of Atlanta, Miami, Washington, D.C., and New York City. It was an enjoyable adventure, and I liked being able to try different approaches in my talks and see what worked best.

I was able to record audio with the voice memo app on my iPhone. Getting hour-long recordings off is a bit of an adventure – they refuse to appear in the voice memo playlist in iTunes, so you have to find the files in the MobileSync backups folders and do some renaming work – but they turned out pretty well.

Introduction to CodeIgniter

• Slides
• Code
• Audio (recorded in NYC)

Building Desktop RIAs with JavaScript and PHP

• Slides
• Client Code, Server Code
• Audio (recorded in DC)

No more travels for me until SXSW in March, I believe. I’m far too tired.

Yesterday I put together a short survey that asked some questions about what people would be willing to pay for Spaz webOS. It’s been my plan all long to change a small fee (when possible — you can’t yet in the Palm App Catalog) for Spaz webOS, and use the revenue to support further development. Since I believe strongly that Spaz must be an open, transparent project, here are the results so far from 145 responses:

• PDF of Spaz webOS Pricing Survey Response Summary data

…and here are some comments on the results:

What is the most you would pay to purchase Spaz in the Palm App Catalog?

From doing a little math on this, it seems like $2 is the optimal price point in terms of revenue generation, followed closely by $3.

• PDF of “revenue potential” data

What 1-3 features would make you more likely to purchase Spaz in the app catalog?

First off, lots of people ignored the request to pick 1-3, which isn’t surprising (you couldn’t set a max number of choices). That being said, 4 items were far and away the most popular choices

1. Faster Performance (56%)
   Spaz does seem to perform slower than comparable apps. Part of this is because we use a combined timeline, and therefore it takes longer to build results. We also initially requested a LOT more messages from Twitter at startup than comparable apps, and processing them takes more time. We’ve lowered the default numbers (you can up them in prefs), but it’s still higher.

   We’ve also had some CPU usage issues. Those have been dramatically lowered since initial release, but there’s probably more we can do. This shows up especially while processing new messages.

   The other issue I think this response refers to is sluggish scrolling speed. This one perplexes me a bit, but I’m guessing we may be running into performance limits of the Pre’s webkit renderer. We’re going to do some experiments with stripping out CSS styling and markup on our timelines to see if the scroll speed improves in either case. If so, we will need to modify how we style and/or build the markup for our timeline.

2. Direct uploading to image hosting services like Twitpic (54%)
   This was really close to #1, which tells you how badly the lack of direct file upload APIs in webOS is hurting devs. What’s most frustrating is that the email-based workarounds actually took longer to implement than direct uploads would — we already have plenty of code from the desktop app we could have adapted. Here’s another plead to Palm to please expose the file upload APIs to 3rd-party developers ASAP!

3. New message notifications even if the app is closed (42%)
   I’ve heard this a lot. I kind of assumed people would just leave an app open if they wanted it still running, but how I use things isn’t necessarily how others will. One consequence of implementing this will be reduced battery life, so we will need to be careful about it. Note that Palm recommends not doing background network requests more than 15min per hour. We won’t exceed that if and when we do implement this.

4. Facebook support
   This one kinda surprised me. I only added it as a bit of an afterthought, but I suppose it makes sense, especially since there’s not a good native Facebook app for the Pre. I actually know very little about the Facebook API and am not super duper excited about building for their walled garden, but if someone wants to build a SpazCore lib for it, we’ll probably implement something.

Also of note were some of the “Other” responses. They included:

• “More optimized code (use less cpu!)”
  This falls under Faster perf, fo sho.

• “tweet with google maps link to current location”
  This is on the list to get implemented

• “hit user pic in timeline to @reply”
  We’re going to implement something that lets you do actions on a message without going to the detail view. Kinda sucks right now.

• “low power consumption”
  The way you do that is to make fewer network requests. This responder will not want background checking, then 8)

• “more identica/laconica support”
  I’d like to see this happen too. If you want it to happen, volunteering to code a Laconica-specific API (or somehow scraping up funding to sponsor development) would help us out a lot. We don’t have time to do much with non-Twitter APIs right now.

• “Livejournal support”
  Seems like a microblogging client isn’t a good match for this, but if we add ping.fm support, you should be able to post to LJ through that. As for reading LJ posts, I think RSS feed support would allow that.

• “It needs a non-offensive name before I would purchase it anywhere”
  We had to get one of these, although I’m surprised we only got one in nearly 150 responses. It’s not changing. Read the FAQ. Sorry!

• “Since last 2 updates it really drains my battery. LOVE it’s look and feel though.”
  These are the kinds of things we need to get reported to us. Can’t fix it if you don’t report it. Go to our support site and file an issue, please. Please make sure Spaz is the only culprit involved, though.

• “Direct blip.fm support (streaming via clicking a link)”
  That would be interesting. If someone’s willing to look into it dev-wise, I have no issue with it.

• “Why? When tweed is free. And there’s more twitter apps to come.”
  No applications are allowed to charge for apps at the moment. That will change in the future, though. I wouldn’t assume Tweed will remain free, but I have no idea what their plans are.

• “Copy and paste”
  Talk to Palm, dude. 8)

• “Change the name!!!”
  Okay, maybe we got another one, but this didn’t claim I was making fun of physically or mentally disabled people. Sorry, not changing.

• “None”
  This surprised me a little. You could have written “shits money and cleans my house.” Surely that would make you more likely to buy it, yes?

This is something I’ve been thinking about and working on for a few weeks now. I wanted to post it here both to understand my motivation, and to hear feedback.

1. Spaz was built for the sake of building it. It is not a means to an end. However, creating it has had several good consequences.

2. Spaz demonstrates that making things is good, and sharing how you make them is better.

3. Spaz is a necessary counter to closed, hidden technologies. Spaz must always be open.

4. The value of Spaz does not lie in the judgements of others, but in the process of building it, and the enjoyment derived by those who use it.

5. We welcome anyone who wishes to participate in the Spaz Project with open arms, as long as they understand and respect the purposes of the project.

6. The Spaz project values clear and open communication between participants.

In the past two years I’ve spent most of my free time working on desktop applications written in JavaScript, HTML and CSS. I write them on top of web runtime platforms like Titanium and Adobe AIR, and more recently Palm’s webOS. In this time, I’ve heard a misconception raised repeatedly: that “local” (desktop or mobile) applications written on top of web runtimes offer no advantage over remotely-hosted, browser based apps. Or, to paraphrase something I overheard recently:

HUH huh your app is written in JavaScript and HTML, why don’t you just load the web site DURRRR.

I suppose this kind of thinking comes from the JS+HTML+CSS being almost exclusively used for web site front-ends for so many years. It’s a knee-jerk reaction, much like the one that says “oh, you can’t use PHP in the ‘enterprise’” or “Oreos aren’t for breakfast.” Proved my mom wrong on that one.

So, I decided to make a list of what things you can do in a web runtime platform that you can’t do in a browser. Now some of these vary depending on the platform or the browser, and I’ll try to make note of them in my list:

1. Cross-browser compatibility issues are a thing of the past
   I should offer a caveat here — even though the rendering engines are the same, you’ll sometimes run into OS rendering differences. AIR, for example, supported CSS3 box shadows on OS X until v1.5, but never did on Windows. But the differences are far, far smaller than you’d see between, say, Safari 3 and IE6. Trust me — you will love not having to worry about getting your layout working in some ass-tastic box model implementation anymore

2. Advanced rendering features (CSS3, etc)
   Since you don’t have to worry about looking the same in different browsers, you can take advantage of the special features your runtime’s rendering engine supports. Titanium, for example, supports the same advanced CSS features that Safari 4 does, like box shadow, border radius, and CSS gradients.

3. File system access
   On desktop web runtime platforms like AIR and Titanium, you can interact with the filesystem just like any other application: read, write, and create files and folders with the permissions of the executing user. webOS offers less freedom in this respect, but you can read and write files on a limited basis.

4. Networking
   Both of the major desktop web runtime platforms provide much more advanced networking capabilities than are available within a browser. I’m not much of a networking programmer, but both platforms allow the developer to open TCP socket connections and communicate over them. Titanium seems especially well-prepared in this area, with its ability to leverage Python and its powerful networking capabilities.

5. No same-origin policy restrictions
   If you want to pull data from a web site other than your own in the browser, you have to resort to JSONP — basically an XSS attack waiting to happen — or set up a proxy on your site’s server. Web runtime app platforms don’t have this issue, so you can make XHR calls to any domain you wish, and interact with any APIs.

6. No need to support non-JS users
   This might seem like a small issue, but having to support users who have disabled JS was one of the major reasons I never did serious browser-based frontend programming before I started working on Spaz two years ago. Now the cool kids at SXSW will tell you that “nobody” disables JavaScript, but I think that’s kind of short-sighted.

   Nevertheless, this argument and the need for graceful degradation and “unobtrusive” JavaScript become moot in the web runtime app platform. JavaScript is there, it’s expected, and you can’t disable it. So go crazy.

7. Using/interacting with platform-specific UI elements
   This includes things like window chrome, menu systems, Dock items (OS X), menulings (OS X) and the System tray (Win/Linux). Both major web runtime platforms display your application within the native window chrome, allow you to create native menus, and give you some access to the system tray and OS X’s Dock. Titanium is a bit better in this regard in that it inherits the native look of form widgets and scrollbars, and provides access to the OS X menubar (those little icons in the top-right).

8. Sound playback without plugins
   Until HTML5 becomes standard in all browsers and bestows the grace of plugin-less media playback, we’re stuck <embed>ing <object>s in our gorgeously crafted markup. Funk dat. Web runtime platforms provide sound playback APIs that mean we don’t have to stick a Flash applet in our document and hope it doesn’t catch the CPU on fire. AIR has a particularly good playback API (probably because the whole thing is running in a Flash engine. Small victories).

9. Interacting with other applications/shell interaction
   Being able to leverage other applications on the machine/device can be really valuable, especially on Unix OSes (Mac OS X, Linux, etc) that have a bevy of useful utilities available from the shell. Titanium is the only desktop web runtime platform that allows the developer full access to these capabilities; AIR is limited to interacting with other Flash-based applications at this time (although this may change in the future). Runtimes on mobile devices are typically much more limited, although webOS’s Application Manager service does let applications launch and pass arguments to other apps.

10. Database support
    Typically this is implemented either via the HTML5-style database stuff (usually asynchronous) or a platform-specific SQLite (usually synchronous). Out of the box, support isn’t provided for external DB servers (MySQL, PostgreSQL, MS-SQL, etc), but with Titanium this should be possible by delegating to Python or Ruby scripts, or Titanium kernel modules. DB servers that provide HTTP interfaces (like CouchDB) will work fine, though.

All of this doesn’t mean web runtime platforms are going to replace browser-based apps anytime soon. There are clear advantages to remotely hosting an application (speed of updating comes to mind), and supporting an app on a user’s machine brings a new group of debugging headaches. But for applications already chafing at the limitations of the browser, web runtime platforms offer a compelling option.

Spaz 0.5.0 went out to the Palm Pre App Catalog today. The coolest new thing is image posting support for TweetPhoto, Twitpic, yfrog and Twitgoo. While webOS still doesn’t have a generic file uploading service that third parties can use, these services support email posting of images, so we were able to build a workable solution using that. It’s not optimal, and as soon as webOS supports file uploads we’ll be there with support for even more services, but it works for the time being.

The other major enhancement in 0.5.0 is with notifications. Previously Spaz on webOS had just used “banner” notifications when new items were loaded, which appear and disappear quickly on the screen. Lots of users asked for what are called “dashboard” notifications in Spaz, though, which are like the ones you get with the email app: an icon is displayed in the corner of the screen, and if you tap it, a larger dashboard appears with more information. These notifications are persistent – they won’t go away until you dismiss them by swiping or tap on them to bring up the Spaz card.

All of these enhancements are available to other webOS developers as well. Because Spaz is open-source with a liberal New BSD-style license, you can use code from Spaz or the SpazCore libraries in your own apps. So if you want to do email-based photo posting to Twitter like Spaz does, you can! And although you are not obligated to tell us, if you do use our code, we’d love to hear about it.

As always, if you have problems, questions or suggestions, talk to us at our Tender-driven support site.