The mobile Internet in general, and specifically Location Based Services, haven't taken off because to date, there have not been compelling applications to drive adoption.Plain and simple.Borrowing from a bumper sticker - "No applications, No adoption.Know applications, Know adoption".There are a lot of reasons for this lack of apps, and my own history in working to develop commercial LBS illustrates this point quite well and is a good backdrop for understanding these reasons.
Although I've worked with location technologies since 1995, it wasn't until '99 that I began to explore the idea of Mobile Location-Based applications. I was working at NearMe, a startup company in upstate New York whose mission was to bring location technologies to the mainstream.We were a typical startup - light on cash but loaded with vision and innovation.As our strategy took shape, we began to focus on the emerging mobile LBS market.Wouldn't it be cool to have access to location and mapping technologies on mobile devices? Of course! Given the fact that when you are mobile, you really want access to information around you, you want to use location like a filter.You don't want to search a full concert database on your tiny mobile device, you just want to see the relevant events occurring tonight that are close by to where your sitting having dinner right now.The element of location as criteria for search becomes more important when you are not tethered to your desk.So with bright eyes we dug in, and began to adapt our technology and applications for mobile devices.Our enthusiasm for mobility would soon be dampened by the harsh realities that all developers in this space were facing.
We had developed a very sophisticated API optimized for Location Based Services.It provided maps, driving directions, geocoding and other location information programmatically via HTTP and XML.As we hosted the necessary server infrastructure, application developers downstream would be freed up from the intricacies of GIS and could focus immediately on their applications. In many ways, it was a lot like today's Microsoft MapPoint Web Service, a product I not so coincidentally work on at present, but pre-dated the adoption of standards like SOAP and WSDL which MapPoint strictly adheres to today.
Once we had our API in place, it was time to get on to actually apply it and build applications for mobility.This is when we started to run into some pretty steep barriers.Each on its own was quite a burden, and in concert they created a completely hostile environment.The lesson we soon learned is that there were a lot more pieces to the LBS application puzzle than just the GIS components that we were focusing on.This was our introduction to the complexity of the wireless ecosystem, and the importance of all of the other elements beyond mapping in the creation of compelling LBS applications!
The good news is that today, each of these problems have been independently solved. Let's look at these historic barriers to the wide adoption of LBS, and break them down one by one to understand why they aren't a burden any longer.
1.Devices were terrible.
2.Development tools were awful.
3.Too many markup languages and related 'standards'.
4.GIS solutions were difficult and expensive.
5.No standard Operating System and Libraries.
6.Difficult to acquire real-time location for a device.
Barrier #1 - Devices Were Terrible
The most common phones of the past that had any kind of internet support
featured monochrome displays of four 15 character lines of text.Highly
advanced models added the ability to display 2 bitplane grayscale images.
As I frequently had to demo applications publicly, I holstered the granddaddy
of them all - the Neo 1000 - sized like a brick and looking a lot like
a prop from Battlestar Galactica, it featured a massive 11 line display.
And these devices only had WML/HDML web browsers that were limited to surfing
the handful of web sites that actually supported these markup languages.
HTML sites, which make up the vast majority of the WWW, were off limits.
It's no wonder the mobile internet never took off when you consider the
gap between the desktop experience we were all accustomed to and what was
being pushed at us as the mobile alternative.It was a lot like going back
to a VT-100 terminal after using a state of the art multimedia PC, and
consumers weren't buying it.
Pocket PC Phone Edition Smart Phone 2002
Times are changing, and FAST! Today's advanced mobile phones feature graphical displays, expandable memory, and even cameras.Oh, you can talk on them too.For example, phones running Microsoft's® Windows CE Operating system such as Pocket PC Phone edition devices and the new Smart Phone 2002, feature full color, generously sized displays, stereo sound, animation, beefy processors, SD expansion slots and more features you expect on a real computer.With capabilities like this you can run REAL applications. Internet Explorer and Windows Media Player are among my favorites.IE lets me surf the web - the SAME web that I surf on my desktop machine, not just a handful of sites built for WAP.MSN's Maps and Directions portal has bailed me out a number of times on my Pocket PC Phone.Media Player lets me take my MP3's and WMA's with me - no need to carry a separate digital audio player.Plus Media Player handles video nicely as well! Word, Outlook, Excel...these are the apps we depend on each day, and now I can have them with me all the time.Before my current trip to CTIA, one of my associates forwarded me a Word document detailing all of my appointments for the week. I simply dragged it onto my Pocket PC Phone, and now I have instant access to it anytime right from my phone!
Consumers finally have a good reason to upgrade from their non internet or WAP only devices to a modern phone capable of running compelling applications, including LBS applications.
BARRIER #2 - Development Tools Were Awful!
At NearMe, one of our first objectives was to select a development
environment for the team.This was doubly difficult as we were still living
at the edge of the internet bubble - what was once just an IDE was now
offering features like "Complete mobile lifestyle management".And the
glut of .com's with deep wallets didn't help either - we actually evaluated
an application server from Apple that sold for 25,000 dollars per server.
Well beyond our startup budget.Today it sells for 695 dollars.There was
a lot to sift through.
As we evaluated each offering, we found ourselves having to learn new technologies everywhere.It was becoming clear that there were no standards. We had to adhere to strict and restrictive programming models.I haven't seen so many products exposing me directly to Model/View/Controller since... since...since NEVER now that I think about it! And touting this like it was a feature.And EVERYONE seemed to have their own markup language, to wrap all other markup languages, which of course I was exposed directly to and needed to learn.
There was nothing on the market to allow me to visually develop an application for mobile devices, as I had done for years in building desktop and web applications.I just wanted to drag and drop some UI widgets onto a form, write my business logic, and run it.Was this asking a lot? I guess it was.It became clear that in order to build mobile applications, one needed to become an expert in a niche domain.Very few developers could invest the time and resources in coming up to speed as a mobile developer, so very few applications were written for the new mobile internet.
The latest version of Microsoft's integrated development environment, Visual Studio .NET 2003, is now shipping with support for Smart Devices as well as legacy browser based devices.Building a mobile application is now no different than building a desktop or Web application.Seven Million Windows developers are now Mobile application developers.Stop to let that sink in.Anyone in your organization who has ever built a Visual Basic application with Visual Studio now has all of the skills they need to immediately be productive as a mobile application developer.Same languages, same debugger, same RAD experience.This is due in large part to a pair of spiffy plugin's for Visual Studio .NET 2002 now being included right out of the box in VS 2003 - ASP .NET Mobile Controls (formerly Microsoft Mobile Internet Toolkit) and Smart Device Controls (Formerly SDE). We'll talk more about the Mobile Controls for browser based phones in the next section on the flood of Markup Languages.
Smart Device Controls allow developers to target rich devices like Pocket PC Phone and Smart Phones.Again, its drag, drop and code, same as it ever was.But now I'm writing code that can take advantage of the richness of this new breed of mobile device.I've got local storage at my disposal. Richer UI elements like tabbed dialogs.Comprehensive libraries of code. Code Completion.In short, everything developers are accustomed to, now for mobile application development.
In part two, we'll continue discussing more barriers that have held up mobile LBS applications.
Author's Note: Thanks to Joe Francica for this opportunity to contribute to Directions Magazine on the subject of Location Based Services on a regular basis.How regularly depends on my schedule and industry news, but with the mobile LBS snowball growing rapidly, I hope to be able to make this a monthly feature.