My Location: Google is Not Always Watching Me over the Airwaves

Google surprised us again this week with yet another bold announcement. With My Location Mobile Maps will be able to tell you where you are. But fear not, big-brother or stalker phoebes. In contrast to Google’s free WiFi service, Mobile Maps has made the very intelligent decision to not bother to know where you are. All My Location knows is an arbitrary identification number (not your MDN, which is your seven digit phone number) that is associated with your mobile device.

The challenge for operators is that whether their LBS platforms provide anonymity or not, it will be difficult for them to shake off the perception that they do not. The network knows the MDN associated with the device; the MDN is associated with the account. The account not only holds information about the identity of the subscriber, but even other facts such as mailing address and credit card number.

Google’s announcement also sparked new discussions about how the carriers ought to release LBS APIs that application developers can take advantage of. This only speaks for the U.S. operators’ inability to effectively educate the media. After all, as I have posted before, some operators do have open (or semi-open, depending on whether economics are part of the definition) APIs. So here is a quick snapshot of carrier supported LBS APIs for developers:

Verizon Wireless
Sprint
ATT

Right now Mobile Maps is limited to smart devices such as Blackberry, Windows Mobile, and Symbian. However, in America it is feature phones that occupy the largest footprint today. So why doesn’t Google take advantage of the semi-open API’s provided by operators? Hmm… perhaps they will soon… Or perhaps the economics get a little murky since operators impose revenue share models on subscriptions to on-deck applications. To make things even more complicated, with Brew operators a third party is also involved: Qualcomm. In contrast, Google’s model is based on advertising, which means giving the service away for free. So perhaps with a little creativity, and suppression of egos, all players could come to friendly terms that would ultimately benefit us, the end users.

Regardless of how this will pan out, the truth is Google’s is definitely a good long term strategy; eventually most, if not all, devices will be open smart devices.

I end this post with the real question that I have: will Google make Mobile Maps open like its online counterpart some day?

(Here is a good interview with the Google Maps product manager, Steve Lee).

Oh, It’s a Wonderful and Predictable World

Why is Om wasting his analytical mind and his words on his post today? The reasons behind the news from Verizon Wireless today can be simply narrowed to the first once he mentions: It’s all about the upcoming spectrum auction. And it is also about Android… Oh, which by the way is also all about the upcoming spectrum auction…

So it is only a matter of time before the rest of the herd follows. The big question for me is which carrier will embrace Android? Just for fun, my money goes to T-Mobile.

Finally, as soon as I figure out how exactly Verizon’s open platform will work and how it will benefit (or hurt – always a possibility) the industry, I will post some more….

Android… New Player, Same Old Song

Attention mobile application developers: the news is that you will now have yet another development platform to deal with. But why should this be a real issue to you anyway? Your present strategy is, and will probably continue to be to maximize your porting investments by focusing on the largest footprint available anyway. If you're looking for VC investment, however, it might wow some of your prospective investors to showcase your app on a a) an iphone and b) android.

It is not like I want to discount the effort undertaken by Google. It will certainly shake things up. And I still believe that few players have the vision and ability to transform the mobile industry, and Google is certainly at the top of my list. I have no doubt about the superiority of the technology either – I’d be scared if I were Windows Mobile, for example. Most importantly, I don’t think there is any other brand in the industry that could have the power to make their platform the de facto standard someday in the future as much as Google. Five years out, I expect Android to comprise a large share of handsets. But until then it is business as usual for application developers.

Seriously, can anybody out there seriously and sincerely focus on application developers’ needs today for once?

Why is it that everyone promising an open mobile platform these days seems to have a hidden – or not so hidden, such as the intent to bid for some coveted spectrum – agenda?

>play's "Beyond Mobile 2.0"

I attended the UC Berkeley Digital Media and Entertainment >play Conference this past Saturday. The mobile panel focused around a somewhat vague, yet interesting topic: “Beyond Mobile 2.0”. The panel consisted of Steve Lee, Product Manager at Google Mobile, Tico Ballagas from Nokia, Jeff Sellinger, VP of Mobile at CBS, Rick Robinson, VP Products and Services at XOHM/Sprint, Evan Tana, Director of Product Marketing at Loopt, and moderated by Mike Rowehl of Sillicon Valley’s Mobile Monday, and AdMob’s tech dude. Some of the predominant themes were:

