Channels ▼
RSS

Open Source

Targeting Applications at New Mobile Web Standards


Dana Gardner, principal analyst at Interarbor Solutions, recently moderated a panel discussion hosted by Genuitec that focused on bringing enterprise applications effectively out to mobile devices. Joining Dana is Stephen O'Grady, founder and analyst at Redmonk, Wayne Parrott, vice president for product development at Genuitec, and David Beers, a senior wireless developer at MapQuest.


Gardner: Let's start first with Stephen. You've been following these issues for quite some time. Why have the mobile Web and mobile applications become so important now?

O'Grady: It's really for a number of different reasons. We have better wireless options than we've had in the past. Wireless pricing is more conducive to adoption.

In addition, we've seen, just within the past 12-18 months, a real revolution in terms of the adoption of applications, largely due to the success of the iPhone platform, which just a couple of days ago sold its billionth application.

The success there is again due to the environmental and contextual factors, but also the success in the design of the device itself, in which we finally have a real Web browser. In your introduction, you mentioned WebKit, which is the foundation for the browser. Obviously that's on the iPhone platform.

For the first time, users have a real Web experience, as opposed to a stripped-down, bare-bones site in terms of what they can experience via the mobile Web. We need to pair the environmental and contextual factors with the advances that we've seen in the devices themselves. They've all come together to give us a rich and deep experience that will allow us to do things that we haven't been able to do before with the devices.

Gardner: We're also seeing some economic factors, given the tough economy. When you see the success that a little game application can have and how engaging it can be, I think the enterprise bean counters say, "Wow. Why can't we bring some of our applications down to that same tier, but at a much lower price point and perhaps out to a much wider user base -- either employees or partners, or even end customers.

O'Grady: The user base is one of the important factors. Certainly, the pricing in the applications is very conducive to adoption. In other words, if it's a couple of dollars an application, as Apple has proven with its iTunes store and BlackBerry has attempted to duplicate, we're seeing real low barrier to entry price points. This will spur adoption of the individual applications themselves.

When you're an enterprise vendor or a consumer vendor looking to target a volume audience, the fact is that, there are a lot more mobile devices than there are desktops and laptops. There are mobile devices all over the planet.

You were mentioning economics. The economics are an excellent indication of one trend that we're seeing recently, with handhelds and the so-called netbook category of subnotebooks or ultra-light machines. We're seeing these devices repurposed, utilized, and leveraged in areas that we haven't seen them before.

For example, a lot of folks who might have traveled in the past and had applications like Siebel built into their laptops are now very often using those in a handheld or, in some cases, a netbook. So, economics, in terms of the application price and the volume audience that can be targeted is a big factor.

Gardner: I suppose that Metcalfe's Law kicks in to some degree. The more people on the network, the more people that can be involved in a business process, particularly in real time, the more powerful the process, and the more powerful the network.

O'Grady: You've got it.

Gardner: Let's move on to this issue about fragmentation. As Stephen pointed out, we still have many, many devices. This is by no means 1982 with MS-DOS the single platform to be concerned with. We still need to work out a great deal of fragmentation.

Let's go to David. You're a developer in the mobile tier. How does an organization like MapQuest handle this whole issue of so many choices on that endpoint?

Beers: : It's both a problem and an opportunity. From a developer's standpoint, and I am a developer, it's obviously difficult, because the amount of energy that you put in is divided across all of these different platforms. You have to make difficult decisions about developing the features you want with the resources you've got and perhaps limiting the targets that you're able to reach, as far as devices are concerned. Or, you may be faced with, partly because of resource constraints and partly because of the need to try to fit across the lowest common denominator, releasing apps that aren't as powerful or as functional as you'd like them to be in order to get that reach. That's a difficult thing.

On the positive side, fragmentation is a pejorative term that we use for differentiation. It's painful for developers, but we can't pretend that it's all a bad thing, because it's really driven by rapid innovation. A lot of the fragmentation that we see out there is because we've got these capabilities now on handsets.

