First Impressions, Second Impressions

Ok, I'm not aiming specifically at the quality or related issues of the Moto Q or Treo 700w here. But this Amazon review of the Q is just brilliant: http://www.amazon.com/gp/cdp/member-reviews/A10U3Z35FCPXF2/

Synopsis (if you haven't read it yet or are too lazy to click through):

1. Smartphone-savvy customer is delighted to begin working with his brand new Motorola Q.
2. Customer discovers some minor issues and remains enthusiastic and forgiving.
3. Customer has multiple hardware failures. Service rep suggests an alternate device with a better quality track record (in the opinion/experience of the rep).
4. Customer buys this alternate device and regrets giving the 5-star review to the Q in the first place.

Footnote: This all takes place in a week, and remember this reviewer seems to be a sophisticated PDA/phone user.

Question: When (Apple) did firms pushing the "high-end" wannabe-Lexus products (Apple) start acting like used car salesmen (Apple) hyping something shiny (Apple) that barely drives off the lot (Apple) with the engine still running?

Someone set me straight here ... meanwhile, I guess this is why I drive a Honda and build my own whitebox PCs...

Relational Databases: What are They Good For?

I'll answer the question: they're typically good for a whole lot, provided a whole lot looks something like:

• Extreme concurrency support (if handled right)
• Solid transaction support, with well-known deterministic tradeoffs agains concurrency
• Deterministic (in both time and output), standardized (mostly) and accessible query capability
• Proven logging, failover, and recovery mechanisms
• Standardized management and operations tools
• Exposure of data to standard, existing reporting and OLAP tools
• Declarative management
• Declarative data cleanliness constraints
• And a few other things
  

Now, nowhere in that list does it say "great data structure for every problem domain" -- or even "great data structure for many problem domains." In fact, the relational model is inherently a good structure for a few domains, but by no means a large number.

And yet somewhere along the way, in the last 20 years or so, it's become a not-entirely-embarrassing-and-career-limiting-move to design a software system by initially modelling entities in a relational model, then slapping a wrapper above the SQL (maybe even auto-generated), tossing a UI on there, and declaring "Mission Accomplished." Wait! Where's the "business layer"? Well, that's where things start to go off track. Actually it's usually above the DB wrapper piece and below the UI -- but more importantly it's usually almost empty in the beginning, since the designer has an entity model that is tightly coupled to the current flavor of business rules. The business layer becomes a real monster ... er I mean tier ... later, when each case or change that isn't supported by the data schema earns a hack-around in the business layer. And at the end of the day all of these systems end up looking and acting the same way: like the 3-tier DB apps they are.

What's wrong with that? The fact that the apps end up expressing this architecture more strongly than they express solutions to their problem domain. These apps feel like fields and records -- they don't feel like what they actually are (e.g. a cell phone provisioning app, a flight management app, etc.) So they're mediocre and they're disliked by their users, disliked by their maintainers... they're "good enough" ... "until we have a chance to do it right."

For most apps, a database is a particular way to persist data, with some handy aspects, that's all. Don't design like it's anything else! Design like you're building a video game, like the experience is everything and only the user interaction needs to be right (and 100% right). The reality of business apps may be dirtier in the details (not to mention you'll rarely have the resources to make your UX dreams come true), but that's the point: if you're smart you can keep it in the details. Which means designing a whole application not just a database.

Remember "Disintermediation"

That was a hot word for the way some online businesses were reshaping value chains in the late 90s by eliminating various links. One might think that arbitrage and free markets being what they are, all of the legitimate disintermediation opportunities were exploited years ago.

But here's a new one -- well, it's not new anymore, but it's a lot more recent. Anyone who has ever bought a pair of eyeglasses retail can't help but wonder what kind of scam is being perpetrated. In an era of $19 MP3 players and $300 PCs, we have $250 for an eyeglass frame that just screams "Made in China, $20 per dozen" Not to mention that in many developing nations, people do buy eyeglasses, and the $250 pricepoint would be unimaginable. Then you pay $40+ for lenses (which are pre "ground" and come out of an envelope), and extra for all sorts of protective magical coatings.

About a year ago I googled for discount eyeglasses, thinking that surely out there on the web someone is importing these $1 frames in bulk and would sell them to me for a modest 1000% markup of $10. No luck. Lots of bogus sites, and the legitimate ones were just selling the same "designer" frames at the same price ($1 manufacturing + $5 licensing + $244 American sucker tax = $250)

Fast forward to today: Google for eyeglasses, and you find a dozen sites selling complete glasses (i.e. frames + prescription lenses) online for anywhere from $15 to $50. I tried a pair from a San Rafael company called Zenni Optical (a.k.a. 19dollareyeglasses.com) because at that price, really what was there to lose? I had the glasses in a week, they look great, the optics are fabulous, done. Price including shipping: $28. These guys rock out!

The only mystery left is: how can a business make any money selling a pair of glasses at, say, $25. Unlike the commodity MP3 players, these glasses do need a little bit of handling and custom work (cutting the lenses, inserting into frames, packing, etc.) The fast shipping and one-off ordering suggests that the custom work is being done in the U.S., not overseas. Let's say it takes 20 minutes to process a pair, and there is $20 of margin in the $25 glasses. That's $60/hour. Which isn't bad if you've got a couple of employees, low rent, and your production pipeline is full. But if the pipeline has some slack, or you have a manager in there somewhere or any kind of real estate ... that's brutal! Even Wal-Mart's absolute cheapest non-branded glasses were about $65 (frames + lenses) last time I checked...

ByRef moreDetails As String

Quiet down, you'll get the joke when you follow the links.

My last post talks about what's not there as far as developing for the Palm. Jamie Flournoy, who has done a ton of rocking contract work for Skip on our mobile clients, has written a post discussing the solution the we did choose for building a new Palm/Treo client.

Even better, he's going to be contributing to the community a test framework he built, and some hard numbers that can be used to look at relative productivity for different tools. Thanks, Jamie!

Waiting for Godot ... er, Cobalt

At Skip, we're creating a native (well, 68K, so native vis-a-vis Java) client for the Palm. In particular, we're targeting the many Palm Treo smartphone users, who deserve a more robust Skip experience than Java has been able to deliver.

In the process of building this client, we've been stunned by the huge gaping hole that is the Palm high-level app development platform.

Since ours is a high-level business/productivity type app, since the client is not complex, and since we support many platforms, some sort of RAD tool or at least high-level API is ideal for client development.

The amazing thing is that the space is a gaping void, where only a handful of tiny ISVs with proprietary tools play.

IBM hasn't updated its Java implementation for Palm in several years ... it's not great, not free, and has no roadmap into the future. At the other end of the spectrum, PalmOS has a broad C API, but this is no high-productivity environment (it's more like C for Win 3.1). Not to mention that using many third-party C libraries requires assembly hacking and linker foo, not ./configure and make.

Adobe could push the Build button and release a Flash player for the Treo that would instantly become the high-level environment of choice for 21st-century connected apps. And the great UI possibilities would be a bonus!

The lack of a top-notch development system is even more mysterious given the large community of Treo users and thriving (by PDA/phone standards) ISV app ecosystem. In other words, the Palm Treo area is one of the most successful and least risky places to invest in infrastructure, with the highest potential return.

Presumably this whole situation stems from the prolonged wait for imaginary Cobalt devices. That's going to make things all better. Real soon now.

Disappointed but not Surprised

Over the weekend I noticed that my DirecTV TiVo DVR wouldn't let me pause or "replay" XM radio stations. Clicking pause or flashback brought the "error beep" and an on-screen message that this functionality was unavailable for audio-only programming.

I am not sure if that is a new change subsequent to their switch to XM for music, or if it has always been part of the TiVo software on their boxes, but I couldn't help laughing at how ridiculous it was. Most likely they are preventing "digital recording" of the audio channels as some sort of protection against imagined piracy.

The reasons I laughed are these -- top reasons why a DirecTV TiVo DVR is not a piracy threat:

1. Although the box has a S/PDIF digital audio output, the audio is compressed in transmission to the satellite receiver, so it's not as if some magical studio-pristine copy of the audio is there on the box.
2. DirecTV TiVo units (unlike Series 2 TiVos) do not allow an ethernet adapter to be added on, or saved files to be removed from the unit. So pirating anything off of the box would have to be done by playing the file back in real time!
   
3. Every DirecTV satellite receiver (at least every legal one) has a smartcard with a unique ID and account information. Since activity on the DirecTV box doesn't even pretend to be anonymous or unobserved, it's not the most appealing channel for doing anything illegal or inappropriate.
4. Since DirecTV owns the box, they could always restrict the unit if it were being used excessively for audio recording and replay in a way that looked suspicious (although, as already explained, it's hardly a practical or appealing way to do anything like that)
5. In the last case, they could always watermark the media on the unit and allow customers to do whatever they want, figuring that (a) most customers wouldn't do anything remotely inappropriate if they know the media is traceable to their account (and bill!) and (b) anyone sophisticated enough to remove watermarking would be getting their media somewhere else in the first place.
6. Unlike the TV and movie channels, the audio channels do not publish a time-based "guide" listing each program or song that will be played. So it would not be possible to plan a recording of a particular song. Basically, the would-be pirate is like a 1980s teenager making a mix tape off an FM stereo. This guy (or gal) would have to either sit there waiting for the song to come on, and Quick! Press record! or else they'd have to record hours of content and then play it back in real time and chop it up on a computer.

I love this whole scenario because it shows just how silly the whole thing is. My DVR has specific features and UI in it that basically amount to guaranteeing that when my 21-month-old hears banjo music he likes, I can't press pause or rewind. Welcome to the 21st century.

A Change in Context Does not Require Rebuilding the World

I love YubNub.

Besides just being very cool in a geeky way, it's got a lot in common with Skip. The interface that YubNub exposes to the user (a "command line for the Internet") and the Skip interface (a "click interface for getting things done with a phone") are diametrically opposed. YubNub is about typing out commands, while the Skip interface avoids typing at all costs. So it's not that part.

What Skip and YubNub have in common is the idea of adapting some of the great applications out there for a new context -- without rebuilding massive parts of those applications from the ground up.

YubNub rocks when your context involves keeping both hands on the keyboard. Maybe you're working in various console windows, or you're a writer or a reporter. I'd love to have this under a hotkey in Microsoft Word (maybe someone's already written the plugin). I type in a command like "gim porsche 911" and *bam* pictures of Porsche 911s. YubNub is extensible and has the notion of pipes and filters. So maybe I want to insert a picture of a 911 into my Word doc -- I could execute the search in such a way as to return just the first image, copy, paste, done. In the keyboard/console context, this is a powerful way to access anything that lives on the other end of a URL.

Skip does something similar, for the no-keyboard, no-typing context you're in while sitting at a stoplight or running from airport parking to catch a plane. We don't want to rebuild all of the airline checkin applications, limo reservation systems, or fast food point-of-sale systems in the world just to make them "mobile."

We'd rather build a context-specialized application that knows just enough about what you're trying to do to make it a whole lot easier, and lets companies get the transaction systems they've already built and operationalized literally into their customers' hands.

It's Not a Tumor ... er Toaster

HCI specialists have metaphors they like to use to describe how products can be made more usable. One of these metaphors is the toaster. They may explain how a complex copy machine, or a PC printer, should behave more like a toaster. You should be able to walk up to one you've never seen before, be able to tell what goes in what hole, press a lever, and reasonable default behavior should pop out a minute later.

Now this is fabulous Crossing the Chasm advice. But the early adopters don't buy toasters -- they buy electrical thermal-transfer bread processing systems. They are interested in the options in the print dialog box -- or to use a literal example, my friend's ancient toaster (an early adopter toaster, as it were) had a tuning screw on the bottom which could be adjusted to calibrate the toaster such that the color of the toasted bread exactly matched the color on the enamel toast darkness selector.

So what's my point?

I recently got to try a Roomba home vacuuming robot. The robot, an interesting piece of technology from a company that clearly makes some hard-core gear, came with about a 4-page instruction booklet. The instructions try to follow a toaster model: simple, clean, "nothing complicated here" -- push "Clean" and go. But it's not a toaster, it's a domestic robot! Like in the Jetsons! This isn't like buying a lamp (and it's not cheap either), so I want to know exactly what the heck it does. It's probably best if I don't have to read a 50-page manual to use it, but I would certainly appreciate one that answers some basic questions.

I'm the guy who's going to be recommending (or not) this device to the people on the other side of the chasm. So when it fails to manage its battery charge and fails to return to its charging station like it's advertised to, I'm the guy who will be very sympathetic if only I can get some understanding of what it's trying to do and why it fails.

A device with great docs is a Samsung VCR-style DVD recorder which I bought a year or two ago, when those devices were a little more raw. It's a solid piece of equipment, and easy to use without reading the manual. But it came with 50+ pages of docs so that I could understand exactly what it could and would do, and where some less familiar recording formats (like DVD-VR) came into play. Because I understood what it could and couldn't do, I felt comfortable recommending it to less technically inclined people. Those people in turn don't want the 50 pages -- they want the toaster, and good for them!

As for iRobot, they score massive points for putting a serial port on the outside of the device and encouraging people to reprogram it if they want! I love seeing a company that isn't afraid to say, "Hey! You bought it, it's yours, go ahead and hack! We're mature enough not to worry about managing perceptions or fighting imaginary lawsuits if you make it do something stupid." That alone is enough to make me forgive if it mysteriously misses a swath of carpet.

Phones and Web Apps: A (Very) Brief Encounter

A few years back, a number of web development frameworks (e.g. ASP.net) began aiming to target mobile browsers as well as desktop browsers. In order to make this process less labor intensive for web developers they do this by allowing developers to use a generic tag instead of a specific HTML tag (e.g. asp:Textbox instead of input) and then, at run time, looking at HTTP request headers such as User-Agent to determine what sort of markup to actually render to the client. New mappings of headers to markup can be added or tweaked in a core library.

This whole approach was possible because of a brief convergence in the capabilities of desktop web apps and mobile phone web browsers. The former were limping along, the latter had just made a giant stride up from the murk of WAP browsing.

But the convergence turned out to be brief: desktop web apps have shot up in their sophistication and usability, with heavy use of AJAX and local Javascript-DOM programming. Any hope of "auto rendering" these sorts of apps onto a phone browser is a non-issue since the mobile browsers don't have sufficient screen size or Javascript support.

So that whole approach turns out to be a historical artifact. What's next? Maybe Flash Lite, if it would only show up on actual phones in the U.S. I also like the WPF/E concept, although sitting here outside of Redmond, it still looks like a concept both in the implementation and as far as getting it on (non-Windows) phones. In these cases, while there are not quite "magic templates" generating custom markup for each device, it should be possible to produce a single published app which works consistently on all of the participating handsets due to standardized support on the client side.

For Adobe or Microsoft, if it's possible to work the right deal with OEMs and carriers, it should be like shooting fish in a barrel. After all, J2ME is the only real competitor. And J2ME is still more complex than it needs to be, and continues to show no material, credible sign of progress (MIDP 3 included) toward the "write once run anywhere" motto that used to fly on the Java flag.

It's Easier Getting Them Out (OO Part 2)

When my wife and I were preparing for the birth of our son, we attended some prenatal classes. One of the instructor's favorite (overused) jokes was that, as far as babies, "it's easier putting them in than getting them out."

When it comes to objects and relational data stores, the opposite is true. Most developers can -- and have already needed to -- learn plenty of query description mechanisms (SQL, OPath and variants, JDOQL, LINQ, and a hundred product specific ones). Learning how to get data out of a store, and putting it into an object, XML schema, structure, whatever is just not that big a deal.

The hard part is putting 'em in. Actually, there are two hard parts.

The lesser hard part is taking data and moving it into a well-defined persistent store. This needs to be done while avoiding egregious transaction, concurrency, and performance problems on the DB side and also not requiring a lot of tuning and locking hints from the developer.

The greater hard part is taking a model built on OO semantics (using a language, UML, etc.) and automagically figuring out how to create a schema and persist this into relational store in a way that (1) does not create all sorts of concurrency and performance problems; (2) is transparent enough that DBA tools can be used for administrative, maintenance, and infrastructural reporting needs; and (3) is amenable to refactoring of the OO model since the in this case the OO model is prior to the persistence, and we recognize the benefits of "refactoring mercilessly" on the model side.

I am glad to see continued work on this problem. But I want to see more discussion right up front on exactly which models have priority in each of these schemes, so that developers can more efficiently choose the right approach for a given project. For example, Rails gives priority to a database schema; EJB 3, Hibernate and the WilsonORMapper take a middle position requiring modest work on both sides of the divide; Persistor.net gives priority to the object model. All good products for the right problem, none perfect.

Microsoft's white papers on ADO vNext suggest avoiding the issue by abstracting up a level: defining models in terms of a more abstract entity definition system. In exchange for defining domain models using Yet Another System, we would be given tools to seamlessly match these entities to objects, on the one side, and storage mechanisms like RDMBSs on the other side. Both the OO languages and the DB become second class citizens to the entity model. Since I'm writing applications in these OO languages, I'm not sure I'm ready for that, but I'll wait and see.

Meantime, if we're not clearer on what we're doing -- putting an object model into a database versus the entirely different affair of pulling database records into objects -- we're going to continue to see grand new schemes that never really take hold.

Free Toys, No Warranties (Yet)

Although official release is still some time off, our new J2ME phone client is looking great under preliminary QA. So I'm making it available to anyone who wants to jump in and play now. We focused on a few areas where the initial release had trouble on many handsets, and made the new version tighter, prettier, more usable, and compatible with most MIDP 1.0 / CLDC 1.0 phones. That is, this release is designed (*cough*) to run on practically any Java-enabled handset, including Treos and many Cingular Windows Mobile devices.

As we continue our QA process, we will make refinements as necessary to bring the bits closer to this grand goal. But in the meantime, if you're reading this blog, you may well be the kind of person who is excited to make a change and try something new right away.

The easiest way to get it is to send yourself an SMS with the .jad file URLs:
http://www.goskip.com/dl/skip11.jad
and
http://www.goskip.com/dl/skip11nds.jad

The only difference between these two is that skip11.jad includes a MIDlet-Data-Size entry, which is necessary to get good behavior from some phones (e.g. Moto RAZR) but breaks other phones (e.g. Audiovox PM8920); skip11nds.jad (nds = "no data size") omits this entry.

The only instruction which is really necessary (cannot be inferred from the UI) is that all syncing with the server is now "on-demand" -- meaning you press the 0 (zero) button on the handset whenever you want to sync. We found that multithreaded net and record store access was creating difficulties on some handsets, especially when cell network coverage was weak or intermittent. So we made this change to make the app clearer and more user friendly, even (especially) when things aren't working perfectly on the cellular side.

Have fun!

OO Part 1: Irony

I am writing a post about OO and data, collecting thoughts from recent development experience that have after the latest Microsoft CTP of LINQ.

But before addressing OO/data, I realized I may need to mount a mini-defense of OOAD to set the stage. In particular, I find it ironic that, on the one hand, at the implementation level OO tools, languages, and pattens have become de facto standards (whether .net or Ruby or Java, whether Visual Studio with its built in CASE facilities or Eclipse with its first-order refactoring and semantic search); yet true OO analysis and design (at the human domain level, not the system or design-pattern level) seems to be out of favor. It appears that OOAD practice is still seen as being tied to heavyweight long-running processes (not agile enough).

With respect to the timeline and heaviness of the process (usually measured by the proportion of activities which are bound to non-code deliverables or resource intensive checkpoints such as meetings or workshops), OOAD can be heavy or light. The heavy examples are famous, the light ones less so because there is less to be famous ...

But the power of the OOAD process to solve hard development problems in vertical domains remains remarkable. Let's make this concrete. Some time ago, eTag (the predecessor company to Skip) was prototyping a new form of automated airline checkin. We worked with one of the major carriers in the US. In the beginning, important stakeholders at the airline were convinced that the sort of automation we proposed was an impossible, intractable problem because of the enormous sophistication of their check-in system and related workflow activities (e.g. seat changes, upgrade request processing.) Without being inside the airline and working our way through everyone else's systems there, it would never work, they felt.

Our assertion was that it is possible to execute checkin scenarios, upgrades, loyalty program operations, rebooking, etc. in an airline agnostic manner using only actions (like "change") , objects (like "seat"), and events ("your account is charged when you make some flight changes") that the customer is already familiar with. Or in other words, we asserted that neither the customer nor the front end of the system needs to understand the airline's peculiar internal rules and representations regarding seats. No knowledge of mainframe record layouts, fare codes, or business rules is necessary to fully define these activities.

It is possible to address scenarios such as these using various "more agile" techniques... but the actual clear, articulated OO analysis deliverables were a sine qua non to establish that our approach did work. A partial implementation, code iteration, or a process that meant our team could move like ninjas was meaningless. We needed to show conclusively that the approach could solve the entire problem before we could overcome the objections and meet the risk profile necessary to move forward.

And the full analysis (large in scope but only weeks in duration) allowed us to execute not only the front and middle tier parts, but also the proprietary legacy integration for everything in a matter of a few months. Because we had already validated the shape and behavior of every domain object in the system, even an extremely complex custom integration to ancient, undocumented, and proprietary mainframe components was reduced to "mere implementation detail."

Points Of Interest and Mobile Interactions

The other day, when my family was in Miami for my brother's wedding, my dad decided he wanted some ice cream. He had been playing with his Garmin StreetPilot, and imagined that perhaps there was a Haagen-Dazs ice cream stand around, and maybe the data point was in the GPS.

Not only did keying in Haagen-Dazs pull up a location, but it yielded a nearby supermarket with a dedicated Haagen-Dazs freezer case. I was impressed and very surprised: my dad is not the kind of guy who, out of the box, would have gone looking for third-party databases to upload into the GPS. So I surmised that this unit actually ships with either (a) coordinates for all known Haagen-Dazs locations or (b) a mapping that could recognize Haagen-Dazs as a food brand, and infer that a large supermarket would be likely to carry the product.

Either way, someone ensured that the "Haagen-Dazs" literal could be used to find an unaffiliated business (i.e. not a Haagen-Dazs franchise) via the GPS database. A quick check revealed that not every major ice cream brand has the same coverage in this GPS, so I imagine that this is essentially a sponsored search scenario.

This rocks! A company went out of its way to make its product available to my dad in a situation where he otherwise would not have been able as easily to find it -- and they did it unobstrusively. No ads, just the right information at contextually the right time.

Haagen-Dazs has some other interesting GIS features: check out their online "flavor finder". I can't wait until more companies start realizing that greasing the skids just little can bring more sales and massive customer loyalty.

Meanwhile, Garmin has an open interface that allows third parties to publish Point of Interest databases (as text files) that a customer can then import into the GPS device. So if I want to open Adam's Ice Cream, my loyal fans can subscribe to my POI database via RSS, keep it synced to their GPS, and now I'm playing right up there next to Haagen-Dazs. This is brilliant. The two features together (dedicated placement for big brands, and a free open DIY-POI integration for everyone else) is great combo that covers the big bump and the long tail.

Time for a "Platform" MVNO?

A week or so back, Russell Buckley published a post on The Frustrations of Java. In particular, he was speaking about J2ME, the Java platform for mobile devices. After a roundup of the issues that plague those of us using J2ME to deploy products, he concludes that perhaps WAP will end up winning because it's "good enough" in a number of respects.

Russell's right on about J2ME, about carriers, and about handsets. But WAP and its variants have been in the marketplace for over 7 years now, and while cellphones and their users have evolved, WAP continues to be an evolutionary dead end. Not extinct, but maybe only alive on a small remote island. Clearly not "good enough" for mainstream adoption so far.

So where does that leave us?

I believe the carriers are leaving massive cash on the table by retarding the progress of mobile-phone-as-computing-platform, which it definitely could be. Phones are today where PCs were in the mid 80s. Lots of apps, lots of different computers, not yet to the point where the "100% IBM PC Compatible" could became the platform to distribute applications. The "PC compatible" emerged not because it was superior but because its owner could expect to run all sorts of apps on it, and app vendors could expect all sorts of customers to have it. A sort of chicken-and-egg problem helped along in the by killer apps like WordPerfect and Lotus 1-2-3.

In a recent conference call, a developer-relations rep from one of the carriers discussed moving to a more consistent J2ME implementation for their MIDP 2.0 phones. When they began offering phones supporting MIDP 1.0, he said, they let the handset OEM put any Java runtime they felt like on any phone. At first I howled in pain, thinking of the late nights that this laissez faire approach cost us who write code. But I realized: suppose this company had subjected the initial Java deployment to the same standardization and QA regimen that they use for voice-call service ... who knows how many years' delay would have ensued?

So I applaud the company for taking a chance on programmability of what had been a completely closed embedded device. This is the attitude we need, and that willingness to open up is the first half of the solution. The second half will need to address the problems Russell wrote about in his post. I don't know whether this ought to be a wholly new platform that phones support; a new version of Java (J5ME?) with a really tight specification and minimal room for ambiguity; or wider adoption of an existing OS like Symbian or Windows Mobile.

But I do have an idea: how about a MVNO whose differentiator is that it promotes regular handsets (not just high-end smartphones) as a general purpose platform for computing. Perhaps it offers J2ME with all the "extra" (JSRs), or more than one platform, the way some phones provide Symbian+Java, or WinMo+Java+Flash (Cingular).

In any case, on the developer side, there would be rock solid specs for how these phones actually behave, open APIs to the voice, network, storage, and embedded apps. On the consumer side, the phones would actually be promoted as computing devices for all sorts of work. More like the early Palm devices than the Treos. The MVNO would charge for the device and for the network connectivity and could pick handsets that are reasonably capable. Access to add/remove/configure apps would be completely open, and the ISVs could win or lose on their merits.

Would enough people subscribe to cover the overhead? Out of the gate, it's hard to say. Other phones/carriers/networks might seem "better." But wait until the apps start coming. It's why I don't still run a TRS-80 or a TI99/4A.

More Dogfood

I'm off tomorrow to my brother's wedding in Miami. As usual, I'll be traveling with Skip, and I expect to learn a bunch.

Since I'm usually neck-deep in code, testing things, and prioritizing features, it's fun to step back and experience Skip as a user a little bit. When we're building the system, there's always a focus on bugs that need fixing, or features the system doesn't have (yet). So it's easy to forget how well it actually works. That's the nice part.

At the same time, you can't help but feel the pain from all the missing bits. Features that were cut, or haven't been implemented yet, or totally new things that just jump out as must-haves.

We'll see what jumps this time...

Less Typing

One quick tip for sharing Skip: if a friend is interested in Skip and asks me where to get the client, I'll send him an SMS (via web or email) with the download page URL http://www.goskip.com/dl in the message.

He can then use Extract -> Go from most phones to launch the browser straight there. It's a little thing, but I find some people dislike typing on the phone keypad enough that this makes a difference for them.

10^H Things^H to do with Skip

Ok, I thought it would make a cool post to come up with 10 things you can do with a Skip account outside of what it's designed for (namely travel).

Instead I decided to post the 1 thing I've found most useful so far; post your own idea in the comments and maybe we can come up with 10 together.

Just creating entries online, and managing all sorts of notes or lists I might need to keep track of one the go ... grocery lists, gift lists, driving directions, random to-dos ... and being able to get all that data anywhere on a phone, without the mutant mini-browser, is pretty sweet.

Now, if you're reading this blog, odds are you've already got a personal solution to this problem. You have a smartphone, or something that syncs with Exchange or with an online PIM suite like a web portal with address/notepad/etc. Or you've got a wired PDA that you sync.

But you probably know someone (maybe a lot of folks) who aren't so wired, and would be surprised to know they could bring all this stuff with them with just a phone (and without fighting their way through the so-called wireless web).

For my own part, I've always loved the Exchange notes sync with the BlackBerry. I probably use that 10 times a day. But my wife uses a regular Samsung phone, and she was thrilled to see that she could throw all sorts of data in online and have it on the wireless, with no cellphone "typing." Plus she and I can "share" a Skip account, make updates to each other's items, and stay in sync.

I wish the best for the pure-play web/wireless groupware systems out there -- a quick Google search turns up AirSet, which looks very cool! Skip is obviously in a different sort of space, but it's handy that some of the basics are a Skip freebie too. I believe that in the mobile productivity space, the more the merrier, as we are just starting to see a dawning general awareness that the phone is a platform. This awareness -- together with apps that make it real for average consumers -- is key to creating a flourishing ecosystem for mobile software.

Midlets in Space

I've been agonizing a bit over whether it is a good idea to create a real, running web instance of the Skip phone client using one of the J2ME-in-a-J2SE-Applet phone emulations like ME4SE or MicroEmulator.

When I first saw a product being shown in one of these emulators (try before you buy!), I thought, "Why doesn't everyone in the mobile software business do this? What a no brainer!" This system lets people see real live apps, instead of screenshots. Here's a great geeky example.
It give a more believable presentation of the app experience that a customer would get (provided her phone has specs similar to what's being emulated, of course). This sort of thing is just what is needed, a lure to get consumers over the hump, where they'll download an app because they've really seen what it's like.

But I'm afraid I'm in a position to recant that statement. There are two issues which argue against that sort of demo.

First, the ergonomics: when you're holding your own phone in your hand, it's comfortable and intuitive to hit the directional keys, softkeys, etc. with your thumb. In the emulator, however, you're using a mouse pointer to click on tiny images of keys that belong to no phone in particular. So a user actually gets an impression of the app in the emulator that is much more awkward than an installation in a real device would be.

More importantly, however, is the user's context, and the way it informs perceptions about the usefulness and value of the application.

Here's an example of how relevant the gap is between the context of user-on-PC and of user-away-from-PC: on a Windows PC, the built-in notepad text editor is the most mundane and unimpressive of apps. But now imagine you don't have a desktop or laptop. You're using a mobile phone or a PDA to take some notes while sitting on a bus. All of a sudden, that notepad experience -- resizable window up to 1280x1024 or more, full-sized 104-key keyboard, mouse for selecting text -- would be a phenomenal luxury. Imagine if you could have that experience somehow with a palm-sized gadget!

Well, mobile software demonstrated on a PC has the same sort of issue: on the giant, 32-bit screen of a 3+ GHz PC, next to Half Life 2 and 4 Mbps of broadband, mobile software in emulation looks like some sort of hokey throwback. "It's so small and awkward, it's not pretty and it doesn't ever do very much." Well, when you're away from that PC, if a tiny piece of software does the one thing you need, it's pretty sweet. Consider BlackBerry email or SMS text messaging. In the right context, these are great communications apps. Never mind how they stack up to Outlook 2003 or a full-on IM client.

And that's basically the issue. I want customers to be intrigued enough to try Skip. But I want their first Skip client experience to be a discovery of how much that handheld device and 3G network can do for them when they're out living life away from a PC.

Why the BlackBerry? It's shaped like the future.

After the rush of getting Skip's beta product published, it's nice to take a step back and have a look. The first thing you see (if you're me anyway) is missing pieces or obvious questions not really addressed in the current release. One of the biggest, to my mind, is this: Why the BlackBerry? I.e., why is the BlackBerry client the "flagship" one ... and why are the other clients patterned on the BlackBerry client, rather than simply being the best possible implementations for their respective platforms?

It's hardly that the BlackBerry device or platform is perfect for deploying a next-gen mobile productivity app. The total number of subscribers is not large. They are not, as a group, as likely to download (or -- gasp! -- buy) 3rd-party apps as, say, Palm (Treo) users. There is a mass of underpowered legacy devices in use. The platform features an inordinate number of API changes between minor versions; a vendor tool suite from another millennium (an era that Eclipse and VS.net have put behind us); and a complex deploy environment due to the BlackBerry Enterprise Server which provides the "BlackBerry magic" along with numerous possible fine-grained management/security restrictions.

Well here's the deal:

The BlackBerry platform has the general shape of what a net-connected mobile personal device ought to be:

• It's always connected, or at least your app can assume that it is. Net problems are handled gracefully, and the stack is clearly optimized to behave well with the squirrely environment of mobile data. But beyond this, the shape: it doesn't feel like network access was grafted on (virtual serial port + PPP + #777, anyone?). It's just transparently there all the time and in that sense it's more like a PC plugged into a LAN and VPN than other systems (which generally resemble a PC with a dialup ISP account).
  
  
• Threading works well. That's a big and gnarly statement, but what I mean is: for a basic business productivity app that wants to run tasks in the background, including network access, it works so well that I've never had to wonder what sort of embedded OS might be underneath the Java VM. The same cannot be said for many other devices/platforms.
  
  
• Multifunction integration on the device. The code-signing bits for directly interacting with the unit's PIM, telephone, and network are inexpensive and easily obtained. So it's easy to create the kind of smart interconnected apps we all want. The kind where you can dial the phone, if that's what the user wants, or where you can create "hotspots" that automatically integrate with the existing email or web browser tools, or grab a contact from the address book.
  
  
• Multitasking. Based on threads (with enhancements) rather than full process independence, but for the average user, it's multitasking. So you're not forced to quit the app just to check your email, make a phone call, or look at your calendar. You can run Skip in the background forever, if you want to.
  
  
• Upgradeable. The BlackBerry is upgradeable to new platform versions. While this exacerbates the "mass of underpowered legacy devices" issue, it creates more customer (user) empowerment ... like with your PC, you decide when to toss that monochrome unit, or the one with the old processor for the new one with the Intel XScale. But in the meantime, you can keep your data and upgrade the system! From an ISV point of view, this means it's reasonable to offer an app for, say, platform v. 4.0.0+, instead of having to choose to either support the baked-in non-upgradeable platform version in a particular model, or else not support that model at all.
  

I believe that these properties describe the fundamental "shape" of an Internet connected personal device, more than a built-in camera, VGA screen, or even EVDO (or HSDPA). For this reason, the BlackBerry app becomes the flagship. I decided that in the first iteration, I'd like to see how close the other platforms could come to this basic set of functionality. With that territory charted, we can go back and adjust the other client versions in the future, hewing closer to the specific strengths/weaknesses of their respective deployment platforms.