Software Everywhere

Software Everywhere http://www.pikesoft.com/blog/ en-us Nucleus CMS v3.33 © Weblog http://backend.userland.com/rss http://www.pikesoft.com/blog//nucleus/nucleus2.gif Software Everywhere http://www.pikesoft.com/blog/ <![CDATA[Taking digital ink seriously]]> http://www.pikesoft.com/blog/index.php?itemid=269 Web Tablets and Text Entry—How to Do It?

I’ve been looking at digital ink a bit differently lately as a result of asking myself this simple question: when do I really need handwriting recognition? I think part of the failure of digital ink has been the focus on handwriting recognition, which has never been good enough to make people comfortable. The human brain is so much better at reading ink and most (not all, but most) of what we do with text is write it and read it with our eyes. If your colleagues at work got occasional ink emails or IMs would this be a problem? Blog posts or tweets in digital ink form raise some issues when it comes to indexing the content for search, but might not the “best effort” handwriting technology we have today be good enough to make this content pretty indexable? The main thing would be to get that HWR processing out of the user’s face so they didn’t have the unsatisfying and distracting experience of it’s imperfect operation.

The tasks I consider that I can’t reasonably do with pure ink are things like creating spreadsheets and writing code. By and large they’re things I wouldn’t normally do when I’m genuinely mobile. I’d love to see more mobile devices that takes ink seriously as a “first-class citizen” for communication of information rather than something that is bolted on in service to ASCII text, which even in the best case imposes so many unnecessary limitations. Livescribe’s Pulse SmartPen seems to have great potential and it will be interesting to watch it evolve (adding wireless, a good desktop SDK, etc). But I believe that there are millions who are still looking for something like Mike Mace’s InfoPad concept.

I think speech is interesting in a few scenarios, but is ultimately quite unnatural as well. A lot of the excitement over it seems to be from people who aren’t really considering the real-world texture of the mobile use context: there are way too many situations where speaking to your device is awkward, rude, or simply won’t work because of the amount of other voices and sounds around. I’m much more optimistic that a rethinking of digital ink will be the Next Big Thing in mobile input/output.

I'm being a bit glib here in writing off the need for text entry as much as I have. For one thing, every resource available on the web is identified with a text URL and every search request must begin with text. But I have a strong hunch that we will find that incremental or even major improvements in handwriting recognition are not the only or best way to address the text input problem.

I know I can think of some better ways, and I'm surely not alone.]]> Pen Computing http://www.pikesoft.com/blog/index.php?itemid=269 Mon, 30 Nov 2009 10:01:06 -0600 <![CDATA[How's webOS doing?]]> http://www.pikesoft.com/blog/index.php?itemid=263 Michael Vakulenko at VisionMobile says:

Despite high hopes, Palm and its WebOS software has (sic) barely made a difference in the growing smartphone market. According to Canalys, Palm shares 3 percent of smartphone market with Linux and proprietary platforms in the “Other” category. Clearly, it is not enough today to make an excellent device powered by modern operating system based on Linux and Web technologies.

Of course if you read the Canalys report you could as easily have used the same screwy logic to say:

Despite high hopes, Google and it's Android software has (sic) barely made a difference in the growing smartphone market. Hype notwithstanding, according to Canalys, Android shares only 3 percent of the smartphone market. Clearly, it is not enough today to make an excellent, modern operating system based on Linux.

These analysts always make me chuckle the way they start with a conclusion they believe to be true (usually just an echo of the rest of the tech media) and then filter the facts as needed to support it.

Maybe I should give it a try using the latest data from AdMob, which ranks all mobile handsets, not just smartphones:

Despite high hopes, BlackBerry has barely made a difference in the new smartphone market, having been displaced from AdMob's top five list by Apple, Android and, most remarkably, Palm. Palm's dethronement of the RIM "juggernaut" in just a few months on the market—despite the Pre's initial availability on just a single declining US carrier—shows that it is not enough today to make great hardware and software integrated with bulletproof messaging services. As Palm releases more webOS products on more carriers in the coming months expect it's innovative Web 3.0 application model to quickly take the wind out of the sails of the Android and Apple platforms which seemed indomitable only a few months ago.