So many of them have GPS, for example, which is a huge opportunity for MapQuest. We would definitely want to be able to leverage those capabilities. As Stephen was saying, part of this uptake in application usage is because the technology is getting better. So, you've got to go to where that improvement is.

Gardner: So, we have choices and tradeoffs, but we also seem to have some coalescing around a better path. Why don't we go to Wayne? Tell us how you see the improvement, now that we've identified the problematic past. How do you see things improving?

Parrott: Looking back, things have been a pretty big mess on mobile for the whole. You kicked off by talking about some of the improvements in the smarter phones and the capabilities they bring in, both higher-end horsepower on the smartphones and a much better browsing experience or engine now showing up on the iPhone-class machines. The programming model that is now available enables a whole new class of Web-type applications, which, in the past, has been reserved for native applications.

Going back to talking about native, again, the fragmentation issue pops up. As you start to move forward with the WebKit-type browsers now more prevalent on these smarter phones, it's starting to represent a more common platform that we have a choice to target our application functionality towards.

Gardner: So, perhaps this goal of being able to "write once, run once" doesn't really work, given the variety of devices. "Write once, run anywhere" doesn't work, because of the differences in the native approaches. So, we're stuck with "write many times and run many places."

It's got to be better than that, though. How do we manage and make that a bit more amenable from a technology and a business perspective? Again, I'll take that to Wayne.

Parrott: Obviously, recognizing the advances in the platform itself and being able to take advantage of the mobile Web capability of the newer iPhone class machines is something that has caught a lot of enterprises' attention. Before, they were scared off by the prospect of the cost of going native and the fragmentation issues around that.

Going back to focusing towards mobile Web and the WebKit browsers gives them the opportunity to start to look at their existing resources and their know-how, in terms of what they've been doing in the past as far as Web. They can ask, "What's the gap that I have to close, in order to repurpose and retarget my resources, my content, services toward reaching people where they are now?" More and more people are living mobile. So, what is it you have to do?

They're quickly starting to realize that the new smartphones are giving them a great new capability, and it's not that big a gap that they have to cross over in order to be able to reach users in a much more cost-effective level by focusing on the capabilities that the mobile Web gives them.

Gardner: Stephen, where do you fall on this? Do you see that the developers are going to be making the choices that winnow down these variables, or are the market, the technologies, and some elephants in the room, like Apple, going to make these standards for them?

O'Grady: In large part, developers will be making the choice, and they'll be making the choice largely based on volume. In other words, whether you're a third-party application developer or an individual developer just putting out an application on your own, you want to target the largest market.

Now, there are exceptions to that. For example, even if the BlackBerry store is much smaller, in terms of the number of users, than the Apple store, it will have a guaranteed, built-in audience simply because of BlackBerry's strength within the enterprise. Enterprise application developers might target that at the expenses of the Apple's iTunes store, but, ultimately, much of it will be determined by volume.

It's kind of a chicken and egg situation, because application volume is a function of the platform success and vice versa, but ultimately, the platforms that are successful will be determined by volume.

The difficult part here is that whether we're talking native or Web apps for the phone, it's still a fragmented market. The native clients, whether it's an Apple, a BlackBerry, or a Nokia device, are not going to be the same application. It's certainly not "write once run anywhere," even for the Web. We have different versions of WebKit being employed for the different platforms. If the Mozilla folks are successful in making Fennec a real presence alongside of WebKit in one or more of these platforms, then we'll have fragmentation even at the Web space.

So, fragmentation is going to be the status quo. That will carry into the future, but success will be determined largely by platform volume.

Gardner: Okay. So, volume is one major force in the market, but we are seeing some innovation technically, and often the best approach for productivity that feeds that volume beast ends up winning. Let's go to David. We've seen developments around HTML advances, scripting language, and open source. From your perspective as a developer, what is getting you out of bed early Monday morning to get into work, when it comes to some of these new technologies?

