Adsense Nonsense 2.0 – Google writes a bad check

Published by:

If I tried, I couldn’t make up a story like this. First, there was the problem, then, there was the solution, and now comes the comedy. I hope you’re wearing your laughing pants.

Catching everyone up to date quickly:

  • Google Adsense technical gitch screwed up my address change for a month
  • The check is already six weeks overdue per Google’s schedule
  • I chatted with them via email for a week
  • Result, I must wait until the check is redeposited in my Adsense account and whatever monthly check issuing cycle that hits is when I get a new check sent out (maybe July, maybe August)
  • I blogged about the experience
  • Matt Cutts from Google stopped by, tipped his white hat and passed the case to someone in Adsense management
  • A day later my check was sent via FedEx

So, today I go to cash the check. I’m standing at the teller window, and realize, gee – this is taking a long time. She looks up at me and says, “There aren’t sufficient funds in the account to cover your check.” *stunned silence* I say, “Excuse me, could you repeat that?” She does. My reaction?

<font-style:”small>Historical Reenactment

Google bad check reaction reenactment

First, denial and disbelief. I say, “Are you sure? Do you know who Google is? You’re kidding me, right?” She says she does know who Google is, but that this particular account doesn’t have enough funds to cover my check. I’m too stunned to move. I look down at the check handled back to me and look back up at her confused.

Next, shock and awe. I say to the teller, “How does a gazillionaire company like Google have a bank account with so little money in it?” She laughs. I laugh. What else is there to do?

Finally, the teller suggests I call someone. I stare at my mobile phone realizing I don’t have any numbers for any of the people I’ve spoken to at Google. She says, “Call the number on the check.” Great idea! So, I do.

It’s the main inbound number at Google. The Voicemail Lady and I have an exchange. You all know her voice.

Voicemail Lady: If you know the extension of the person you’d like to reach, dial it now followed by the pound sign.

Me: Nope, I don’t know any extension numbers.

Voicemail Lady: Press 8 to dial by name.

Me: Great! Pressing 8. *whistling to myself a bit*

Voicemail Lady: Please enter the first few letters of the last name.

Me: Hmmmmm, Brian the payments operations guy probably won’t work as a name in this system. That’s the result of Google’s employee privacy policy. I don’t know the guy’s last name. I know, Matt Cutts! Surely, Matt can get me transfered to Brian the payments operations guy or someone else. I type in Cutts.

Voicemail Lady: Please enter more characters.

Me: More characters for his last name? Or should I start on his first name, now? I’ll do both alternatively until some combo works.

Voicemail Lady: Please enter more characters.

Me: Entering Cutts, Matt.

Voicemail Lady: That userid is not valid. Goodbye.

So, finally I get over the enter more characters hurdle and hear what I believe was Matt’s voice – sternly.

Matt: This voicemail box is not active. It is not checked on a regular basis. Do not leave messages in this voicemail box. Beep.

So, I call back having heard an option given by the Voicemail Lady for customer service.

Voicemail Lady: For customer service/technical help press 5.

Me: I’m so there!

Voicemail Lady: (gives options 1 & 2) Press 3 for all other questions.

Me: Done.

Voicemail Lady: As Google does not currently authorize customer support, please see our website.

Me: Doh!

Google sent me a bad check! Now what?

I’m sure this is a result of someone trying to do something outside the normal and timed operations of this huge monolithic organization, but still…. WTF?

Adsense Nonsense 2.0 – Google writes a bad check

Published by:

If I tried, I couldn’t make up a story like this. First, there was the problem, then, there was the solution, and now comes the comedy. I hope you’re wearing your laughing pants.

Catching everyone up to date quickly:

  • Google Adsense technical gitch screwed up my address change for a month
  • The check is already six weeks overdue per Google’s schedule
  • I chatted with them via email for a week
  • Result, I must wait until the check is redeposited in my Adsense account and whatever monthly check issuing cycle that hits is when I get a new check sent out (maybe July, maybe August)
  • I blogged about the experience
  • Matt Cutts from Google stopped by, tipped his white hat and passed the case to someone in Adsense management
  • A day later my check was sent via FedEx