Location:

The most heard theme was: LBS is the key to providing targeted content.

According to Rick Robinson, the biggest problem with adoption today is the lack of privacy. However, I would agree with Evan’s response that the privacy control tools are in place today, so the biggest challenge is education (of consumers about these controls).

On Future of paid on deck applications:

According to Steve and Evan, both Google and Loopt get the whole ‘playing with carriers’ deal today, but believe the market is slowly moving to a more open environment. Nokia truly believes this, which was clear by Tico’s constant reminder that Nokia is evolving into a services company. Proof of this is the company’s launch of Ovi and late acquisitions (Navteq, Enpocket, Twango, and Loudeye). Rick Robinson from Xohm went as far as saying that "Xohm will tear down this wall..." (BIG statement!), but will still provide an on-deck expericence that is customized for the device.

Interoperability of different technologies:

The best description of what a rich end user experience might be was Jeff Sellinger’s. This would call for an interactive behavior between the different applications that exist on the mobile device. Jeff said it would be great to be able to tie SMS/MMS with WAP and Location. I would add streaming video and interactive gaming to this fabulous equation.

Limitations in the U.S.:

* Limited MMS support by U.S. carriers was the top item

* Absence of unlimited data plans, as in Europe, was mentioned repeatedly as a roadblock for user adoption

* Pervasive broadband (both availability and adoption) was mentioned a few times as an issue
Device fragmentation, specifically with browsers, was also mentioned as "old" but never ending "news"

Consumers should not have to pay

As a follow up to my previous post, here is a good example of how working with U.S. carriers to develop new economic models can create opportunities for growth in the mobile econsystem.

mBlox, Inc. is making inroads with U.S. carriers to make SMS free for end consumers. Why would carriers care to lend an ear to this seemingly ludicrous proposal? And who will pay for these messages?

Today when you receive an alert from your favorite Web application, such as Twitter, your carrier collects money from you for the delivery of the message. On the other hand, your carrier does NOT charge a fee to the aggregator who delivered the message to it, nor to Twitter for delivering you your message.

mBlox’ proposition is that by removing the charge to the end user will drive more user adoption of messaging applications. In other parts of the world the model has been proven to work better for the players in the ecosystem, beginning with end consumers. In Europe the amount of traffic for simple mobile terminated messages by far exceeds that of premium content (e.g., ringtones, wall papers).

The most interesting part of the proposition is that the carriers would receive a bigger payout for each individual message. This is due to the higher willingness to pay that exists in specialized services and applications, where the ability to send a message to an end user signifies a cost saving. Examples are financial institutions and brands, which otherwise have to invest significantly to reach consumers through other means; and which, presumably, should be willing to pay for the ability to make messages received by end users feel less intrusive.

Quit Complaining

I get sick and tired of Web developers complaining about how closed they are finding the mobile space. I find the complaints ignorant and whiny. The arguments for the need for an open mobile ecosystem are not only shallow, but also obviously selfish and poorly disguised as idealism and altruism.

It is not that I do not believe in openness and opportunity for all. It is not like I do not realize that the consumer is who will benefit the most from access to a broader, more compelling, more discoverable, and price competitive range of services and applications. It is not like I do not perceive the potential that mobile has of surpassing the Internet in terms of availability and profitability of services and applications (in terms of reach, mobile has long gone surpassed the Web).

My dilemma is that as a capitalist I strongly believe that the parties who have invested heftily in laying down and maintaining infrastructure to connect the world are entitled to protect their investment to capture as much of the returns as possible. Carriers are also entitled to protect their physical assets from abuse, malice, and tear and wear. It is, however, also investors’ entitlement, if not their duty, to also maximize their ROI.

The problem I see in the carrier ecosystem is that by being so over protective and paranoid of opening the flood gates carriers may be selling themselves short. One major downfall of the walled garden is the stifled user adoption.

My call to action then to the Web developer community is to stop complaining. Instead, get your creativity juices flowing and think of ways to turn the situation around. It is time to develop innovative ways to show carriers ways to maximize their returns by opening up their platforms, and forcing OEM’s towards a less fragmented device platform environment. Successful models will be those in which all carriers, OEMs, developers, and end-consumers alike will reap benefits.