Beers: : I can tell this from the context of how things have evolved at MapQuest. We're a company that grew up on the Web, one of the first Web applications to hit the Internet back in 1996. It wasn't too surprising that we started on the mobile web with WAP technology, the early version of the mobile web. We've been pretty successful with that project within certain limits, but it's definitely been a least common denominator type platform, and it's been difficult to move that.

Gardner: WAP is Wireless Application Protocol, right?

Beers: : Thank you, yes, and it's been a little bit of a silo for us. In other words, you can't really take a WAP website and evolve that very easily into an iPhone-class device, as Wayne is talking about.

Gardner: How long have you been grappling with this? As you say, you were early to the Web. How early have you been to mobile? It seems that when someone is traveling, they're not stuck at a desk, and the more value you can add to them. Right?

Beers: : Mobile has been something that's been part of MapQuest right along. It comes in the nature of our business, which is getting people from A to B. So, it's intrinsically mobile oriented.

A lot of what we've been doing in the last couple of years has been developing what we've been calling native applications here. We've talked a little bit about some of the pain of that.

As to the question of HTML 5 and how this changes the picture for companies like MapQuest, we're beginning to see that these capabilities make it so that we can take technology that powers the mapquest.com website that people use on their desktop and repurpose that very quickly to provide a beautiful and powerful Ajax Web experience on modern smartphones.

We found that, considering the amount of development and energy that's gone into making our native applications, and has gone into the mobile website that we have out there right now, what it took to get a great application on the iPhone was minimal. It was very impressive.

A lot of what has made it so intriguing for us is the fact that we're doing real Ajax here on the devices. So, for the problems that have been around with Web apps, which are compounded when you're talking about a mobile network with a huge latency and everything, you really have tools to be able to handle those situations and provide a lot better user experience. It's finally starting to make sense as a Web application.

Gardner: Clearly if you peruse the Apple's App Store, as I like to do, we're seeing quite a shift. The games being promenaded first, but all of a sudden, we're seeing content providers, Web-service providers, and portal providers all coming out with their iPhone version. It doesn't seem like it was that difficult for them. Maybe it's not quite the same full set of features, but it's pretty darn compelling.

Beers: : I think so. You asked me what really gets me up in the morning. The other piece of this is, looking at that difficult tradeoff we have right now, HTML 5 seems to bring another possible answer to that tradeoff.

It's not just a mobile Web story. We see companies like Palm coming out with essentially native application environments that use those tools for the presentation layer. That brings up all kinds of very interesting and productive new models for releasing essentially a native application that has really rich access to the underlying features on the device -- things like GPS and the accelerometer. That's also a very exciting application model for companies like MapQuest to look at.

Gardner: So, as a developer, it seems that, while it could be quite difficult, the best of these worlds would be to be able to take advantage of a certain set of native functions and specifics to a handset or even a carrier, but, at the same time, leverage what you can across the Web, in terms of Web services and the ability to mash up and take advantage of some of the rich Internet application features. How do you see that hybrid possibility evolving?

Beers: : It's going to be very interesting. We're starting to see, with the Pre and webOS, the first signs that this is going to be a new way that applications will be released.

You see another example with the Sprint's Titan platform, which hasn't had a lot of attention in the media. WebKit may actually be a piece of that story that's going to make you hear a little bit more about that.

One way you can look at this, as far as where things will go, is you're starting to see phones that essentially will have two tiers on them. You're going to see developers having a choice to say, "Do I want to be operating completely in JavaScript and exercise my skills there in the WebKit environment, or do I want to have some of the application logic below that, perhaps in a Java environment, where it's essentially being a local server on the device for the presentation layer on top?"

You start to combine those things, and it allows all kinds of different components that are out there and that have been driving the innovation in the Internet to come into play on mobiles in ways that we haven't seen before.

Gardner: Stephen, do you concur with that? Do you think we're going to see the equivalent of a distributed multi-tier capability at this mobile-device endpoint?

O'Grady: Ultimately, we'll get there, and the Palm Pre is a great example, because Palm is taking a different approach to application generation. Undoubtedly, we'll see the hybridization of both Web and native features.