So, today I go to cash the check. I’m standing at the teller window, and realize, gee – this is taking a long time. She looks up at me and says, “There aren’t sufficient funds in the account to cover your check.” *stunned silence* I say, “Excuse me, could you repeat that?” She does. My reaction?

<font-style:”small>Historical Reenactment

Google bad check reaction reenactment

First, denial and disbelief. I say, “Are you sure? Do you know who Google is? You’re kidding me, right?” She says she does know who Google is, but that this particular account doesn’t have enough funds to cover my check. I’m too stunned to move. I look down at the check handled back to me and look back up at her confused.

Next, shock and awe. I say to the teller, “How does a gazillionaire company like Google have a bank account with so little money in it?” She laughs. I laugh. What else is there to do?

Finally, the teller suggests I call someone. I stare at my mobile phone realizing I don’t have any numbers for any of the people I’ve spoken to at Google. She says, “Call the number on the check.” Great idea! So, I do.

It’s the main inbound number at Google. The Voicemail Lady and I have an exchange. You all know her voice.

Voicemail Lady: If you know the extension of the person you’d like to reach, dial it now followed by the pound sign.

Me: Nope, I don’t know any extension numbers.

Voicemail Lady: Press 8 to dial by name.

Me: Great! Pressing 8. *whistling to myself a bit*

Voicemail Lady: Please enter the first few letters of the last name.

Me: Hmmmmm, Brian the payments operations guy probably won’t work as a name in this system. That’s the result of Google’s employee privacy policy. I don’t know the guy’s last name. I know, Matt Cutts! Surely, Matt can get me transfered to Brian the payments operations guy or someone else. I type in Cutts.

Voicemail Lady: Please enter more characters.

Me: More characters for his last name? Or should I start on his first name, now? I’ll do both alternatively until some combo works.

Voicemail Lady: Please enter more characters.

Me: Entering Cutts, Matt.

Voicemail Lady: That userid is not valid. Goodbye.

So, finally I get over the enter more characters hurdle and hear what I believe was Matt’s voice – sternly.

Matt: This voicemail box is not active. It is not checked on a regular basis. Do not leave messages in this voicemail box. Beep.

So, I call back having heard an option given by the Voicemail Lady for customer service.

Voicemail Lady: For customer service/technical help press 5.

Me: I’m so there!

Voicemail Lady: (gives options 1 & 2) Press 3 for all other questions.

Me: Done.

Voicemail Lady: As Google does not currently authorize customer support, please see our website.

Me: Doh!

Google sent me a bad check! Now what?

I’m sure this is a result of someone trying to do something outside the normal and timed operations of this huge monolithic organization, but still…. WTF?

Mobile Web – Just Say No!

Published by:

Mmetrics have released an interesting little data snack from their smartphone user panels. The chart shows the top “mobile web” destinations in the US versus in the UK.

Top Mobile Web Sites

What’s interesting here is that five of the top ten web sites accessed from mobiles in the UK are carrier/operator sites, while the US list more closely resembles the top www sites list. There are the very consistant top three, Google, Yahoo! and Microsoft (MSN) and only two carrier/operator sites in the US top ten list. I’ve asked this question of a number of people in the mobile applications, infrastructure and operator businesses, “Is the US consumers’ entry to mobile data services impacted by the very high PC peneration rate and previous web experience in the US versus Europe?” The answers have varied and granted one should not draw conclusions from this one data point, but it validates asking the question.

The label “mobile web” creates cognitive dissonance and confusion in the marketplace. Is there a separate web? The real answer should be no, and in fact, as one observes the growth and evolution of mobile data services in the US what strikes the chord of recognition and apparently adoption are those services familiar from our web experience which add a mobile specific UI and uniquely mobile VAS (value added service) to existing behaviors.

For example, Alltel’s award winning Celltop application ties web services into a UI which works on handsets and tiny screens. Note: Celltop awards are both industry and user bestowed.

