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.
Friday, May 26, 2006
Wednesday, May 24, 2006
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.
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.
Wednesday, May 17, 2006
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!
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!
Tuesday, May 16, 2006
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."
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."
Monday, May 08, 2006
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.
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.
Thursday, May 04, 2006
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.
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.
Monday, April 24, 2006
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...
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...
Sunday, April 23, 2006
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.
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.
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.
Tuesday, April 18, 2006
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.
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.
Sunday, April 16, 2006
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 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.
Subscribe to:
Posts (Atom)