To some extent, we can see some signs of where this will head. Think of the iPhone and the ability of WebKit to automatically reformat due to the gyroscopic functions that are contained in the handset. A Web page can automatically resize itself if the handset is tilted one way or another. We'll see a lot more development like that, which combine the present Web applications with native abilities of the handset, and GPS probably is the most obvious example.

At present, however, the development story is still, generally speaking, one or the other. I don't think that we're there yet.

Gardner: It certainly sounds like an opportunity for the tools people. Let's take this over to Wayne at Genuitec. Coming from a Java, Enterprise, and Eclipse heritage, you're used to complexity. You're used to dealing with difficult integration problems, where developers are accessing assets and resources from a variety of different background technology sources. What do you have in mind for the tools aspect of what we've been discussing in the evolution of these mobile apps?

Parrott: Let me just echo what Stephen was talking about. We were talking about what will come in the future in terms of the hybridized, blended Web device type programming model. Where we're at right now is that it's a binary decision. It's native or Web, for the most part, and the Web model is the lowest barrier to clear in order to go native.

Before we jump in and say, "Hey, mobile Web is it," I like to take the approach that, you can pick the right tool for the right problem or the right technology for the right problem. For anybody interested in mobile web, the first thing they should do is educate themselves and learn about what's out there.

Gardner: Let me be sure I understand. So are you talking about how to take an existing Web developer and train them to transition to the mobile web, or are we talking about getting people native-ready for the mobile web, almost from a starting blocks position?

Parrott: Obviously, one of the forces driving us has been enterprise organizations that want to move to the Web. They're being driven by their own workforce, sales staff, etc. I'm not thinking so much blue-collar, but white-collar staff that's very mobile, and wants to have a high connectedness, basically they want to run their businesses through their smartphones.

What they're pushing us for is, "How do we get there from here?" They already have a lot of their own infrastructure and resources in place, but moving that to the mobile Web has been a challenge for them.

First, they need to be educated about what it takes to get there, looking it through, and evaluating their own resources. David mentioned the Ajax model, HTML 5, and the mobile Web model. It's not a static content type model. So, your traditional static Web developer needs to have some skills and awareness that it's much more functional. It's not just static data, but it's functional.

You have what we call the mobile Web programming model so that you can now build some very sophisticated functionality that you run directly in the browser. You have to be educated about what you want to run local. Do you want to serve static content or do you want to push functionalities directly to the particular smartphone device?

We're servicing both -- helping educate and provide tooling and educational services for both Web developers and traditional enterprise developers -- Java developers who are moving over, bringing their programming know-how and experience, and applying that to dynamic Web applications.

Gardner: It sounds like some path we've already been on. If you have a set of Java developers and you have a set of Web developers, how do they come together to form some sort of an alignment for the delivery of these modern applications? That shouldn't be too different when you take them out to the mobile tier. Right?

Parrott: Definitely not, but at a higher level, an organization just needs to understand, how much and what kind of functionality they actually want to push out to the mobile Web. It's really our overall strategy.

Gardner: Right. There are architectural and network considerations that are unique.

Parrott: Correct. You have to remember that you're running on wireless networks. It's not running at Wi-Fi speed necessarily. There are things you have to take into account, as you work through the total end-user experience that you're targeting and then focus on what kind of developers have the experience to build and create that type of experience and delivery for your customers.

Gardner: What about Eclipse? What are some things going on there, some projects, interesting developments and innovation? We've certainly seen a lot of interest in OSGi over the previous year or two. What is the bearing that some of those activities have on moving out to mobile development?

Parrott: I can talk very specifically to one of the projects that Genuitec is heading up. It's called Blinki. The focus with the Blinki project is to create a mobile-Web development platform. The concentration has been in two areas, both to provide frameworks for building tools that developers could then use for creating really compelling Web applications and also UI frameworks or rendering frameworks.