Celltop Business View Celltop Sports View Celltop Consumer View

Weather, news, sports scores, stocks and new ringtones/callback tones are services combined from the web and/or the carrier/operator presented in a handset specific UI. Alltel are also running polls to ask their users which web service they’d like to see offered next through Celltop. The options include a digg feed, Gmail, NASCAR updates or horoscopes. Sounds webilicious, no?

Another example is a personal favorite, Sprint Navigation by Telenav. I love this application.

Sprint Navigation Menu View Sprint Navigation Turn-by-turn Sprint Navigation Traffic

Most of you have used Mapquest, Yahoo! Maps, Google Maps or some combination of web based mapping and navigation applications. Telenav brings web services behind maps and navigation along traffic information together with GPS and voice capabilities from the handset and mobile network. The result is a powerful personal navigation solution.

First, your actual location is determined via GPS, then you have the option to type or speak the address of your destination. This is where Telenav have done a superior job of integrating with native handset strength in functionality. Screen viewing to observe navigation instructions is supremely difficult at 80 mph on a California freeway. (This is an illustration not an admission of guilt in case the CHPS are listening.) So, Sprint Navigation allows placing a call from inside the application to an automated voice search facility which locates and confirms your destination address, then returns the handset to application state on completion of the call. Your route is calculated and finally the application checks a web traffic conditions service and either reports traffic is good or reroutes to your destination, if possible.

So great! You’ve got a route, traffic considered, and now to get there you need to view the directions. Well, not nessarily. The application repeats turn-by-turn instructions periodically via voice. Using your headset or speakerphone (safety first people) you will hear updated instructions until the turn is reached or you bypass it. If a turn is missed, the application automatically informs you and recalculates the directions. That’s user fault tolerant which I often need give I suffer BADD (blogger attention deficit disorder) which is far shorter and more easily distracted than ADD or ADHD.

Here are two excellent and well adopted applications which do all the things that we’ve been told at countless events and conferences are essential to a successful application, and more importantly, they are implemented extremely well.

  1. web functionality
  2. augment with handset mobile network strengths
  3. mobile specific UI – this might require multiple modalities (don’t ignore voice)
  4. user centric design and fault tolerant

Okay, maybe the list wasn’t presented exactly this way, but it should’ve been. To all those evangelizing “the mobile web,” please stop. And reset to evangelize web services on mobile devices.

I’ll continue to try and persuade you on this logic. Stayed tuned for the next article of the series: .mobi winners and losers.

Back to the Mmetrics findings.   Well over half of the web browsing activity by smartphone users in the UK occurs on operator portals.  Well over half of the web surfing activity by smartphone users in the US is through Google.  It would be helpful to have a breakdown of the Google activity.  Is that all search?  How much is attributable to Gmail access?  Data always raises more questions.

These findings also highlight another consideration when combined with the illustrations of web services in this article.  What does it now mean to access the web from a mobile device?  Are web services through thick clients merely a interim step on the path to fully functioning web browsers on mobile devices?  I think not.  Again, with the example of Sprint Navigation, it takes a handset application to weave handset functionality into a complete solution.

And finally what does it mean that smartphoners in the UK rely upon their operator portals for web browsing?  Are the services offered by operators superior to those on the web?  Is it habit?   Or perhaps, the walled garden is simply more persistent in the UK than it is in the US.

Mobile Web – Just Say No!

Published by:

Mmetrics have released an interesting little data snack from their smartphone user panels. The chart shows the top “mobile web” destinations in the US versus in the UK.

Top Mobile Web Sites

What’s interesting here is that five of the top ten web sites accessed from mobiles in the UK are carrier/operator sites, while the US list more closely resembles the top www sites list. There are the very consistant top three, Google, Yahoo! and Microsoft (MSN) and only two carrier/operator sites in the US top ten list. I’ve asked this question of a number of people in the mobile applications, infrastructure and operator businesses, “Is the US consumers’ entry to mobile data services impacted by the very high PC peneration rate and previous web experience in the US versus Europe?” The answers have varied and granted one should not draw conclusions from this one data point, but it validates asking the question.