There. Can I have Roger McNamee's job now? :-)

All joking aside, after using a Pre pretty regularly for the last month or so and working a bit with the SDK I do think they've got a helluva dog in the fight. It's kind of ironic, but despite my passion for mobile computing I'm not a guy who can say he's ever really fallen for a mobile handset. I like the idea of smartphones, but mostly they frustrate me in the ways they fall short of their potential, especially in terms of the user interface. I use a LOT of handsets on all the platforms in my work, but when I pick up the Pre I marvel at how much of the pain I experience on other phones simply isn't there. It's not perfect for sure, but it's an incredibly good start, in my opinion. I'm also hopeful that Palm is on a better track with their developer program than Google and Apple. Dion Almaer and Ben Galbraith from Mozilla and Ajaxian were an inspired choice to lead Developer Relations and I enjoyed immensely their sessions at the Sprint Open Developer conference. In all, I can't disagree with the analysts who identify Palm as an underdog, but I find myself rooting for them as enthusiastically as ever.

Update: Forgot to mention that if you want to understand what these smartphone market share reports do and don't mean, make sure you've read this (Mike Mace, Mobile Opportunity).]]> Palm webOS http://www.pikesoft.com/blog/index.php?itemid=263 Fri, 13 Nov 2009 07:40:00 -0600 <![CDATA[Drove my Chevy to the levee...]]> http://www.pikesoft.com/blog/index.php?itemid=258
He then proceeded to insult his audience's intelligence with sophistry about Sprint being worried that having an open, modern mobile Java environment running across its device portfolio would "increase fragmentation." It's hard to think of a statement that could more succinctly have told his audience that (a) he didn't have a clue about what fragmentation means, and (b) he didn't really know or care about developers very much. Mr. Oommen seems to be part of a re-ascendant Old Guard at Sprint because this is a retrenchment from the new open image that the company has been cultivating.

Their strategy up until last week—never clearly articulated, I'm quick to add—was to bring mobile Java into the smartphone era by fitting as many handsets as they could (smartphones and feature phones alike) with powerful CDC Java environments. Critically, they also planned to end the mess of fragmented static stacks that we've called "Java ME" by delivering an open services framework on the device that would free developers and users to build the software stack they needed. That framework was called Titan by Sprint, but perhaps better known to Java developers as Mobile OSGi or JSR 232 for those who follow the Java Community Process. The mobile Java developer community has been waiting years for someone to commit to the next generation of Java ME, whether in the form of mobile OSGi or MIDP 3.0, and Sprint has looked for some time like it was going to be the first to get off the fence and say "let's do it!"

The plan was strategically sound and the technology great, but anyone who has watched the halting, timid way that Sprint introduced Titan over the last few years could guess that there were folks within the company who didn't understand the strategic value themselves, still less know how to articulate the vision for developers. Mobile developers could be excused for not knowing that Titan even existed or thinking that it was just some "enterprise" technology that had no relevance to what's going on in the rest of the industry post-iPhone. The first Titan devices—the HTC Touch Pro, HTC Intrepid and Samsung HD Pro—were released by Sprint this year with no Titan fanfare whatsoever.

Part of what was weird about Titan has been that Sprint did nothing to dispel the misconception that it was more than just "a Java VM for Windows Mobile handsets." The HD Pro is a BREW device running this powerful Java middleware. And my suspicion that Sprint had gone so far as to integrate mobile OSGi into their flagship Android phone, the HTC Hero, was proven true at the conference. HTC and Google gave away hundreds of Heros at the conference and while there was no mention of Titan, there it was, beautifully integrated into the firmware. The Hero (at least the one I received) lets you add OSGi programs exactly like any native Android app, even as widgets on the home screen. I am quite sure that this won't be the case for the Heros that end users get from Sprint, now that the Titan program has been canceled.

It's bitter-sweet to have one of the few truly open and modern Java handsets knowing that I can't develop apps for other users in that environment. OSGi is an enormous enhancement to the capabilities and openness of Android. And as I mentioned in my last post, I believe that's precisely why Google most likely talked Sprint out of including it on their Android phones.