Google is Watching Me Over the Airwaves

I am logged onto Google WiFi in Mountain View right now. First time I have ever used Google's free WiFi. I did not realize that I would have to log in with my Google username. It is pretty scary to realize that Google knows where I happen to be at this very moment... Or is it?

Google Navigator

I pay $4.99 per month for Verizon Wireless's VZNavigator. VZNavigator is a Brew based LBS applications that gives turn by turn directions, local directories, maps. VZNavigator has gotten me out of many a hairy situation. The past few times I have used the application, however, I get a sporadic error telling me it is unnable to retrieve the directions I have requested.

When this happened to me today, I decided to try Google's SMS directions. I sent "directions from (my work address) to (graphing social paterns conference address)" to the short code 46645 (GOOGL). Within 30 seconds I received three messages including the turn by turn directions. So while I didn't have a friendly voice dictating to me where to turn, nor access to a map, I was able to get to my destination just fine. I must admit it is pretty tempting to want to save myself $5/month going forward... Especially when it takes almost the same amount of time and effort to type the directions request onto the SMS message, than to navigate through the device's convoluted menus to get to VZNavigator.

One More Sequel to My Mobile Widget Ranting

As a follow up to my previous post about taking Web applications Mobile...

Yes, there's a lot of appeal to the word 'widgets' these days. And widgets are fantastic for the Web. But when it comes to mobile, whether the widgets are client-based or Web-based, they can become rather difficult to implement, and impossible to port or support across many types of devices.

Few words to the wise: stay away from mobile widgets!

From Web to Mobile, One Step at a Time

My advice to Web developers wanting to penetrate the world of Mobility is to take it in strides. Forget about dealing with the plethora of on-device platforms (from 5+ different Operating Systems, to the 3 or so middleware platforms, to the 1000's of resolution and other iterations). WAP and Mobile Web have their problems. The learning curve is steep and quite costly.

The simplest and quickest way to get your feet wet in mobile is through SMS. Through services like TextMarks or Mozes you will be up and running in no time without the need to integrate with any carrier or aggregator. But SMS will not allow you to automatically port your application to a mobile dimension. Although SMS will only allow your application to extend some functionality to the mobile device it will achieve two things:

1) It will help you learn more about your users' interactions with their mobile devices with respect to your app. This is valuable information to have before taking the full plunge and investing significantly in other mobile platforms.

2) In many cases and depending on your application it will help drive stickiness by allowing you to ping users when they are away from their PC

The best example I can think of is Facebook. They started off by supporting a few alerts to users' mobile phones. Today they host a plethora of alerts and functionality around these alerts. Facebook even allows (much like blogger) to post pictures from a mobile device. Other excellent examples are Twitter and Truemors.

Redefining the “Cloud” (i.e., add wireless)? Too early to tell

So what of the news that the FCC will auction new spectrum under the condition that those who venture into the challenging space of building, maintaining and operating a network keep the last mile open to any device?

Well, for starters, if it comes to fruition this ruling could have a major impact on the wireless industry: more consumer power, less restrictions on proliferation of applications, less device fragmentation with better devices… and on and on. At last, a stride towards an open environment has been taken. Great.

However, while this ruling could result in something bigger than the Telecom Act of ’96, today it is still too early to tell what the real outcome will be. Fully aware of the threat that this poses to the them, the incumbent operators have already been busy at work in Washington for some time, and will continue to be until the fat lady sings. The lobbying (they have been at it since before Sergei and Larry were born) and staying power of the operators is not something to be underestimated.

Finally, even if this ruling were to be successfully implemented by the FCC, the incumbents not only have the deep pockets to compete in the bidding war with Google and co., or whomever. They will fight to the nail and teeth for they have much more to lose. They might even give Google a little bit of its own medicine: pay ludicrous amounts of money for the spectrum and do nothing with it simply to keep the competion out.

Access is the problem, but Yahoo Go may be on to something

The most important determinant of user adoption of applications is access. It is a noble (and potentially very profitable) effort for companies to add more applications platforms to increase the number of applications to the mobile device. Yet, the pending need is not the number of applications. There are thousands of BREW and J2MEE aggregate applications. Handango currently sells over 7000 applications for the Symbian platform alone.