The label “mobile web” creates cognitive dissonance and confusion in the marketplace. Is there a separate web? The real answer should be no, and in fact, as one observes the growth and evolution of mobile data services in the US what strikes the chord of recognition and apparently adoption are those services familiar from our web experience which add a mobile specific UI and uniquely mobile VAS (value added service) to existing behaviors.

For example, Alltel’s award winning Celltop application ties web services into a UI which works on handsets and tiny screens. Note: Celltop awards are both industry and user bestowed.

Celltop Business View Celltop Sports View Celltop Consumer View

Weather, news, sports scores, stocks and new ringtones/callback tones are services combined from the web and/or the carrier/operator presented in a handset specific UI. Alltel are also running polls to ask their users which web service they’d like to see offered next through Celltop. The options include a digg feed, Gmail, NASCAR updates or horoscopes. Sounds webilicious, no?

Another example is a personal favorite, Sprint Navigation by Telenav. I love this application.

Sprint Navigation Menu View Sprint Navigation Turn-by-turn Sprint Navigation Traffic

Most of you have used Mapquest, Yahoo! Maps, Google Maps or some combination of web based mapping and navigation applications. Telenav brings web services behind maps and navigation along traffic information together with GPS and voice capabilities from the handset and mobile network. The result is a powerful personal navigation solution.

First, your actual location is determined via GPS, then you have the option to type or speak the address of your destination. This is where Telenav have done a superior job of integrating with native handset strength in functionality. Screen viewing to observe navigation instructions is supremely difficult at 80 mph on a California freeway. (This is an illustration not an admission of guilt in case the CHPS are listening.) So, Sprint Navigation allows placing a call from inside the application to an automated voice search facility which locates and confirms your destination address, then returns the handset to application state on completion of the call. Your route is calculated and finally the application checks a web traffic conditions service and either reports traffic is good or reroutes to your destination, if possible.

So great! You’ve got a route, traffic considered, and now to get there you need to view the directions. Well, not nessarily. The application repeats turn-by-turn instructions periodically via voice. Using your headset or speakerphone (safety first people) you will hear updated instructions until the turn is reached or you bypass it. If a turn is missed, the application automatically informs you and recalculates the directions. That’s user fault tolerant which I often need give I suffer BADD (blogger attention deficit disorder) which is far shorter and more easily distracted than ADD or ADHD.

Here are two excellent and well adopted applications which do all the things that we’ve been told at countless events and conferences are essential to a successful application, and more importantly, they are implemented extremely well.

  1. web functionality
  2. augment with handset mobile network strengths
  3. mobile specific UI – this might require multiple modalities (don’t ignore voice)
  4. user centric design and fault tolerant

Okay, maybe the list wasn’t presented exactly this way, but it should’ve been. To all those evangelizing “the mobile web,” please stop. And reset to evangelize web services on mobile devices.

I’ll continue to try and persuade you on this logic. Stayed tuned for the next article of the series: .mobi winners and losers.

Back to the Mmetrics findings.   Well over half of the web browsing activity by smartphone users in the UK occurs on operator portals.  Well over half of the web surfing activity by smartphone users in the US is through Google.  It would be helpful to have a breakdown of the Google activity.  Is that all search?  How much is attributable to Gmail access?  Data always raises more questions.

These findings also highlight another consideration when combined with the illustrations of web services in this article.  What does it now mean to access the web from a mobile device?  Are web services through thick clients merely a interim step on the path to fully functioning web browsers on mobile devices?  I think not.  Again, with the example of Sprint Navigation, it takes a handset application to weave handset functionality into a complete solution.

And finally what does it mean that smartphoners in the UK rely upon their operator portals for web browsing?  Are the services offered by operators superior to those on the web?  Is it habit?   Or perhaps, the walled garden is simply more persistent in the UK than it is in the US.

Mobile Web – Just Say No!

Published by:

Mmetrics have released an interesting little data snack from their smartphone user panels. The chart shows the top “mobile web” destinations in the US versus in the UK.