Titan was admittedly a marketing conundrum for Sprint. It actually solves too many problems plaguing mobile Java, none of which stand out from the rest as anything like a "killer feature" to any developer that hasn't lived in the mobile Java trenches for some time. I'd have to kind of sit someone down and talk to them for a while to explain why OSGi running across most of Sprint's handset portfolio was more exciting to me as a developer than the latest iPhone SDK or Android 2.0. Even reviewing my blog posts on the subject I realize how difficult it's been to convey succinctly why I am so convinced it's is a game-changer. One moment I'm talking about how excited I am to develop mobile apps and desktop apps that interoperate beautifully because they share the same architecture and components. Next I'm going on about solving the deep fragmentation of mobile Java. Then I go on about RCP, which is the optional part of Titan that enables you to create a native GUI. Then I'm talking about the cool things you can do when you have a web server running on your phone, or why being able to remotely manage your phone from the network is so important. And then I go off on how the deep problem with Java in general is the absence of a good component model (which OSGi solves) and why having one can transform the whole economics of software development. I haven't been able to come up with a simple, punchy story. At the end of the day Mobile OSGi is not a new API candy, or pastry to follow Google's metaphor; it's the whole store! I've just been the kid blathering excitedly with his nose pressed against the store front window waiting for it to open for business.

At some point I'll give some analysis of what this means for mobile Java. Suffice it to say: it's not good. But right now I've got to get back to writing more mobile Java code and try to put all that out of my mind.
]]> Mobile OSGi http://www.pikesoft.com/blog/index.php?itemid=258 Thu, 5 Nov 2009 10:08:17 -0600 <![CDATA[Has Sprint caved to Google on its open Java platform?]]> http://www.pikesoft.com/blog/index.php?itemid=256
Unfortunately, it appears that Sprint may have lost their nerve and decided to hang back with the pack after all. Looking at the agenda for the conference there is not a single session pertaining to Titan. The "big news" is that Sprint will start carrying some Google branded Android handsets, not that these handsets will run Titan in common with dozens of other devices across their portfolio. I suspect that Google may have strong-armed the carrier into scrapping the project. More on that in a moment.

First, understand why Titan running across much of Sprint's handset line (even BREW feature phones) was a brilliant plan to begin with. Titan is not a glitzy new UI layer, a powerful new API stack, a mobile cloud computing platform, or some trendy new way to consume or produce social media. But it is an enabler for all of these things and it puts developers and service providers in a highly productive relationship with each other with respect to them. Titan's profound service-orientation and remote management capabilities, coupled with a powerful VM and support for Java components that have never been available on mobile devices all combine to exhibit many of the characteristics that have made Web 2.0 such a strong ecosystem for applications. Having this common component framework extend broadly across a carrier's device portfolio as Sprint has been planning to do would make being a "Sprint developer" as opposed to an iPhone or Android or Java ME developer a surprisingly interesting option, especially once you consider what you can do with the platform.

So what can you do with Titan? I have to say, Sprint's not done a great job getting the answer across. Sometimes they've managed to make it sound like it's an enterprise application technology and had nice guys from IBM touting it for them at the booth. That's not going to convert many developers in this post-iPhone era. The truth is there are a lot of very cool things I am dying to develop (or, second best, have someone develop for me) that I can only imagine doing on a platform like Titan. Without it they would either be too much work, too costly to port across the platforms I'd want to target, involve waiting for some gatekeeper to open some API, or in some cases they'd simply not be possible at all.

Examples? Sure. Here are a few that I think about often:

Personal server apps where my mobile serves up content to my desktop or home entertainment system using whatever connection is available and convenient at the time. ProSyst has already done the DNLA media server idea and it's awesome. But what would scratch my longtime itch would be to have an always-on-me personal web that holds all my notes, appointments and reminders and integrates with device capabilities like the camera, vibrating alerts, Bluetooth, GPS. I don't want my whole life in the cloud: I want it on me, and continuously accessible from whatever screen and input device is most convenient. With Titan, I can create standard Java servlets that run in Jetty on the device and have bindings down into those device capabilities. These could be accessed through HTTP and a static IP address using whatever radio is most convenient: carrier, wifi, or Bluetooth.
Next up, a component for scripting UIs for some new machine-human interface concepts I'm working on. This would enable people who wanted to create apps using these design concepts to do so very easily and help me get traction for them. Note: Titan's OSGi framework lends itself to a more componentized way of writing apps, so my UI scripting component might work in one case with a rendering component that uses 2D graphics, in another with a component that renders a hardware-accelerated 3D visualization, and in yet another with a browser-based widget UI depending on what the phone would support. All would be implementations of the same service interface.
Next I would use Titan to develop a micropayments mechanism for monetizing apps (later selling the company for a cool billion). This component would provide simple, standard ways to implement a wide variety of payment arrangements in any app that used it. Importantly, it would enable revenues from apps developed using multiple software components and/or content sources to be shared among the developers in a way that all could be confident that the agreed terms of the rev share were being met. Since Titan provides an OSGi-based middleware through which service calls between components are made, I believe that trustable and fine-grained logging of component use should be practical in a way that is impossible on any other platform I'm aware of.
I want the components I create (not just the complete apps) to be available in an online Dev Store (hopefully using the aforementioned micropayment plugin) so I can make money building stuff that exercises my special expertise even if I'm not big enough to create all the incredible apps that need my component to fly.

I could go on, but I've done so before and frankly I'm not feeling very inspired to continue after looking at the Sprint conference agenda. Sure, some of this may be verging on pie-in-the-sky. But with some vision and the right partners, Titan puts Sprint is in a position to make all of the above possible and actually lead the next wave of mobile innovation. That's not something, I grant you, that mobile carriers are known for doing. But hey, I'm an optimist, Sprint has been acting admirably scrappy for a big-three US carrier, and they really seem to have been on the right track in this case. So pardon me for allowing myself to get some hopes up.

Now, the Sprint Android announcement is neat. Android has certain aspects of Titan's service orientation and openness, which is one reason it is attracting a lot of attention now and why it is expected to blow past iPhone in the next couple of years. But as much as I love Android, I have to say that Titan is more robust, more open, and better leverages standards that are already mature in the Java world, most importantly OSGi. In point of fact, Sprint could easily integrate Titan with Android (it's already been done) and augment Android's service orientation capabilities with those of Titan, bringing Android into the Titan family, so to speak. And this was what I most hoped to hear about from Sprint at their Open Mobile Developer conference next week. The only thing better would have been a Titan + Palm webOS announcement, but I wasn't hoping for that yet.

Instead, Titan is off the menu entirely. Probably canceled. What happened?

My best guess is that Google saw the open Titan model as a threat to their growing dominance in services to mobile apps. It makes it too easy for Yahoo or AOL (my current employer) to develop integrated app suites and open on-device APIs that bring developers and users to their services the way Google has used Android to expand it's reach. So I'm betting Google delivered Sprint an ultimatum: if you put Titan on an Android handset we will not let you use Google branding, and maybe not license you certain Google Apps. Because Sprint had not yet developed an ecosystem of competing services and apps to replace Google's and perhaps did not feel confident in their devices doing well without the Google branding, they caved. Sprint may have tried and failed to persuade Palm to put Titan on the Pre (more the pity for Palm in my opinion if that's the case) and when they started to look at their flagship devices not running their flagship middleware platform they saw the unifying aspect of Titan starting to fray. And they chickened out.

If I'm right, shame on Google for giving lip service to openness in public, while pressuring behind closed doors to stop it from occurring. And shame on Sprint for believing they needed Google's branding more than they needed to compete on openness, service and software innovation to win. If they really have abandoned Titan, they've shot themselves in the leg.
]]> Mobile OSGi http://www.pikesoft.com/blog/index.php?itemid=256 Tue, 20 Oct 2009 19:14:29 -0600 <![CDATA[Palm ups the openness ante]]> http://www.pikesoft.com/blog/index.php?itemid=244 new developer program that they announced this week, but the tech media seems to be impressed.

Rethink Wireless says that the new developer program terms "make Google's look tightly closed by comparison."

Software creators will be able to distribute applications on the web and will only have to submit to a review process if they want their software to be made available through the App Catalog, said the vendor, stealing some of the open web high ground from Google.

