Last night I attended the monthly Mobile Monday meeting for the MOMO-NY group here in New York City. A panel was put together and the planned topic of conversation was to be focused on Smartphones, and whether all phones should be considered smart phones.
While I enjoyed the conversation, we quickly got off topic and it became more of a question and answer session for the two panelists, Samsung’s Pete Skarzynski, Senior Vice President of Strategy and Mobile Complete’s Mudassir Sheikha, VP Solutions.
Before the panel began, I got into a short conversion with someone from Slifter, a location based mobile phone product finder service. Unfortunately I didn’t take her card and don’t remember her name. A few times during the conversation I completely disagreed with her point of view. But being late in the evening after a long day of using my brain, I didn’t want to get into it. Some of the issues also came up in questions to the panel, and I want to comment on them in general.
When building a service for the mobile consumer, you have a number of decisions that you must make early on in the process. When building a location based service, you have even more issues that you must deal with.
When I entered the conversation, she was talking to my partner Gary about how Slifter was a Java app, and she used some technical terms that made him visibly take a step back. I immediately jumped in so he could recover.
She portrayed the application as a “location based” product finder service. I commented on the small market size of GPS supported phones, and how it must be tough to be promoting a product that can only be used on a small number of handsets.
With that comment, I got a laugh and the response “Oh, no, no… We deal with the carriers, not the consumers.” Since I have limited knowledge of the politics of infiltrating the actual carriers, I replied with an “Oh that must have been a difficult process.” At that point I had been imaging that they had made deals with the individual carriers, and that the carriers were providing location based data to them over some API. I had always heard that this is not something that is really possible. But hey, good for them. She said once a single carrier came one, the others were eager to go along (I’m not sure what others there are besides Sprint and Helio).
She showed us the mobile web version of the service, which I plan to do a Mobile Experience Post on later today. The idea behind the app is that you can find products in your local area, and get prices and directions to the retail location. I’ll leave my comments on the business idea for later, but what I found interesting was how she was using “location based service” as the driving factor behind the promotion of the app.
So the desicisions that I would have to make when when building this service would be two-fold.
Should it be developed as a WAP site, or an installed app?
Is it a GPS based LBS service, or can we get location data from the carriers?
I don’t know much about LBS, but one thing I do know is that I can’t simply send a message to the carrier and get even a general location of a phone. To me, putting the GPS in the phone is not the answer, unless that info can be queried from outside the phone.
When I mentioned that I though a WAP based site would be better since consumers don’t like to install apps, the response I got was how sending location based data over the web creates a privacy issue, and that it’s no big deal to use an installed app. I don’t get that, and I don’t agree with that.
Consumers don’t want to download and install apps on thei phones. As the browsers become more robust, and the wireless pipe gets bigger, the mobile web is where it will be at. Building an application that only works on phones with GPS chips, and only works on some carriers and models is not the answer. If you want to build an app that can be used by EVERYONE, then it should be mobile web based.
As far as LBS, we’re not talking about locating a phone and sending the coordinates to someone to locate you. We’re talking about the user of the phone querying our service and receiving a list of stores nearby. For an application like this, we don’t need to know the actual location of the phone. Why can’t the carriers abstract it out and give us a 1 mile radius or something? What are they waiting for? Why not just give us some information in the HTTP header of the request?
If the consumer opts in to allow a particular service to query their location, why not provide the information? What’s in the best interest of the consumer, is what the consumer wants, not what the carrier thinks they want. Also, why do we need to build GPS chips into the phones when the E911 regulations already tell us with some accuracy where the phone is?
During the Mobile Monday Q&A session, there were some questions posed at the Samsung rep about GPS and location based services. The impression I got from him was that by putting a GPS in the phone, they believe you have the opportunity to bypass the carriers, and install location based applications. But is this really the answer?
For years we have been hearing about location based apps. There are a million great ideas that can be implemented. But until that information is available, I personally would not build a business that relies on it.
We are currently working on an application that would have added value by knowing where the phone is. While discussing it with the team I made what we have to do simple and clear. Put columns in the database for lattitude and longitude, and when we can fill them in, we will!
Meanwhile by the end of the Slifter conversation, it was clear that this is a zip code based mobile web application, and that the “Carriers” that are providing LBS info possibly consist of only Sprint. Nothing on their site talks about LBS services, and when you send it to your phone, it’s simply a link to the WAP site. I’m sure they are workng hard behind the scenes with the carriers.
In the meantime, they appear to be talking the right steps to getting this service up and out there. Starting with a zip code based mobile web site is exactly how I would have done it. Build your J2ME app and put it on some phones and see where it leads, but don’t count on it being the bulk of your users. Work with the carries and make your deals if you can. I was also thinking that an SMS based lookup would be great as well. She breifly mentioned that they had a short code, and a look at the site shows that they do indeed allow you to query for products via SMS.
Best of luck to Slifter. They have some great content and it looks like they have built relationships with many retailers.
A review of the WAP site & service to follow.