Top Mobile Web Sites

What’s interesting here is that five of the top ten web sites accessed from mobiles in the UK are carrier/operator sites, while the US list more closely resembles the top www sites list. There are the very consistant top three, Google, Yahoo! and Microsoft (MSN) and only two carrier/operator sites in the US top ten list. I’ve asked this question of a number of people in the mobile applications, infrastructure and operator businesses, “Is the US consumers’ entry to mobile data services impacted by the very high PC peneration rate and previous web experience in the US versus Europe?” The answers have varied and granted one should not draw conclusions from this one data point, but it validates asking the question.

The label “mobile web” creates cognitive dissonance and confusion in the marketplace. Is there a separate web? The real answer should be no, and in fact, as one observes the growth and evolution of mobile data services in the US what strikes the chord of recognition and apparently adoption are those services familiar from our web experience which add a mobile specific UI and uniquely mobile VAS (value added service) to existing behaviors.

For example, Alltel’s award winning Celltop application ties web services into a UI which works on handsets and tiny screens. Note: Celltop awards are both industry and user bestowed.

Celltop Business View Celltop Sports View Celltop Consumer View

Weather, news, sports scores, stocks and new ringtones/callback tones are services combined from the web and/or the carrier/operator presented in a handset specific UI. Alltel are also running polls to ask their users which web service they’d like to see offered next through Celltop. The options include a digg feed, Gmail, NASCAR updates or horoscopes. Sounds webilicious, no?

Another example is a personal favorite, Sprint Navigation by Telenav. I love this application.

Sprint Navigation Menu View Sprint Navigation Turn-by-turn Sprint Navigation Traffic

Most of you have used Mapquest, Yahoo! Maps, Google Maps or some combination of web based mapping and navigation applications. Telenav brings web services behind maps and navigation along traffic information together with GPS and voice capabilities from the handset and mobile network. The result is a powerful personal navigation solution.

First, your actual location is determined via GPS, then you have the option to type or speak the address of your destination. This is where Telenav have done a superior job of integrating with native handset strength in functionality. Screen viewing to observe navigation instructions is supremely difficult at 80 mph on a California freeway. (This is an illustration not an admission of guilt in case the CHPS are listening.) So, Sprint Navigation allows placing a call from inside the application to an automated voice search facility which locates and confirms your destination address, then returns the handset to application state on completion of the call. Your route is calculated and finally the application checks a web traffic conditions service and either reports traffic is good or reroutes to your destination, if possible.

So great! You’ve got a route, traffic considered, and now to get there you need to view the directions. Well, not nessarily. The application repeats turn-by-turn instructions periodically via voice. Using your headset or speakerphone (safety first people) you will hear updated instructions until the turn is reached or you bypass it. If a turn is missed, the application automatically informs you and recalculates the directions. That’s user fault tolerant which I often need give I suffer BADD (blogger attention deficit disorder) which is far shorter and more easily distracted than ADD or ADHD.

Here are two excellent and well adopted applications which do all the things that we’ve been told at countless events and conferences are essential to a successful application, and more importantly, they are implemented extremely well.

  1. web functionality
  2. augment with handset mobile network strengths
  3. mobile specific UI – this might require multiple modalities (don’t ignore voice)
  4. user centric design and fault tolerant

Okay, maybe the list wasn’t presented exactly this way, but it should’ve been. To all those evangelizing “the mobile web,” please stop. And reset to evangelize web services on mobile devices.

I’ll continue to try and persuade you on this logic. Stayed tuned for the next article of the series: .mobi winners and losers.

Back to the Mmetrics findings.   Well over half of the web browsing activity by smartphone users in the UK occurs on operator portals.  Well over half of the web surfing activity by smartphone users in the US is through Google.  It would be helpful to have a breakdown of the Google activity.  Is that all search?  How much is attributable to Gmail access?  Data always raises more questions.

These findings also highlight another consideration when combined with the illustrations of web services in this article.  What does it now mean to access the web from a mobile device?  Are web services through thick clients merely a interim step on the path to fully functioning web browsers on mobile devices?  I think not.  Again, with the example of Sprint Navigation, it takes a handset application to weave handset functionality into a complete solution.