Yet the issue of access to those applications that remains unsolved for the most part. Access today remains a major roadblock for consumer adoption and stickiness. I synthesize access into three areas:

Discovery. Given the abundance of mobile applications out there users find themselves overwhelmed. Even when a user has an idea of an application he/she is interested in using, finding it in the operators’ or storefront catalogs can be quite the ordeal. Not to mention when it is done from the device itself.

Adoption. Most existing platforms have actually made the process of trying out and signing up for applications significantly simple. An application download will typically involve a series of authentication and provisioning processes. Most of these processes combined take place in a matter of seconds and are usually invisible to users.

Stickiness is another problem area. Mobile phones have a very limited user interface that has resulted in cumbersome navigation and layers and sub-layers of menus. Frankly, it is easy for consumers to forget about an application they downloaded in the past along with many others. It is easier to stick to the basic applications, like WAP or SMS, which are closely integrated with the physical user interface.

On this front, Yahoo is on to something with Yahoo! Go. It brings potentially thousands of applications to the consumer in a self-contained, seamless and user-friendly experience. The Yahoo Go experience is client based, so reaching a wide device footprint will be a never-ending challenge for Yahoo. However, since the downloading can be initiated from the Web, and through a SMS containing a URL, getting the client to supported devices will be easy for the consumer. The discovery of new applications that are part of the Yahoo! Go experience has been made so simple, thanks to the Yahoo Go user interface that allows for extremely simple navigation. As the number of applications, or widgets as Yahoo calls them increases, however, discovery will become increasingly more challenging. Hopefully Yahoo will add an effective Search and/or Recommendations engine to future versions of Yahoo Go. Yahoo will still have to address the problem of stickiness. Depending on the device, the Yahoo! Go client may be added to the device’s layers and layers of applications. Alerts (opted-in by the user, of course) may be a simple way, for example, for Yahoo to remind users to shift the Mobile Web paradigm to Yahoo Go on an on going fashion. The other, even better and very possible alternative, is the Yahoo Phone through direct relationships with OEM's for device-embedded Yahoo Go.

Who cares as long as it's sexy

I have been interviewing as many fortunate owners of the iPhone as I could come in contact with. What I have observed is either a severe case of herd-mentality denial or simply a slap in the face for the wireless industry that has been decades in the making.

Among many surprises about the iPhone, one that stood out to me the most is that the iPhone does not support picture messaging. The alternative functionality of sending pictures, or anything else for that matter, as email attachments is not supported either. The average iPhone user's response to this was that he/she had no need for pictures on a phone.

A certain iPhone user also described the Internet browsing experience over the EDGE network as “painful”. Another user commented that he would not even attempt to watch a streaming video outside of WiFi, but then added that he “hates YouTube anyway” (he and the rest of the world, right?). An eager user insisted, instead, that streaming video over EDGE was even faster than doing it from his computer over high speed Internet – obviously in denial!!

