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.

LBS Is for Everyone

Contrary to popular belief, carriers (Sprint and Verizon Wireless in the U.S.) have opened up their LBS platforms to the developer community. In this post I focus on Verizon Wireless’ LBS platform and publicly available Brew API. For more detailed information you may look at this presentation that was given at the Brew 2006 Developers Conference.

The Brew API is also publicly available. Through use of this API information that is available to applications through the ILpsPosDet extension for GPS is latitude, longitude, and altitude, among other information; through the same extension, one can also get the system ID, Network ID, Base Station ID and other information.

So why do some developers find themselves unable to tap into these platforms? The costs to do it could be significant and are often times unplanned for. Developers must first pay a fee to join the Brew developer community and gain access to all the proper development tools, such as the Brew SDK. Besides development expenses developers will also incur the costs to certify their application. This certification must take place for each device platform (add this to the porting expenses). Finally, carriers take a share of their revenues once the application is commercialized.

In summary, it is not that operators keep their platforms closed. But given the economics, many developers feel as if that were the case.

What do you like to use your cell phone for?

I have created a ratings Weblist on RateItAll to find out what people like to use their cell phones for. When you get a chance, you too can let the world know what you think are useful applications of cell phones. Here's a link to my Weblist.

Check out RateItAll

Location, Location, Location

My last posting on Meetro brought up some interesting discussions with Mobilites out there. Some see Meetro as having the disadvantage of lacking users' precise location and feel mobile operators' Location Based Services will overtake players like Meetro. My response is simple. Applications like Meetro fulfill a different need entirely: "I want to know who's close to me. I want to know if this attractive person lives close to me or far away. And if they live close, I might just throw out there the idea of meeting up". It is true Meetro cannot offer precise location information to within feet, but in some sense, why would they want to? Enter the BIG issue when it comes to LBS: Privacy. Privacy is a huge deal for mobile operators as well as for consumers. Mobile operators will probably never allow users to see where everybody else in the network is physically located. Talk about the potential for disaster... Customers would never allow other untrusted users in the network to know their precise location either. Even for trusted users, an LBS user will want the capability of turning on and off that visibility. The services we are going to see from operators will be security intensive. An example would be a friend (or employee, or child) finder app, that lets users set security rules for other users – i.e., only my friend should be able to see my location, but only when I want them to).

This brings me to the big news of the month: Verizon Wireless launched their first LBS application, VZNavigator . VZNavigator finds your precise location and that of such destinations as restaurants, airports, specific addresses etc. and provides you with turn-by-turn directions. To use VZNavigator you will need a Motorola V325. Once you buy the phone you can use the service for $9.99/month or $2.99/day.

This is a pretty big deal for Mobilites. While mobile operators are likely to launch with a few more branded applications I would be willing to bet they are probably not going to get into the Web 2.0 groove. Let's just face it, while NTTDoCoMo fully exploited data to provide an Internet like experience on mobile devices, U.S. carriers completely missed the boat. Chances are they will miss this one as well. This leaves open a great opportunity (and in my opinion, obligation) for developers to leverage LBS and take Mobile 2.0 to the next level. The two big LBS platform providers Wave Market and Auto Desk claim to have developer programs. This playing field should get very exciting, very soon. So to get a closer look at Auto Desk don't miss the Bay Area's up coming , Mobile Monday.

Meet Meetro

In Silicon Valley it’s really not that often that one runs into a start up with a truly disruptive idea. If you live here and are like me, you have fallen into the horrible habit when listening to people’s new idea for a business of instinctually tearing to pieces. Chances are you’ve already heard it before or know someone who already failed miserably while trying to do the same.

I spent my Saturday afternoon at a BBQ hosted by what seemed at first your typical Silicon Valley start-up. If you have lived here for more than five years and were participant to many of these events during the boom, or to put it easier, if you’ve read Coupland’s Microserfs, you get the picture: a house in close proximity to Sand Hill Rd., its living room the office of all the employees, most of whom are under 30, equipment, cables, paper everywhere – not to mention the bedrooms turned into dorm rooms and a communal bathroom.

When Paul Bragiel, one of the Meetro founders, invited my husband over to Meetro HQ I quickly jumped on the opportunity. I am a wireless applications addict and had not had the chance to try out Meetro b/c they have not launched a Mac OS client, yet. But my true curiosity stemmed more from my skepticism about the media created buzz around Meetro’s ability to offer Location Based Services. Come on! Anyone knows only mobile operators can offer LBS today, right?! Ok, so I am being facetious; most people don’t even understand what LBS is - which is why Google can coin the term and and get away with it! But that’s a topic for another occasion. I also wanted to find out if they weren’t just another (uhm, boring…) Dodgeball. The point is I wanted to check out Meetro so that I could understand how they are doing what they claim to do: “radius and proximity based software.”

Here’s what I was able to dig up (no worries Meetro, there’s a lot more to your secret sauce): Meetro today works by downloading an application to your PC (think of Instant Messenger) that finds a unique identifier that is inside your pc or Wi-Fi router or card, pairs it with your physical address (you have to enter it manually if you are the first user to ever use Meetro through that PC or Hot Spot), and sends it to a Meetro server to be added to a database with other users’ similar information. That way Meetro can tell which users are in the proximity of which users, and thus let them know. Ok, so this is not Location Based Services: 1) it’s not for cell phones (yet) and 2) it does not use all of the complex triangulation algorithms cellular networks and GPS use. But it pretty much does the job! If you are often on the go and use your PC in different locations Meetro will automatically find you and let the Meetro network of users know of your proximity to them. Automatically is the key word here - who wants to be reporting to a system every time he/she arrives at a location via text messaging?

I used the word ‘today’ earlier because Meetro does have the potential to do a LOT more in the future. I really mean a LOT. Of all the applications out there that claim to merge mobility and social networking, Meetro has a leg up. They have a very unique offering that is very easy and fun to use. It is viral and addictive, which can be seen by the big traction they gathered soon after launching in Chicago. And while there are some considerations like barriers to entry, the size of the mobile PC market and oh, yes… revenue models, what Meetro is in the process of building could go into so many directions in terms of building a business and growing the technology.

And so I walked away from my encounter with Meetro with not just an alpha client for Mac OS (which has already become a serious distraction for me), but also with more ideas as to how Meetro can succeed in this new Wireless meets Internet space, instead of a million reasons why they won’t.

Hello World

Ok, so I am just experimenting posting via my cell phone. This message was sent using PIX-FLIX Messaging service from Verizon Wireless.