And finally what does it mean that smartphoners in the UK rely upon their operator portals for web browsing?  Are the services offered by operators superior to those on the web?  Is it habit?   Or perhaps, the walled garden is simply more persistent in the UK than it is in the US.

Carnival of the Mobilists #81

Published by:

The newest CoM is up and ready for your reading pleasure at Symbiano-Tek. Check out Carnival of the Mobilists #81 Pharaoh’s Style.

Also, visit the CoM site for information on how to participate in the Carnival, or locate previous editions of the CoM.

Mobile Web – Just Say No!

Published by:

Mmetrics have released an interesting little data snack from their smartphone user panels. The chart shows the top “mobile web” destinations in the US versus in the UK.

Top Mobile Web Sites

What’s interesting here is that five of the top ten web sites accessed from mobiles in the UK are carrier/operator sites, while the US list more closely resembles the top www sites list. There are the very consistant top three, Google, Yahoo! and Microsoft (MSN) and only two carrier/operator sites in the US top ten list. I’ve asked this question of a number of people in the mobile applications, infrastructure and operator businesses, “Is the US consumers’ entry to mobile data services impacted by the very high PC peneration rate and previous web experience in the US versus Europe?” The answers have varied and granted one should not draw conclusions from this one data point, but it validates asking the question.

The label “mobile web” creates cognitive dissonance and confusion in the marketplace. Is there a separate web? The real answer should be no, and in fact, as one observes the growth and evolution of mobile data services in the US what strikes the chord of recognition and apparently adoption are those services familiar from our web experience which add a mobile specific UI and uniquely mobile VAS (value added service) to existing behaviors.

For example, Alltel’s award winning Celltop application ties web services into a UI which works on handsets and tiny screens. Note: Celltop awards are both industry and user bestowed.

Celltop Business View Celltop Sports View Celltop Consumer View

Weather, news, sports scores, stocks and new ringtones/callback tones are services combined from the web and/or the carrier/operator presented in a handset specific UI. Alltel are also running polls to ask their users which web service they’d like to see offered next through Celltop. The options include a digg feed, Gmail, NASCAR updates or horoscopes. Sounds webilicious, no?

Another example is a personal favorite, Sprint Navigation by Telenav. I love this application.

Sprint Navigation Menu View Sprint Navigation Turn-by-turn Sprint Navigation Traffic

Most of you have used Mapquest, Yahoo! Maps, Google Maps or some combination of web based mapping and navigation applications. Telenav brings web services behind maps and navigation along traffic information together with GPS and voice capabilities from the handset and mobile network. The result is a powerful personal navigation solution.

First, your actual location is determined via GPS, then you have the option to type or speak the address of your destination. This is where Telenav have done a superior job of integrating with native handset strength in functionality. Screen viewing to observe navigation instructions is supremely difficult at 80 mph on a California freeway. (This is an illustration not an admission of guilt in case the CHPS are listening.) So, Sprint Navigation allows placing a call from inside the application to an automated voice search facility which locates and confirms your destination address, then returns the handset to application state on completion of the call. Your route is calculated and finally the application checks a web traffic conditions service and either reports traffic is good or reroutes to your destination, if possible.

So great! You’ve got a route, traffic considered, and now to get there you need to view the directions. Well, not nessarily. The application repeats turn-by-turn instructions periodically via voice. Using your headset or speakerphone (safety first people) you will hear updated instructions until the turn is reached or you bypass it. If a turn is missed, the application automatically informs you and recalculates the directions. That’s user fault tolerant which I often need give I suffer BADD (blogger attention deficit disorder) which is far shorter and more easily distracted than ADD or ADHD.

Here are two excellent and well adopted applications which do all the things that we’ve been told at countless events and conferences are essential to a successful application, and more importantly, they are implemented extremely well.

  1. web functionality
  2. augment with handset mobile network strengths
  3. mobile specific UI – this might require multiple modalities (don’t ignore voice)
  4. user centric design and fault tolerant