Furthermore, while the phone allows music side-loading only (no different than the iPod and not to mention a waste of the benefits of wireless connectivity and money left on the table from consumers' higher willingness to pay to purchase songs while on the go), the iPhone has been praised in the bloggsphere for having the potential to revolutionize the music industry. More denial.

Openness? Don’t even get me started. Besides Safari, nothing else in the device is open to developers: no keypad, no LBS, no codecs, no SMS, no J2MEE/BREW equivalent...

While the phone’s revolutionary touch-screen keypad provides for more and much needed screen real estate, it made it very difficult for me to enter text (my fingers are pretty small, mind you). That was acceptable to the owner of this particular iPhone because I am a newbie, after all, and I need to practice. This same user had been practicing for one week and yet kept fat fingering every other letter.

In terms of memory space, no one has denied that it is definitely a downgrade from the Video iPod. iPhone owners’ response?... They do not need the memory space for video because they can stream video (when sitting in front of their computer at an Internet café, of course).

One area where eager iPhone adopters and I can certainly meet is the device’s extremely slick design. It is thin, light, has a relatively large screen, and aesthetically pleasing rounded corners. The UI is a beauty with its large bright colored icons on a dark background. Unlike the iPod, the phone will actually resist the physical abuse of the average mobile user.

So what could this mean to the rest of the mobile industry? For years thousands of competent minds have been trying to second guess what customers really wanted out of their phones. After voice and SMS, we brought users access to information over data networks. It turned out that what we provided (WAP 1.X) was not the Web, so we gave them WAP 2.0 with images, colors, fonts, tables. It was still not enough. With more powerful devices, we were able to provide Internet browsers, but since the limited machines cannot bear to process much of the content that is out there today, this is still not good enough. So we added more bells and whistles (cameras, MMS, LBS. Video, Music)… Not enough because the networks were too slow? Answer: 3G networks. But no. Not enough.

So, could it be that over the course of 20+ years working to improve the mobile device the so-called experts were simply heading in the absolute wrong direction? Could it be that at the end of the day, despite of anything they said, consumers did not really want feature-rich empowering mobility tools after all? Could it be that after all, all the consumer really wants is an overpriced sexy-looking gadget that shouts social status to the world? Hopefully not (and I doubt it), but only time will tell…

For the time being I am holding on to my $600… and holding out for the iPhone 2.0... perhaps.

Off-Carrier LBS platform

Hats off to the folks over at Yahoo! Research Berkeley for developing something truly disruptive!

The Yahoo! Research Berkeley team has come up with an open LBS platform that allows the community to generate and openly obtain the location information. This is in contrast to other LBS platforms, most of which are owned by carriers.

“Fire Eagle”, code name for YRB’s open LBS platform, allows location-based applications to connect to it and 1) post end-users’ location information, and/or 2) get end-users’ location information. Here is an example of how it works: Suppose you, as a developer, come up with the “Totally Rad” Social Networking location-based application and connect to “Fire Eagle” using its soon to be made public API. Now, let’s say one of your users also uses Zone Tag. While out and about, this user takes a picture, tags it, and uploads it to Zone Tag. Zone Tag will determine the user’s location by means of its Cell Site ID database. Zone Tag will then post the user’s location information to the “Fire Eagle” platform. Next, the end-user will log in to the Totally Rad Social Networking application. The Totally Rad application will get the user’s location information from Fire Eagle. With this information Totally Rad will be able to serve your end-users with location information about their friends or love interests, or even highly targeted ads.

So what about the security of users’ privacy?

Privacy has always been the number one concern with location-based services and continues to be. YRB promises the platform will be armed with privacy features. First, the location history of users will not be maintained. Fire Eagle will only cache each user’s latest posted location information. Second, users will be able to manage through a Web UI which applications should or should not have access to their location information. I would add to that the ability to specify windows of time, ability to turn off the disclosure on information from the device, etc.

How good will the information be?

Unlike a carrier supported LBS application, a user’s Latitude and Longitude may not always be available.

What might the carriers say/do?

They may not do anything until a user’s location information is compromised and used in a bad way… or until they see that this significantly eats into their revenues. For now, though, this is probably will be just noise to them.

What’s Fire Eagle’s status?

Currently “Fire Eagle” is about to go through alpha testing. Enter your email address on the Fire Eagle Website to be notified when it becomes open to the public.

Text May Become the New Voicemail... Someday

I am currently test driving some of the new messaging applications that are out there. CallWave Mobile turns your voice messages into text and delives them to your phone in the form of an SMS message, and to your email. It also lets you check your voicemail from your desktop via the Web. I have found the value proposition of the application to be very enticing: it keeps me from having to dial my voicemail, entering my passoword and listening to voicemails one by one. Two minor flaws I found though: 1) Voice to Text conversion is far from perfect (surprise, surprise), so many times the text SMS or emails are unintelligible so I have to check the voicemail anyway, and 2) the voice messages do not get stored in my carrier provided voice mail, which I am very used to checking. Instead, in order to check my voice messages from my phone, I have to call CallWave's voice message number - only a matter of adding the number to my speed dial, yes, but still not quite perfect.

Keeping the Google Bus Mobile