You can think of these as themes. If you want to build a Web application and have it have an iPhone type look and feel, it's easily possible with the HTML 5 technologies. But, your starting point is to work with an existing UI framework that can help you create that kind of end-user native experience.

So, we're working on those two aspects. That's all of part of the open source. If anybody is not aware, Eclipse is a platform for building both tools and run times, and we're focusing mainly on tooling and the UI development in terms of the Blinki project.

Gardner: Let's go over to the developer. Dave, this open-source development, I assume, is something you've been involved with, as a user, or perhaps a contributor as well. Tell me a little bit about the role that open source has in your mobile development, and then, if you're familiar with OSGi, does that hold any interest for you?

Beers: : First of all, open source is very important to us from many different directions. We're using a lot of open-source tools. In my time as a developer, I've also had a chance to contribute to a lot of open-source projects, including Eclipse, and then kind of eat my own dog food. It's hard to be a developer these days and not be enjoying a lot of the benefits and productivity that come from the existence of open source.

OSGi is a particularly interesting area for me, and I think it may be becoming more important now with Oracle's acquisition of Sun, because it's really bringing about a new component model for Java, in particular. Part of this problem of fragmentation that we're talking about has to do with the fact that we deal so often, at least in Java applications, with these static stacks. We've got these configurations. We've got profiles. We've got all these optional packages in mobile Java. OSGi presents the possibility of being able to have just the right stack for what you need and not to worry so much about whether the capabilities are there natively in the phone, because you can add them as a developer.

The idea of OSGi being a component model that's underneath, something like that WebKit layer, is an extremely powerful combination. There you've got standards at both of those layers that I was talking about. I'm very hopeful about seeing that evolve. I agree with Stephen, it's not going to happen this month, but I think we're headed that way.

Gardner: Stephen, any thoughts about it. With OSGi, of course, its heritage was in embedded. So, it's almost designed for this sort of a problem set?

O'Grady: I was about to say exactly the same thing. OSGi is eminently applicable, simply because it does offer you the componentization, to some degree, of the stack, as was just discussed. We've seen this before. Some of the mobile carriers have explored OSGi in varying degrees. We'll certainly see more of that.

The other Eclipse-related mobile story that's probably worth at least a mention is some of the Android work that's going on. There's a plug-in for Eclipse that will allow you to develop in Eclipse and towards the Android platform.

So, both on the server side with OSGi, as well as the tooling side, the client development side, with things like the Android SDK and some of the work that the folks at MyEclipse are doing, Eclipse will really have roles to play on both sides of that equation.

Gardner: Wayne, given that we've identified the mobile Web and its latest incarnations and innovations as an interesting way for the enterprise developers to move quickly to mobile, and the fact that they're getting the push for doing this from their own users, those mobile warriors, how do you get started?

If you're in this mode of training, experimenting, and getting up to speed, where do you even start on that process of going from traditional Web development to mobile Web development?

Parrott: I am going to go ahead and toot our own horn here, but at Genuitec, this is what we're specializing in. We provide a number of online resources and enterprise tools to help users target towards both their enterprise applications and also toward mobile. So, I would say, visit our site at genuitec.com/mobile/.

The other would be to educate yourself. As I mentioned earlier, there is just a wealth of resources on the Web. Genuitec will provide a book list or a bunch of book lists that you can access, read up on, and kind of educate yourself, just to understand whether you really even want to get into this field or not.

Finally, one of the things that I am really proud of is that I believe what really gets you connected is seeing and believing. When I talk to some people, not everybody has access to a smartphone. They may have seen other people with them, but they don't necessarily understand or grok it. One thing that we provide is a very simple micro WebKit browser that you can install and it can run off your desktop. You can explore and experiment with the mobile Web in a way that gives you a first-hand type of experience.

Once you're beyond that, then you have additional roadmaps, depending on the type of complexity that you want to adopt and the type of applications you're going to build, and provide tooling and expertise around that.

Gardner: Thanks to our panel. We've been joined by Stephen O'Grady, Wayne Parrott, and David Beers.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video