Okay, maybe the list wasn’t presented exactly this way, but it should’ve been. To all those evangelizing “the mobile web,” please stop. And reset to evangelize web services on mobile devices.

I’ll continue to try and persuade you on this logic. Stayed tuned for the next article of the series: .mobi winners and losers.

Back to the Mmetrics findings.   Well over half of the web browsing activity by smartphone users in the UK occurs on operator portals.  Well over half of the web surfing activity by smartphone users in the US is through Google.  It would be helpful to have a breakdown of the Google activity.  Is that all search?  How much is attributable to Gmail access?  Data always raises more questions.

These findings also highlight another consideration when combined with the illustrations of web services in this article.  What does it now mean to access the web from a mobile device?  Are web services through thick clients merely a interim step on the path to fully functioning web browsers on mobile devices?  I think not.  Again, with the example of Sprint Navigation, it takes a handset application to weave handset functionality into a complete solution.

And finally what does it mean that smartphoners in the UK rely upon their operator portals for web browsing?  Are the services offered by operators superior to those on the web?  Is it habit?   Or perhaps, the walled garden is simply more persistent in the UK than it is in the US.

Mobile Web – Just Say No!

Published by:

Mmetrics have released an interesting little data snack from their smartphone user panels. The chart shows the top “mobile web” destinations in the US versus in the UK.

Top Mobile Web Sites

What’s interesting here is that five of the top ten web sites accessed from mobiles in the UK are carrier/operator sites, while the US list more closely resembles the top www sites list. There are the very consistant top three, Google, Yahoo! and Microsoft (MSN) and only two carrier/operator sites in the US top ten list. I’ve asked this question of a number of people in the mobile applications, infrastructure and operator businesses, “Is the US consumers’ entry to mobile data services impacted by the very high PC peneration rate and previous web experience in the US versus Europe?” The answers have varied and granted one should not draw conclusions from this one data point, but it validates asking the question.

The label “mobile web” creates cognitive dissonance and confusion in the marketplace. Is there a separate web? The real answer should be no, and in fact, as one observes the growth and evolution of mobile data services in the US what strikes the chord of recognition and apparently adoption are those services familiar from our web experience which add a mobile specific UI and uniquely mobile VAS (value added service) to existing behaviors.

For example, Alltel’s award winning Celltop application ties web services into a UI which works on handsets and tiny screens. Note: Celltop awards are both industry and user bestowed.

Celltop Business View Celltop Sports View Celltop Consumer View

Weather, news, sports scores, stocks and new ringtones/callback tones are services combined from the web and/or the carrier/operator presented in a handset specific UI. Alltel are also running polls to ask their users which web service they’d like to see offered next through Celltop. The options include a digg feed, Gmail, NASCAR updates or horoscopes. Sounds webilicious, no?

Another example is a personal favorite, Sprint Navigation by Telenav. I love this application.

Sprint Navigation Menu View Sprint Navigation Turn-by-turn Sprint Navigation Traffic

Most of you have used Mapquest, Yahoo! Maps, Google Maps or some combination of web based mapping and navigation applications. Telenav brings web services behind maps and navigation along traffic information together with GPS and voice capabilities from the handset and mobile network. The result is a powerful personal navigation solution.

First, your actual location is determined via GPS, then you have the option to type or speak the address of your destination. This is where Telenav have done a superior job of integrating with native handset strength in functionality. Screen viewing to observe navigation instructions is supremely difficult at 80 mph on a California freeway. (This is an illustration not an admission of guilt in case the CHPS are listening.) So, Sprint Navigation allows placing a call from inside the application to an automated voice search facility which locates and confirms your destination address, then returns the handset to application state on completion of the call. Your route is calculated and finally the application checks a web traffic conditions service and either reports traffic is good or reroutes to your destination, if possible.

