Obligatory Windows Vista Post (™), Part 2

Improved high-density display support is a big part of Vista. But what about those of us with low-DPI displays?

Ok, is that supposed to be a joke? Who would have a low resolution display?

Anyone who has a LCD panel larger than 17" and which runs at a native resolution of 1280x1024. Which is to say, anyone who has bought a nice desktop 18" or 19" panel in the last couple of years (excluding some widescreens, and the 19" panels at 1600x1200). The Vista "baseline" resolution is 96 DPI, which turns out to be just right for typical 17" flat panels (at 1280x1024). On these displays, UI elements which are sensitive to DPI render beautifully. In particular, the ClearType font smoothing technology which is widely used in Vista, even for legacy apps.

That same ClearType logic on 18" panels (87 DPI or thereabouts) or larger produces text so blurry it's distinctly uncomfortable to read.

The display customization box where a user can specify the DPI of the display has another complementary quirk: it allows you to choose higher-than-standard pixel densities, but not lower ones. If one types in a lower pixel density (as a percentage), it "snaps" back to the default setting. Moreover, if you have two monitors with two different pixel densities (I can't be the only one in the world in this situation), there's no way to specify that. It may be the case that a video card can supply this additional option, but it's not available in the latest nVidia drivers. And what if you have two different video cards (so that a single driver is not managing both of them)? The latter possibility suggests that the OS needs to provide this option...

Any ideas out there? Am I missing the "big red button" somewhere that fixes this? (By fix, I mean offer a place to enter the precise DPI of each display, so that the OS can inform apps, and tune its own services [ClearType] accordingly.)

Finally, lest anyone wonder why a large lower-res display (such as 19" monitor at 1280x1024 native resolution) would ever be desirable:

1. Viewing HD media content from a distance. Neither a smaller monitor, nor more pixels on a bigger monitor is a significant help here.
   
   
2. Gaming. Running a game at 1280x1024 on a larger screen is a great way to get a rockin' immersive experience without the substantial additional system load that would be required to render 1600x1200 (or widescreen) frames.
   

Anyway, I'm looking for answers. In the meantime I think I'll downgrade to a pair of matching 17" displays for regular Windows work.

Obligatory Windows Vista Post (™), Part 1

Ok, what's to say about Vista RTM amid the flood of coverage...

I installed Vista on my wife's laptop to do some usability testing. She is a relatively strong "typical Windows user", but not a "power user." Uses Office, the file system, corrects redeye in photos, knows what not to click on on the web; has no idea how to add user accounts, update a driver, or monkey with the control panel; doesn't know why anyone would want to do it.

As a geek, the parts of Vista I love are the parts not immediately visible. Mainly, the out-of-the-box support for .net 3.0, especially WPF and XPS. I'm always asking, "Have you seen the New York Times Reader?" I'm still mourning the loss of WinFS, and the Vista shell experience struck me as just-another-graphical-shell, with a couple of new things to see/find/learn/adjust to. My wife, on the other hand, had no problem with any of the changes (e.g. in the filesystem Explorer windows). She loves Vista. She said she found it way easier to use than XP: more intuitive and more productive (not to mention more visually attractive).

My point here is not to make a commercial for Windows Vista; this experiment compares Vista only to XP, and says nothing of how, say, OS X would stack up. Instead, what I really learned was how differently usability design / engineering / testing in Vista comes across to a "normal" user than to a geek. Every time I "discover" this usability fact, I am surprised anew, even though I shouldn't be.

I'll never stop being amazed by (1) how completely wrong we geeks can get it when we try to talk about what is usable and appealing to average tech consumer personae; (2) how brilliant the great usability engineers and designers are who can get some of this stuff right up front; and (3) how much of a mistake it is, when developing technology products, perpetually to defer serious usability study.

Mauve has the Most RAM

Here's a recent post on the 37signals Job Board. I've seen a number of these postings lately, and I wonder: why would you specify a particular technology or platform when you haven't prototyped (let alone built out) a product yet?

When I've posted ads for jobs at Skip, notwithstanding our existing platform and the advantages of extensive experience in the relevant technologies, I've always emphasized that talent and attitude count way more than a particular language or platform. Experience with core CS concepts and perennial software development patterns/anti-patterns comes next, but is still more important than a platform or framework. Because anyone really talented knows that just as "Java is the new Cobol," .net will someday be the new MFC, and RoR will be the new ... OK, you get the point. And anyone with the proper foundation, inclined to ask the right questions, can learn new frameworks -- even new practices/methodologies (like an agile approach) -- and put them to use.

So why are Web 2.0 founders performing what I would call an extreme and misguided attempt at premature optimization?

First guesses:

• It's boom time again in the Silly Valley, they've read a Business Week article that talks about platform X, and decided the way to become the next Google is find some X hackers
• They don't understand the differences between the open source options, but like the idea of open source, so they've picked one... that is, they really mean "I believe open source affords my startup some opportunities or advantages, and I need an architect who is an expert in the relevant options"
• They asked their geekiest / most successful techie friend, who said, "Just go with X nowadays, don't worry about [insert important but subtle tradeoff here]"

I have another idea: the entrepreneurs have gone a bit behind the hype to get a feel for the practices or philosophy associated the best-known practitioners on that platform. They then imagine that the best way to find folks who subscribe to that philosophy is to decide on the platform, then hire for the platform.

So when someone insists on LAMP, for no particular reason, maybe they really mean they are hoping to engage an engineer or team that embraces agile practices or at least agile concepts. When the entrepreneur has got his mind set on Ruby, he really means "the Ruby way" (least surprise, don't use 200 lines where you could use 10, etc.) If he or she says Ruby on Rails, it probably means get-it-up-quickly, include-some-AJAX, and ActiveRecord-will-do-it-for-now.

These folks would do well to distill out their methodology desires from premature platform commitments that cascade into hiring filters. After all, with the hardware virtualization and bytecode interpreters prevalent (and coming), and web services as de facto server-side object bus, we can do ActiveRecord on .net on Mono on Linux, or Java interoperating with Ruby on OS X, Agile development with IronPython on IIS... There is less reason than ever to close off options before any code has even been written.

Travel Right with Skip 1.2 for Blackberry

It's been about a year since the first version of the Skip client became available for testing. Targeting connected business travelers, and inspired by the interface metaphor of classic killer Blackberry apps like email, the Skip Blackberry client was heavy on text and light on visual sophistication.

As Blackberry users migrated to the high-density color devices like the 87xx and now the Pearl, Skip started looking a lot like opening Notepad on Windows Vista. But the 1.0 release suffered from the curse of being good enough. No major bug was ever reported for the Blackberry client, and the biggest usability problem by far turned out to be folks having trouble keying in their id and password on the device (not just SureType -- even QWERTY folks have had a lot of trouble, strangely enough).

Meanwhile, 2006 turned out to be a busy year for Skip's 1.5-FTE engineering division: to get the ball rolling we needed to deliver the core Skip server app, minimal web UI, travel industry integration, Java phone client (twice), Plam/Treo client (twice), Windows Mobile (it's in test, so try it now with this OTA install; additional bits you might need install OTA from here and here)... and the Blackberry client never got a proper polishing because it was just good enough never to get to top of the "urgent" list.

So I'm glad to finally offer this substantially touched up Blackberry client to all of our loyal early adopters. Most of the changes are small bug fixes, ergonomics improvements, and UI features which will be self-explanatory to readers of this blog. The only non-obvious change is a power-user mechanism that lets you use the same client to work with a production (www.goskip.com) or test system (peridot.goskip.com) account: in the username field, simply prepend "test!" to your email address (e.g. instead of foo@bar.com, test!foo@bar.com), and the client will operate with the test system.

You may notice some new UI features (like the icons) will only appear via the test server for now, as we'll be doing some additional testing before moving the server code changes into production. ETA is probably a week. Also, the first time the client syncs, it will load up the icons into its local cache, so that first sync may take a little longer than usual, especially over EDGE.

Let me know what you think, and thanks for your patience this, er, um, whole year.

Security Questions Considered Harmful

I went to sign on to the citibank site today, and before I could complete the sign-on, I was presented with the following required step:

This whole approach is just so darned awful.

This data isn't secret. Some is public record, like where I was born. Other things, like my favorite pet's name, are not pieces of data one normally protects. It's much easier to amass a collection of unprotected facts, and use those to pose as someone, than to compromise an actual password, an encryption scheme, etc. Moreover, most of these questions are used by many sites for the same purpose. So if I know someone's nickname, street address growing up, city of birth, mother's maiden name -- all readily available in the U.S. -- I'm that person on a lot of websites.

Personally, I use Mr. Schneier's approach of typing in random gibberish, thereby protecting myself at the cost of some convenience if I do lose my password.

While I'm on the topic -- and I'm sure someone has written authoritatively on it before, but nevertheless ... -- I am surprised how rarely people realize that their unprotected email account is the weakest link for all of their "secure" online activity.

Many sites (including Skip) email a new password to a user upon request. The gmail account that they stay logged in to, or log in to from a questionable computer in a hotel lobby, thinking, "My life is so boring, hey if someone wants to read my gmail, let them" ... or a business email account accessed on the road in the clear ... these become the easy way to get passwords.

There's nothing inherently wrong about using email to do a password reset (reset -- that means only a temporary password is sent via email; the user must then change it to a more protected one). Folks just need to realize that the email account -- if it is registered with sites that send passwords -- needs to be protected. Complex password, routine changes, all that...

The Transactional Web

Ok, maybe a double-Z-list blog like this one ought not to start coining phrases.

On the other hand, I started thinking a little about the taxonomy of the (programmable | read-write | 2.0) web.

Three categories came to mind right away:

• Classic mashups take two or more sources comprising different kinds of data, and combine them in a new UI or tool. This group includes things like HousingMaps (housing from craigslist + Google Maps), or BroadwayZone, which pulls in show info, hotels, transportation, etc., and uses Google Maps to provide a substrate and a UI for working with all of this data.
  
  
• Agent apps take multiple sources of related data, and bring them together to perform an action on behalf of a user. Some are goal-seeking agents, which search a wide space and narrow it down to something tractable based on a heuristic like minimizing a price. Kayak, which interacts with a huge number of travel websites and vendors, and Ugenie, which searches e-commerce sites, are agent apps.
  
  
• Proxy apps take one or more sources of data and bring it into a new context. 411Sync's Kayak queries use Kayak's own API to get raw data that can be formatted for the SMS service. This category also includes RSS (client) widgets, and mobile smart clients like Abidia (mobile auction), Mobio (movies) and, yes, Skip.

Being at Skip, it's probably no surprise that I find the last category the most interesting personally. This category of apps is spawning what I've started calling the transactional web -- it's a flavor of mashed up app that makes real commits against external services. Not all proxy apps are involved in the transactional web, it's just that mobile proxy apps are where a lot of the transactional excitement is right now. Unlike the other categories above, these apps are doing things like buying movie tickets out of a finite inventory, checking you in to a flight, bidding in an auction.

Other kinds of apps can be "transaction mashup apps" of course -- I can imagine a travel web site that uses airline seat change APIs together with, say, SeatGuru, to automatically get your family the combination of seats you want to sit in.

But to do that, and all sorts of other amazing things, more "transactional APIs" need to be opened up beyond the B2B world they're trapped in now. Companies -- and old economy companies in particular -- have been hesitant to open up these services as transactional APIs to the general public. There are some financial and security concerns, but they are not insurmountable as PayPal's successful payment API has shown.

What we need now is for folks like United Airlines to offer the same things via API that it has already put onto its web site (check in, cancel, standby, upgrade, seat change, flight change, status). Each web check-in helps the airline, and saves it money; the service should be published as widely as possible.

OpenTable blazed an early path with web-service-standards-as-B2B-infrastructure. But, hey, there are some great apps in the heads of people outside their small group of strategic partners.

Web 2.0 has shown if nothing else that there are more good ideas out there for what can be done with a data set than there are in here. And that the value of the data often increases the more freely it can be used by other applications in unexpected ways. I'm suggesting that the notion of a web-service-accessible data set be expanded to include the real-time seat map of an aircraft, the reservation book at a restaurant, the transaction history and current status of a Visa account, a doctor's appointment schedule ...

All the hard work for this stuff has already been done. When this switch finally gets flipped on, you're gonna see some real fireworks.

More API ... Build Your Own Interaction

An updated API is now available that starts letting anyone bring the pieces together to create mobile interactions. As before, the web service API is on the test server at https://peridot.goskip.com/skip.asmx and you can get a dev key by emailing me. The secure connection which was originally optional, is now required.

The API adds three new operations. Two of them ("MemberExists" and "CreateAccount") can be used to programmatically create new Skip accounts. Why would you want to do this? Suppose you had, say, a site oriented around a conference. You could give users an option to add conference events to their Skip account... and if they don't have a Skip account, but you have their email addresses, you could automatically generate a Skip account for them and insert the new activities.

But here's where it gets really fun: suppose you want to create interactions for these users, meaning real clickable menu items on their mobile device, associated with the conference activities you've just created for them. We've implemented a system that lets you do this in the easiest possible way. Using the "PublishAction" API, you can specify a display name (what shows up on the mobile device menu) and a URL that Skip will call back when the person clicks the item.

Technically, Skip will issue a HTTP GET to the URL you specify, will append ?user=xxx or &user=xxx as appropriate, where xxx is the user's email address, and whatever text you return from the GET (probably best to keep it short!) will become the "result" document from the user's Skip action invocation. When you call PublishAction, the API returns a bind key (a GUID) that you insert into the Publisher Data field of any item you create and that you want to feature your new menu item. The syntax is [bind:xxx] where xxx is the bind key. You can include more than one action on an item as well.

So here's a quick example. You're organizing this conference, and you want to offer your users event data through Skip. In addition, for conference keynote sessions you want to offer a quick "Thumbs Up" or "Thumbs Down" rating menu item. First, create the Thumbs Up and Thumbs Down actions, with as much specificity as you like (e.g., different URLs per keynote). Let's say you publish Thumbs Up, asking for a callback at http://www.tempuri.org/rating.ashx?keynote=monday

You then create the Monday keynote event for your users, and pass the bind key expression in the publisher data. When the user views the keynote event, she will now be offered a clickable menu item "Thumbs Up" -- and if she clicks it, Skip will make a call to http://www.tempuri.org/rating.ashx?keynote=monday&user=jane@janedoe.org in real time.

Where you go from here is up to you, but the possibilities are huge -- these callbacks are versatile enough that with a little creativity you can use them for restaurant reservations, ordering food, meetings, conferences ... they are pretty much a generic mobile front end for any one-click simple transaction that you might currently make available via the web.

Two final notes...

First, these APIs will continue to expand, allowing you to update items you've published in real time, and allowing you to create more complex interactive menu items with "wizard" type workflows and graphical elements. We already use these techniques at Skip for travel industry transactions like airline check in, and we want to make them available for general use.

Second, you might have read this far and are thinking "This is news? I publish a label and a URL, a user clicks something and your system issues a HTTP GET to the URL and returns a document ... isn't this called the web, and the technique is like 15 years old?" If you're asking this questions, then the answer is "Yes, exactly."

Windows and Linux Avoided a Big Java Mistake

As we wind down toward releasing our first dedicated Windows Mobile Skip client, I reflected on how easy it was to port the core logic from a Windows desktop test implementation. I compared this to a time when I wanted to port a modest J2SE library (which did not require any "fancy" APIs) to J2ME. And to another time when I needed a similar port for a Linux library.

It seems silly if not dumb to have to say this, but the fact that the Windows APIs for mobile are so similar to the full-on Win32 APIs (including the .net compact framework) makes it a no-brainer to convert many apps to run on mobile. Ditto with Linux, which of course represents an even purer case since "mobile Linux" is generally just another distro on another hardware platform.

So with Windows libraries, we can build, make a couple of changes, and off we go. Linux rules for porting, for obvious reasons, and ./configure; make; make install gets us "mobile."

Then there's J2SE to J2ME. Ouch. What were these guys thinking? Yes, things like this. And this.

But the bet was against Moore's law, and I believe it was not a smart bet for the platform. If Java has a future on devices, it'll be J2SE aka "Java SE Embedded"

Try Skip's First Public API

Skip's first public API is live on our test server. Part of our "keep it real" philosophy involves allowing public access to our test server almost all of the time, where interested parties can see and play with things we haven't quite finished.

The web service is located at https://peridot.goskip.com/skip.asmx, and opening the link in a browser provides the .net-generated descriptive and sample data for each operation, as well as a link to the WSDL.

Email me to get a free developer key, which is a string you pass in the devkey field.

The member field is the email address (Skip login) of the Skip member in whose itinerary you wish to create an item. publisherdata is the initial descriptive text corresponding to an item (which appears in the "annotation" box on the web). In the final release, this data will have its own independent field, which you will be able to update via the item handle that is returned from the Create operations.

Ignore the groupkey field for now, as it is not implemented yet -- but it will be used in a final release to allow you to associate multiple items so that the end user can move or manage them together as a group.

For flight segment items, the record locator and pax names are optional, but must be present if you want to enable the end user to do a one-click check-in via his mobile device.

These operations only affect accounts on the test server (peridot.goskip.com), not the production www.goskip.com site. The test server also hosts versions of the mobile client which run against test, if you would like to play with the full end-to-end travel publishing and travel consuming experience.

What Exactly are you Testing Anyway?

Static/dynamic language debates continue ... spurred on by the continued success of LAMP and RoR. These discussions often evolve into an admission that the real issue is "What is being tested?, What is doing the testing?, and When?". For example, Bruce Eckel (a C++ and Java guru among other things) wrote a canonical post in 2003 asserting that dynamic languages seemed to him to offer greater programmer productivity, and although certain things were not being checked before runtime, they were in any case being checked. Cf. the whole RuntimeException and strongly typed exception debate in the Java world.

The corollary to this conclusion of course is that you don't want your users finding your bugs at runtime, so something of a test-driven or at least strongly test-supported approach is necessary. Testing and TDD are great. Just as great as compile-time checking. The problem is that the two are not testing the same things, or with the same coverage.

The specifics: static compile time checking typically covers 99% of the code for most applications (it normally excludes casts, dynamically generated code, and reflection among other things). From a user/feature point of view, it covers, well, 0%. So it covers a whole lot of things that are helpful, but not immediately relevant to the feature set.

Now look at a solid TDD-inspired test suite. Assume it adheres to best practices meaning coverage of all (functional) features (the core of TDD), multiple failure cases, non-trivial tests, etc. So we have coverage of 100% of features (again I'm excluding non-functional requirements like security, performance, design for the time being). And it will, through sheer exercise of code, verify a significant percentage of the formal code correctness, including type compatibility.

At this point, the problem and the solution are obvious (if hard to implement). PROBLEM: The test engine, including test suites, UI test runners like Selenium, components that generate random input data or events, load testing facilities, security analysis probes, etc. are still limited to producing an a posteriori analysis of a small set of cases. But these are only the positive cases (where positive includes success and defined failure modes) plus a tiny fraction of the negative (unspecified failure) cases. Type checking in strongly-typed languages provides a comforting a priori data set over nearly all cases.

SOLUTION: We need to create better analysis tools for all languages. We need a big step beyond the formal syntax checking, type checking, and lint analysis of code. Some more sophisticated approaches are going to be necessary. At the minimum, it would likely involve recursive runtime use (GUI design tools have "cheated" like this for years), dictionaries of data types, ranges, precision, etc., and a probability engine that can handle breaking up workflows into blocks in order to keep permutations within the compute capability of the hardware, and then recombining them along with a risk analysis of what's thereby been left out.

A lot of work has already gone into finding the boundaries of this problem, especially in academia and where languages (e.g. Scheme) with heavy academic use are concerned. Traditional static analysis and more importantly some human user hints will need to set up the constraints, so that the testing does not devolve into "testing any string that can be passed to eval"

Mini Manifesto

I wrote the points below to a colleague this morning, and I realized that they do a pretty good job of articulating the Skip "stake in the ground" on mobile software in general. Perhaps this a is "duh, no kidding" post. But I hope it's useful to someone who may be thinking about either introducing a new mobile product, or mobilizing an existing one:

Two-Screen Model

We’ve patterned our system after a two-interface system, one on the web, and one on the device, where both interfaces work against the same account, but are tailored to the web or mobile context respectively. We looked at how Microsoft Outlook and the Blackberry suite complement each other in offering access to the Microsoft Exchange account and we also looked at the Apple iTunes desktop client along with the iPod player software. Our belief is that those models work really well for users – a powerful management interface on the web or on the desktop, and then a custom-designed mobile client that picks up those settings and accesses the same data while on the go.

Smart Client Architecture

Although every phone (more or less) has a WAP/[X]HTML-lite browser, we believe that compelling user experiences will require at least a minimal client on the device. We like the smart client architecture as articulated by Microsoft: namely, an app that has access to local resources and privileges (local storage, control over the screen, security access for dialing, etc.) while gaining much of its leverage from remote network-based services. The app is offline capable, while the remote services make the client light and flexible across devices/platforms.

Client Device Development has Turned a Corner

In the past, it was not practicable for most companies to target a wide range of devices successfully. The devices were too disparate, and even the standards (famously J2ME) were absolutely not standard across devices. This environment is changing as we speak, and good progress has been made, so it is no longer prohibitive to target many devices. Skip is proof of that, with over 100 devices supported, on several platforms, and we’re a 5-man shop with other work to do too! Some specifics: Sprint has standardized all of their MIDP 2.0 phones on a single specific Java implementation, guaranteeing wide compatibility on Sprint with minimal effort (our tests have shown this is true in the real world, not just a Sprint PR world). Verizon and Adobe announced an agreement earlier this year to support a version of Flash on many of the new Verizon phones in North America. Mobile Flash has a track record in Asia/Pacific, so it’s not a “here’s my untested new world-conquering technology” play, and availability in the US should make it relatively easy to bring even sophisticated interfaces onto a whole bunch of phones using designer-friendly (rather than just coder-friendly) authoring tools.

Consumers

Consumers need a little marketing/education, but are hungry for mobile productivity tools. Especially the younger (16-35) demographic. These folks either assume their phone is capable of doing a lot, or they are easily persuaded. There is a real desire for anything that’s both useful (i.e. does something practical) and easy to use.

IT Procurement 2.0

I posted a little while back about Zenni Optical, which sells eyeglasses starting at about $16/pair complete. The other day I was looking at a pile of generic ink cartridges I've gotten from Digi4Me.com, at a cost of about $1-2 each (the name brand versions can run anywhere from $10-$30 each in stores). We test a lot of phones at Skip, and sometimes we need extra chargers. I have a bunch of USB-type AC chargers (e.g. for Moto RAZR or Blackberry) -- $6 each at BargainCell.com. Price for "official" equipment at other sites? $25-$30 each. And miscellaneous hardware that we use for desktops, laptops, etc. in the office has come from a whole host of great vendors that all have two things in common:

1. The vendors offered the best or near best (within 20%) price for a generic product on pricewatch, or they were matching that price range
   
2. If they advertised on pricewatch, then they had 4+ stars from their reviews

Once upon a time, Dell disrupted all of the PC builders. They were so successful at addressing every market segment (home, small biz, enterprise) that even startups would get their equipment through a big ol' Dell account. And it was a reasonable choice.

That era is over, for startups anyway. With the half-life of technology running as short as ever, there is no justification to pay extra for a supportable or supported configuration. (Mind you, production servers are a bit of a different story, but like many startups, Skip only has a few of those and they don't change much.) If a laptop breaks in 2 years, the user would probably need a better performing one anyway, and Dell doesn't look like they're too eager to support their own gear regardless.

And memory modules, monitors, hard drives, everything else? Bring on pricewatch! I haven't been burned yet, and more importantly I do not believe that any "established vendor" is going to do better by my small startup at any affordable price. I've seen enterprise vendors' support when I worked at a major bank; we had a virtually unlimited support budget for one vendor and yet no amount of green could make them show up, get things working, and keep them working.

So I've realized that IT Procurement 2.0 is about TigerDirect and Fry's and a myriad other vendors that are selling white-label gadgets or last-quarter's products for pennies, and are getting my dollars. Just as success put the lie to a priori dismissals of the LAMP stack, Ruby, and the cluetrain, a thousand startups today are controlling their burn by buying "great cheap stuff that works" from great vendors that want to sell it to them.

Moto + Linux = Real Progress in Phone as Platform

Motorola has followed up its aggressive stance on Java development at JavaOne (and I mean this in a good way, as any vendor's aggressive position is helpful in the wishy-washy world of mobile development platforms). At LinuxWorld today, Motorola exhibited the community and tool projects that go along with its plans to develop all mid-range and higher phones on a Linux OS. Exhibits included work on an Eclipse-based SDK for native app development. They plan to take on Symbian and Windows Mobile head-to-head in this arena of supporting native apps.

Greg Besio's keynote emphasized that Motorola is opening their platform (including publishing code for the core phone apps, in compliance with GPL requirements) and hoping that in return they will benefit from innovation in third-party apps that will flourish on their devices. Sounds like a plan. I asked a number of Moto folks about the balance they will be striking between carrier desires for control, and developer desires to, well, be able to deploy software on the phones. After all, innovative and compelling user experiences only go so far if you need a sync cable and bunch of cracked toolkits to get an app on your phone.

It sounds like a clear position statement has not yet been formulated. One individual said that infrastructure is being prepared in the SDK for various levels of code-signing to control deployment to devices. This could be a "cover all bases" move though, rather than a clear indication that code would need to be signed. Others emphasized that Motorola is committing resources toward helping developers move along the deployment path.

For my part, I emphasized two points to everyone with whom I spoke:

1. Any unlocked GSM phone that a user owns should be wide open. If a SIM card / network affiliation wants to restrict some net or phone traffic, fine. But the core device and the decision about what runs on it needs to be the owner's.
   
   
2. Even very restrictive carriers (Verizon, Nextel) have historically allowed owners of high-end devices carte blanche with app installation, provided the devices were designated and marketed as smartphones -- e.g. Q on Verizon, Blackberry on Nextel. Plenty of apps generate fatal exceptions on both of these devices, and the earth hasn't stopped rotating, so app robustness isn't the issue. And since smartphone users pay big bucks for their data plans, loss of revenue isn't either. Therefore, it would seem reasonable for Moto to position at least the high-end Linux phones as smartphones, and make clear that they are being promoted as devices which let users move data on and off, install apps, etc.

In any case, this is a great development for too many reasons to blog here. (Ok, so just one: J2SE anyone? ... yeah, it's about time ...)

Work at Skip!

Skip is hiring, and Mr. Malik said it best, just last week:

"the job boards don’t seem to have the necessary impact or perhaps get the right kind of users"

So first ... check out our ad on CrunchBoard.

Then, tell me if you don't think these are some of the issues that render the "big traditional" job boards less-than-useful for Skip and other startups:

1. They have a poor job taxonomy - many of these sites serve every industry from sanitation to aviation, and yet instead of having a category like "technology," they split tech up into all sorts of categories and subcategories. A startup-type employer has a hard time deciding where to post, and a candidate has a hard time narrowing the search.
   
   
2. Likely, #1 is a symptom of a heavy bias toward Fortune-500 org chart / HR type hiring. All of the tech categories and subcategories look like they came from some post-re-org bad dream at a very large company. The bigco bias doesn't just make it hard for the long tail (like Skip) to get involved, it drives away the audience we want (folks who love startups).
   
   
3. They foster job descriptions (and concommitantly attract resumes) built out of tech acronym lists and bullet lists of "years of" (you know what I mean). If you have "8 years of C#" you'd better have worked for Microsoft. Of course, resumes like this are a desperate response to foolish HR-composed job ads asking for 8 years of J2EE
   
   
4. For us, attitude counts. A whole lot more than the difference between "3 years of C#" and "4 years of C#" -- so these job boards that scream: "the candidates are bored, the hiring companies are boring, and we're both" are not going to draw the right folks.
   
   
5. Lastly, these boards are packed with jobs posted by recruiting agencies (staffing companies). Many of these jobs are widely believed to be bogus. That is, the ads exist to draw resumes, from which the recruiters try to find clients. Now, even if this isn't always true, the appearance of this situation drives away the serious candidates. Dice.com is a great example of a tech job board that used to be (in 1999 or so) rock solid. Then the staffing companies moved in with "jobs" that I've yet to hear of anyone actually getting/taking, and now ... well, let me just say I'm not spending money to advertise there.
   

Long live CrunchBoard and the rest of the niche sites!

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.