I heard a rumor that Google’s approach for providing Internet access to its employees while they ride the commuter shuttle using WiFi was turning many of the indulgence accustomed and productive workers into disgruntled commuters. Instead of using WiFi, Google is rumored to want to supply its soon to be no-longer-disgruntled commuters with 1xEvDO cards. If the rumor is true, will this be the real outcome???

EvDO is absolutely fabulous because it relieves you from the infamous ‘hot spot’ dependency and very effectively delivers on the promise of “Internet Everywhere”. As with all wireless access technologies, however, user satisfaction highly depends on coverage. EvDO, whether it is provided by the more experienced provider Verizon Wireless or the newbie Sprint, is likely to have its “gray spots”. These are spots where EvDO may not be present and one may be temporarily switched to 1xRTT. This is the CDMA technology that preceded EvDO and which only transmits at about 128Kbps instead of over 1Mbps.

The other catch is capacity. When 20+ concurrent users get on EvDO cards all using the same bearer (part of the cell site that provides the connectivity to the rest of the network) they will probably find the bandwidth to be much less than the expected 1.4Mbps.

Throw economics into the mix and the whole thing just falls apart. For the average consumer the price of EvDO is on average $80+ for the card plus $50 to $60 per month for the service (granted, Google can probably pull off a mega-deal with a carrier). Multiply this by the 150 or more Google commuters, and compare the numbers to using instead just a few EvDO lines connected to WiFi routers that can service the 20+ employees at a time.

At the end of the day, however, EvDO is a great investment for improving employee productivity. For example, another rumor has it that at Google “Sunday is the new Monday”. Therefore, for Google the return on investment on EvDO cards for its employees may certainly go a lot further than the Google Bus.

A Few Thoughts on Mobile Widgets

I have heard of widgets within the context of mobile when referring to various types of applications. Because access (i.e., discovery, availability, ongoing ease of use on the device) is so much more critical in the mobile device the various types of Mobile Widgets should be properly defined and separated:

1) Mobile Web Widgets. These are widgets that are accessed through a Web browser on a phone. The challenges when developing these widgets are similar to those of developing Web widgets – i.e., multi-browser support. Add to that, however, multi-device browser implementation support. There is also the walled-garden that is still part of the browsing experience in most of the feature phones. Not to mention that outside of 1xEvDO the browsing experience is still very slow. Despite of these challenges, this is low hanging fruit with potential to shift part of the carriers’ WAP paradigm. Unfortunately, I have yet to find any companies focusing on this space. If you know of any, please send them my way…

2) PC-like widgets that can be downloaded to mobile devices and that can either run in stand-alone mode or require connectivity to operate, I call Downloadable Mobile Applications. This is simply what they are. These are not any different than a J2ME or Brew game, with the exception that these are being developed by new comers trying to bypass the carriers. While buzz marketing is certainly appreciated, it is important to take into consideration the implications associated with these downloadable applications. One problem with downloadable applications is discovery. How are users going to find these applications? Buried in a Web site? Or even worse, buried in a Mobile Web site? What about devices that prevent downloads to occur from a Web session? Or in a carrier supported application catalog (still buried) where the carrier demands to get paid for it? Another problem is downloading; even with optimal bandwidth, installation could be a confusing to a user and will likely vary per device. Also, a few platforms accommodate applications that reside outside of the walled garden. Take for instance Plusmo, which claims to send a text to your phone after you select your widget of choice. Once you receive the SMS, bam! you’ll be all set! – Sure thing, IF, and perhaps, you have a non-carrier-blocked Smartphone.

The bottom line is to use caution when thinking about designing applications that will require users to a) find them, b) figure out a way to download them c) deal with latency associated with GPRS and 1xRTT, and d) deal with the possibility the mobile platform may not accept the application or may require multiple attempts to download/install (well, other than perhaps… the iphone…). Remember: the mobile world is not like the computer world – it is by far more fragmented in terms of operating systems, different devices with the same OS can behave very differently, the systems are often closely guarded by operators, etc. Do not get caught off guard and make sure to develop with a clear strategy in mind.

For a vast set of examples of these visit Widsets, and Webwag.

3) Web Mobility Widgets (if anyone has a catchier term, please comment) allow Web applications to extend their functionality to mobile devices. Many of these, especially SMS messaging widgets, are showing great promise. Take 3Jam, oTxt by Owdigets, or Textdrop’s widget for MySpace, to name a few. These enjoy the viral, ease of use, and simplicity characteristics of widgets, while tapping into the mobile space in a way that even carriers can welcome their expansion through the Web.

