Of user-local programming

A Detroit-area “Mobile Monday” group cross-posted an event to the Ann Arbor CocoaHeads group (which I attend regularly), and it’s interesting enough to make it worth my time to drive across the state twice this week. Which, in addition to traveling to Philadelpia for Voices That Matter: iPhone Developer Conference on Friday, is probably too damn much travel for one week.

[Aside: we really need a West Michigan CocoaHeads group…]

The event is going to feature a presentation from Ford on SYNC and the API they’re exposing to developers of third-party applications. At 360iDev, fellow AA CocoaHead Tom Hoag was on me to check out SYNC, and since we’ll probably have it on our next car, I would naturally be attracted to it anyways. Looking at the developer welcome page, they talk about planning to distribute apps through existing app stores, so whereas I originally thought a SYNC SDK might involve writing apps to run on the car’s CPU, maybe what it actually means is more of a protocol to be called via the iOS External Accessory framework. That would actually suit my needs much better: I’ve long wanted to voice-enable Road Tip, and being able to just connect to SYNC and let it do the voice recognition and speech synthesis is conceptually straightforward and would be very compelling. In fact, it would be more practical for the user to use SYNC’s driver-optimized microphone and the sound system’s speakers than to use in-built iOS speech frameworks (which aren’t yet available to third-party apps anyways).

But that’s actually beside the point I wanted to make, which is this: to sign up for the event, I had to join the Mobile Monday meetup group, the process for which posited this question: “Why are you interested in mobile.”

I answered: “I’m not.”

Specifically, I’m not interested in mobile, per se. Over the summer, I was talking with a high school friend of mine, Raman, who’s had a long and successful career at Microsoft. One of the things we found we both liked is the idea of having our code running where the user is. This isn’t mobility, exactly, because we both like desktop programming too. What we like is having our code executing on a device that’s where the user is, in direct interaction with the user, rather than on a server somewhere.

For the sake of coining a term, I’m calling this “user-local computing”.

I think this is an important turf to stake out becasue there’s been an almost smothering focus on the web and server-side programming for the last decade, that a lot of us feel like we’ve been left behind or overlooked. Sure, I can do server-side stuff — I’ve written servlets and SNMP traps and web services — but what I enjoy is the kind of application that’s interacting directly with a user, not looking up some database record that something else is going to present, or sending some HTML that’ll get rendered a second or two later and just sit there. Other people like that. Most people like that. In some camps, the server side is the default point of view, to the point of myopia (looking at you, Java community).

But not everything can be a webservice. Not everything should be.

There is a tangible difference to code that is executing in the user’s immediate presence, stuff that responds immediately to input, that manages resources locally. The web is getting closer — Google Instant Search is a remarkable user experience — but it still isn’t, and probably can never be, as responsive as work being done on the user’s own CPU.

There are also creative tasks that seem ill-suited to remote performance. It may well be possible to make a browser-based IDE, with source files stored on and executables built on a remote machine… but would it really be a good idea? Now let’s up the bandwidth: could you build a video editor in a browser, sending all your source media back and forth across a network connection? I’m sure someday it’ll be possible, probably soon, but I think it’ll be a long time before it’s actually a good idea.

In a way, this is a sort of retro outlook for those of us in our 40’s: the old paradigm of computing was based around creative tasks executed locally: Visicalc, WordPerfect, MacPaint, PageMaker. With the dictate that everything has to be network based, we’ve gotten more in a mindset of applications that collect and consume data from various network sources. And that’s great. But the idea of empowering your user to actually do stuff still matters, and while it may seem old-fashioned, a lot of what really matters involves clearing out the noise and distraction of the network and concentrating on doing something yourself. Notice how the new trend in text editors is to dispense with formatting, menus, toolbars, and all other distractions: it’s just you and your text. This is an ideal application of user-local computing: cut the crap, just let me focus on the here and now. “Here” being wherever I am, and whatever CPU happens to be handy.

So I’m interested in desktops, tablets, and iPhones not because of some high-falutin’ idealization of the power of mobile computing… I like them because they put my code where the user is, whether that’s at a desk, a couch, walking around, or driving in a car.

Comments (2)

  1. […] seem to have penetrated desktop or device programming to any significant degree. If the code is user-local, then it’s almost certainly running in some curly-brace language that’s not far from C. […]

  2. […] the Ford SYNC/AppLink SDK at After a long ramp-up period — I originally mentioned going to a developer event promoting the Ford SDK back in October, 2010 — Ford now has actual […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.