So great! You’ve got a route, traffic considered, and now to get there you need to view the directions. Well, not nessarily. The application repeats turn-by-turn instructions periodically via voice. Using your headset or speakerphone (safety first people) you will hear updated instructions until the turn is reached or you bypass it. If a turn is missed, the application automatically informs you and recalculates the directions. That’s user fault tolerant which I often need give I suffer BADD (blogger attention deficit disorder) which is far shorter and more easily distracted than ADD or ADHD.

Here are two excellent and well adopted applications which do all the things that we’ve been told at countless events and conferences are essential to a successful application, and more importantly, they are implemented extremely well.

  1. web functionality
  2. augment with handset mobile network strengths
  3. mobile specific UI – this might require multiple modalities (don’t ignore voice)
  4. user centric design and fault tolerant

Okay, maybe the list wasn’t presented exactly this way, but it should’ve been. To all those evangelizing “the mobile web,” please stop. And reset to evangelize web services on mobile devices.

I’ll continue to try and persuade you on this logic. Stayed tuned for the next article of the series: .mobi winners and losers.

Back to the Mmetrics findings.   Well over half of the web browsing activity by smartphone users in the UK occurs on operator portals.  Well over half of the web surfing activity by smartphone users in the US is through Google.  It would be helpful to have a breakdown of the Google activity.  Is that all search?  How much is attributable to Gmail access?  Data always raises more questions.

These findings also highlight another consideration when combined with the illustrations of web services in this article.  What does it now mean to access the web from a mobile device?  Are web services through thick clients merely a interim step on the path to fully functioning web browsers on mobile devices?  I think not.  Again, with the example of Sprint Navigation, it takes a handset application to weave handset functionality into a complete solution.

And finally what does it mean that smartphoners in the UK rely upon their operator portals for web browsing?  Are the services offered by operators superior to those on the web?  Is it habit?   Or perhaps, the walled garden is simply more persistent in the UK than it is in the US.

Adsense Dollars and Cents, not Nonsense

Published by:

I could have merely updated Adsense Nonsense, but the events following that post merit their own article.  Maybe I am Guy Kawasaki, afterall.

Less than a day after posting my frustration with Adsense, Matt Cutts left a comment and forwarded my article to Brian (last name not given) in management at Adsense operations.  Brian phoned me Friday morning, but I didn’t speak with him as I’ve posted here before, I don’t answer calls that block caller id.  Later he emailed to inform me that he was aware of the problem, had received communication from both Matt and Suzie, and that my check was going out FedEx immediately.

To my astonishment, someone from Google not only heard my plea, but went further and acted on it.   I want to thank Brian, Matt and Suzie for working to solve this problem and make things right between Adsense and me.  My check arrived this morning via FedEx, as promised.

The lingering question for me is whether to reconstitute Adsense on mobilejones.com.  I remain undecided.  Brian’s email assured me that they were looking at my case to see where improvements could be made to ensure there are no repeats of this problem.  I’d like to hear about those solutions when they are implemented.

Maybe you have a suggestion for what I should do in regards to Adsense.  What would you do?

Adsense Dollars and Cents, not Nonsense

Published by:

I could have merely updated Adsense Nonsense, but the events following that post merit their own article.  Maybe I am Guy Kawasaki, afterall.

Less than a day after posting my frustration with Adsense, Matt Cutts left a comment and forwarded my article to Brian (last name not given) in management at Adsense operations.  Brian phoned me Friday morning, but I didn’t speak with him as I’ve posted here before, I don’t answer calls that block caller id.  Later he emailed to inform me that he was aware of the problem, had received communication from both Matt and Suzie, and that my check was going out FedEx immediately.

To my astonishment, someone from Google not only heard my plea, but went further and acted on it.   I want to thank Brian, Matt and Suzie for working to solve this problem and make things right between Adsense and me.  My check arrived this morning via FedEx, as promised.

The lingering question for me is whether to reconstitute Adsense on mobilejones.com.  I remain undecided.  Brian’s email assured me that they were looking at my case to see where improvements could be made to ensure there are no repeats of this problem.  I’d like to hear about those solutions when they are implemented.

Maybe you have a suggestion for what I should do in regards to Adsense.  What would you do?