Palm recently hired Dion Almaer and Ben Galbraith of Ajaxian fame to head up their developer relations team. These guys know a thing or two about the power of openness and this week's announcement seems to show it.]]> Palm webOS http://www.pikesoft.com/blog/index.php?itemid=244 Fri, 9 Oct 2009 07:36:35 -0600 <![CDATA[Required info for new mobile developers]]> http://www.pikesoft.com/blog/index.php?itemid=240
Those days are gone and are unlikely to return. The reasons are well known to most of us and there's little point in rehearsing them in this blog post. If you want to be in the game, suck it up and learn what it takes now. The biggest challenge to a small company or individual developer first looking into the mobile market, or an old-school mobile dev looking to adapt to the new world: simply understanding the bewildering new platform landscape and all the hidden costs and hurdles of targeting each platform.

My good friend and Palm software veteran Justine Pratt at Creative Algorithms (run with her husband Corey) has done a great service to new entrants by producing an impressive matrix comparing all the major platforms—as well as some you probably didn't know about but should—in about 30 dimensions, both technical and market-related. Particularly helpful are the comparisons around digital signing requirements, benefits and costs, and around the various app stores: submission costs, commission rates. If you're not aware of the off-device distribution channels and which platforms they support, she covers these as well. Finally, she has provided estimates of the market size and the number of device models for each platform.

Making the right decision about what platforms to target with your application requires, in my view, some deeper intuitions about the platforms than could ever be captured by such a matrix. Some platforms are much better for certain kinds of apps than others, and you should not forget that each platform attracts different types of users. Also some platform vendors and app stores are better channel partners than others depending on their internal culture and their interest and experience in really supporting third party developers. But the information Justine has gathered is foundational and indispensable for such business decisions, and I'm surprised to say that I've not seen it all collected in one place anywhere until now. Justine is quick to call this a work in progress—as is the mobile landscape it aims to summarize. But grab the PDF off of Creative Algorithm's web site here and see if you don't agree that she's done us all a great service today.

Update: For updates on the document, follow Justine on Twitter.
]]> Mobile App Market http://www.pikesoft.com/blog/index.php?itemid=240 Wed, 30 Sep 2009 08:04:39 -0600 <![CDATA[Palm WebOS Roundup]]> http://www.pikesoft.com/blog/index.php?itemid=238

Was I right or was I right about the JavaScript presentation layer running over Java middleware? I love this architecture. If/when Palm enables developers to write services in the device middleware the webOS ecosystem will really take off.
By hitching its wagon to the rising HTML 5 star Palm is going to have less trouble supporting gaming and high-performance graphics than many expect.
I still haven't bought a Pre because the Sprint coverage near my house is so spotty. Not to worry: I put the house on the market :-)
I'm more certain than ever that webOS will soon have a desktop story to tell. I don't have the usual evidence to offer for this, just feel the stars aligning that way.
I'd have a lot more to say about this platform were it not for a legal problem than I cannot discuss. I can't even develop on webOS right now, which is supremely frustrating to me.

]]> Palm webOS http://www.pikesoft.com/blog/index.php?itemid=238 Mon, 28 Sep 2009 08:05:56 -0600 <![CDATA[Where am I?]]> http://www.pikesoft.com/blog/index.php?itemid=235
One of the few pleasant things that can come of letting your blog languish is having a few long-time readers take the time to bug you about it. Thanks, guys... you know who you are! Apparently, flattery works.

I'm always impressed with the people who manage to make clockwork blog posts every day or even every week for years on end. For reasons I'm not sure I fully understand myself I seem to go through periods of furious spouting and then stretches where I go "heads down" and disappear from the web entirely. One thing: I don't have the self-control to write short snappy posts, so if for any reason I don't feel able to sit down and write the kind of essays that scratch my peculiar blogging itch I guess I just don't write at all. Another thing: after a long hiatus there is so much to talk about that the prospect of starting again seems overwhelming.