4) PC Mobility Widgets are just like Web Mobility Widgets in that they interact with mobile devices. For the time being, the ones I’ve seen are limited to SMS Messaging whether it is a stand-alone applications or extensions to other applications such as an Instant Messenger or Email client. Great examples are: CallWave’s widget that allows users to listen to their voice mail from their desktop, or Clickatell’s Messenger Pro, which allows users to send/receive text messages directly from their desktop. These are likely to be less popular outside of the Enterprise due to the need to download and install the widget on one’s your computer. An interesting spin off these is SMSalias’ computer browser extension, which also requires downloading/installation.

The Defective Phone

Scene 1: I wake up to my Motorola Q displaying nothing but a blank screen. The phone cannot turn on or off.

Scene 2: I spend 1/2 hour with my carrier's technical support. We manage to get the phone on Flash Mode. The agent instructs me to install Wireless Sync on my PC, and then download the SW Upgrade application from Motorola and also install it on my PC. I hang up... so far so good

Scene 3: I spend 1 hour trying to get my PC to recognize my Phone through the USB cable. I unistall/reinstall Wireless Sync twice. I give up and call tech support again.

Scene 4: Tech support can't help. They say the phone has to be completely on for Wireless Sync to detect it (duh)... They transfer me to Motorola tech support.

Scene 5: Agent asks me to replace the battery - the PC all of a sudden recognizes the phone! Begin flashing process... It stalls once... twice... three times... I finally ask the agent, what is the contingency plan here? He responds: "Uninstall Wireless Syn and SW Upgrade application; download them again and reinstall them... and IF that doesn't work... then it means YOUR PHONE IS DEFECTIVE"... hmm...

I'd like to add that I absolutely love the Q and that my overall experience with tech support wasn't all that bad. They were very nice, patient, and genuinely tried to help me. At the end of the day, I did as they agent said and for some miraculous act of who knows what, I was able to reflash my phone.

By the way, what do you think about the Motorola Q ?:

Technology Blogs on RateItAll

Welcome back Russ! (and mobilebuzz)

This being my first post in a while, I thought I would commemorate the occasion with a welcome to a fellow mobilite, Russell Beattie, who is back on the scene again too.

I attended last month’s Silicon Valley's MobileMonday at UC Berkeley. The most pleasant surprise was to see Russell Beattie present. I will post about what he talked about, which was mainly a plug (a very informative and well done one, by the way) for his latest venture Mowser.

Russ broke the ice with his BS-meter about mobile Web – which I found so true, so I thought I would post it here:

- “Users only care about x and y”
- “Users don’t need a, b, or c”
- “Networks are too slow” (my personal favorite)
- “Mobile Web is too expensive”

Russell synthesized the approaches to Mobile Web to the following three. The first is the “Dedicated” (all xHTML) approach, which is ubiquitous today. It has its limitations because it is not what we would expect as an Internet-like experience, but it is very good for mobile-specific functionality to complement other services (banks, weather, maps, etc.). Lastly, it is very easy to create applications using this approach. The problem: low-end mobile browsers. Not that I would call this a “problem” personally, but a way around the many limitations of feature phones, which is what the majority of consumers can afford today.

The second approach Russ named the “Internet of Phones” (smartphones, that is). This approach is possible thanks to next generation browsers, such as DeepFish (MSFT), the Nokia Mini Map, and the Access Netfront 3.5. There was mention of the iPhone browser, but by the way, most of us have yet to see and for all we know is nothing but vaporware – and as Russ cleverly mentioned, it will only operate in GPRS, at least at launch. The problem with this approach is that the PC experience is still too difficult to mimic.

The third approach is Widgets. Russ’ perspective: mobile widgets are difficult to find, they need to be downloaded and installed, there are steep learning curve for users, and take time to develop.

I will continue to comment on Russ’s extremely insightful presentation later (he spoke about Transcoding and obviously, Mowser.com). For now, I close with the hopeful thought Russ will continue to honor us with more posts of his own, as he promised at MobileMonday.