Enough of the self-analysis. This is a technology blog, so let me get on with it while I seem to be able! Queued up for discussion: Palm webOS thoughts, the LiveScribe SDK release, and another run at the perennial question: "where is the InfoPad?"]]> General http://www.pikesoft.com/blog/index.php?itemid=235 Sun, 27 Sep 2009 14:55:16 -0600 <![CDATA[What's the next Java GUI?]]> http://www.pikesoft.com/blog/index.php?itemid=228 Wayne Parrot thinks it's going to be HTML5. His work on WebKit for SWT aims to prove it:

We have implemented a bidirectional bridge that allows you to implement JS objects in Java and to interact with JS objects from Java. This feature has turned out to be very useful as we are leveraging the power of HTML5 technologies in a much more dramatic and efficient manner from Java now. This is a dev strategy that I have wanted to leverage for sometime. I'm so impressed by what is possible that I'll make a controversial claim that if you are a Java UI developer and are not paying attention to the advances in web UI technology then prepare yourself to be blown away in a very short order by much more capable and productive UI developers that understand how to use new killer web UI features on the desktop.

WebKit's growing dominance in the mobile space (iPhone, Android, S60 and now Palm webOS) as well as the desktop make this a pretty intriguing UI option for Java developers—more so than JavaFX, perhaps. I like JavaFX script, but it wasn't the first dynamic scripting language specifically designed to complement Java for the purpose of developing RIAs. That was JavaScript, which already has great mindshare and energy that shows no sign of flagging. One can't help but wonder about JavaFX while the very future of Sun itself seems so uncertain.

Speaking of RIA's, a call-out to Jo Ritter for his recent comment on RMAs—Rich MobileNet Applications. This application model, which spans mobile and the desktop by introducing the stackless Java stack, is finally hitting some mainstream handsets thanks to ProSyst and Sprint. But let's get serious: that can't possibly come to pass until there is an entry for Rich MobileNet Application in Wikipedia, guys! Get on it!]]> Mobile User Interface http://www.pikesoft.com/blog/index.php?itemid=228 Sun, 12 Apr 2009 13:21:39 -0600 <![CDATA[Keep an eye on Project Blinki]]> http://www.pikesoft.com/blog/index.php?itemid=225 Blinki project at Eclipse Foundation (formerly known as FireFly). What caught my attention:

the FireFly project will develop next-generation technologies and frameworks to support the creation of mobile web applications that look and behavior similarly to native applications and are able to interact with device services such as GPS, accelerometers and personal data.

It looks like Genuitec (of MyEclipse fame) is leading this initiative. The first thing that's they've released is an SWT browser widget that uses the WebKit rendering engine. From Wayne Parrot's blog:

The WebKit for SWT browser API provides all the basic browser use-cases that you would expect. Additionally the cool features of WebKit such as HTML5, CSS3, V8 engine, and other things are now accessible from Java.

V8 is the super-fast open source JavaScript engine that Google developed for its Chrome browser. It's worth noting that it's been optimized not just for x86 processors, but for ARM Linux. Think Android... or the Palm Pre with its webOS platform.

Last week I mentioned that Mobile OSGi (specifically the Sprint Titan platform) would be a great starting place for the open source community to create a knock-off of the Palm webOS mobile platform. Now that the bindings between a Java runtime and the WebKit HTML5 rendering engine are in place the community is quite a bit closer... and webOS isn't even in the wild yet. The beauty of the OSS version would be that developers could write code not just at the JavaScript front-end as the Mojo SDK will allow, but they could also write Java modules that run as services in the middleware tier—or even native Linux or Win32 modules encapsulated in OSGi bundles. For Palm fans who read my blog, think webOS (or something much like it) running not just on the Pre, but on the Treo Pro with Windows Mobile under the hood.

I'd like to think that developments like this will force Palm to release an SDK that opens its own middleware layer. For webOS to get the most traction in the market Palm needs to leverage the architecture's natural advantages as a service oriented mobile platform. Android's Achilles heal is the weak component model and attenuated, non-standard affordance for apps to provide services to each other (i.e. be "mashed up"). If Palm doesn't go after that weak point early in the evolution of webOS, it won't take long before others make the first move.

UPDATE: The new Blinki blog is here. Watch it.]]> Mobile OSGi http://www.pikesoft.com/blog/index.php?itemid=225 Mon, 23 Mar 2009 10:26:00 -0600