Mike Rowehl: This is Mobility

The word is out now that dotMobi is picking up the Mowser assets. Like I said in my post about planning to shut down Mowser, the problem wasn’t with Mowser itself or the technique of content adaption or the mobile web as a whole. We just weren’t able to run Mowser as a media site and make the kind of money we needed from advertising. The folks at dotMobi however have a much different position in the market.

They’re already hooked up with folks looking to go mobile and in a unique position to offer the service without the hurdles Russ and I had in reaching motivated site owners. Like we discussed at the last Mobile Monday in Silicon Valley, one of the most important aspects of planning out a mobile business is to have the right partnerships in place to give you a strong market channel. Working independently Russ and I didn’t have that. dotMobi is in an excellent position to be able to try out some different models with the technology that made up Mowser - and has an existing audience and constant stream of new users to try it out on.

I’m actually out in Dublin right now working with the dotMobi team to figure out where to integrate Mowser and what products and services would benefit the most:

It’s an excellent chance to explore some of the ideas that Russ and I knew we would find it difficult to put into practice, as well as a chance to work with some folks I hold in high regard. I had already been talking to James about Mowser when Russ decided to shut it down, so shifting the conversation to purchasing the Mowser assets was natural. I’m pretty proud of the way things turned out. Not the part where we failed and had to give up, but all the stuff that’s happened since then. There’s a real strategic fit with the Mowser code at dotMobi, it’s going to a great team with a genuine goal of making the mobile web better, and instead of just shutting the thing down and dropping it we managed to dig Russ out of some of that infamous debt as well.

I’m going to remain in Dublin for the next week or so (returning to San Fran on May 16th). In the meantime we’ll be figuring out how to integrate the parts of Mowser and working up some roadmaps. Most likely the Mowser site will not keep operating as such, though I’m not sure what the timeline is for migrating the services. Once we do have a plan we’ll post it to the Mowser blog to give the folks who are currently using Mowser time to switch off or change services if they choose to.

Russ and I have worked on stuff together in the past. One of the interesting side effects of online celebrity (or whatever you want to call it that Russ has, blog popularity, name recognition - the term itself isn’t important) is that whenever we work on something together it’s not “Russ and Mike”s whatever, it’s Russ’s whatever. It’s happened a few times, and we even named it “The MoMo Effect” after Mobile Monday, which is where it first seemed to happen. Normally I don’t care about it much, as long as I can get done what I want to I’m happy to ride on Russ’s popularity. With the collapse of Mowser I’m actually happy to see that it’s written up all over the place as “Russ Beattie’s Mowser.” At least I don’t have my name directly associated with that flame out in most people’s minds.

However something happened out of this that I wasn’t thinking about at all. I’ve spent the last 3 months tapping everyone I could to get a chance to talk to angels and VCs to see if we could find some funding. Obviously we didn’t. However, the “is the mobile web dead” conversation that got kicked off has caused issues for some of the folks who helped me out who were also currently looking for funding. I’ve had a few calls that went something like: “What the hell? I introduced you to a bunch of folks, and you guys turned right around and screwed us! People are starting to wonder now if they should put their money in the mobile web.”

Interesting, after not being able to get money out of anyone for Mowser, which I was working on with Russ - I’m interested to hear that anyone’s investment policy would be impacted by a post that Russ put up. I would be surprised if even the secondary conversation that came out of it impacted anyone. So just something to keep in mind for the other folks out there. Just because when you go and sit down with a group of folks to discuss what you’re doing and have it dismissed, that doesn’t mean those folks aren’t going to turn right around and use your commentary against friends and partners. Watch your back, sometimes the problems come from the places you least expect them to.

The reaction to Russ’s post about shutting down Mowser and his thoughts on the mobile web have me in a bit of a tizzy. Russ is a good friend, and I understand where his thoughts are coming from, so I’m not going to attack him. I would however like to bitch at the rest of the Internet for being unthinking sheep on the whole.

The reaction to Russ’s post seems to be “Oh god no! The mobile internet is dead!” For one of the folks who was a vocal advocate of the web on small devices to say that developing for low end devices is a waste of time, well then the whole game must be over and everyone should pack up their tents and go home. Come on! Here’s an example of something I like to call “independent thought”, all of you out there might like to try this exercise on your own.

First is to try to extract some core points from the stuff that’s laid down in the post. Try to draw some boundaries around what exactly it is that seems to be the issue with Mowser. First of all we were aimed at lower capability devices, the average handset you find in pockets from San Francisco to Mumbai. That meant we weren’t doing anything special for higher capability devices like the iPhone or recent N and E series Nokia devices. While that increases the audience you can address, it also takes a lot of the whiz-bang WOW factor out of the initial user experience for the power users. It also means that we were positioned against the current market movement, which sees more and more high capability devices out there. Does that mean that a content adaption service would never be able to survive in the world of high capability handsets? NO! It just means that two guys working out of their homes and trying to cover all aspects of the business weren’t able to come up with a method that covered high capability devices with a pleasant experience and served low capability devices adequately.

As far as the fact that many of the requests through Mowser were porn related, that’s not a unique issue, and certainly not “a problem”. Carrier networks try to filter out porn and restrict what people can do. Give them an open system and they’re going to go out looking for what they want. And if they want hot girl on girl action, hell, that’s what we serve up. Takeaway for that is that there’s huge potential in adult mobile content still, not all the business models have been explored there apparently. Does that means that “everyone browsing the mobile web” is a pervert? No, it doesn’t mean that at all. Does it mean that the only stuff you can put on the mobile web and get an audience is adult content? No. But it means that given the methods we used to grow organic traffic we got a lot more adult related searches than other terms. You can draw no other conclusions from it, and to do otherwise would be stupid.

Third is the monetization. Making significant scratch from a mobile website run as a media company is still pretty hard. The availability of mobile advertising networks has lowered the bar quite a bit. But not enough so that an adaption engine with monetization on interstitial pages and throwoff traffic on a directory of links is a no-brainer. We had too few methods of monetization build into Mowser, too few “advertising positions per pageview”, and hadn’t made it over the traffic hump where trying to represent any subsection of our property as a higher value media buy could have increased our margins. Because we did have lots of traffic from places like India and South Africa, which are less hotly contested in the advertising networks, much of the advertising we had a relatively low payout per thousand impressions (eCPM in the biz). We didn’t have a good mechanism for profiting off that traffic more directly, though I’m sure the right person would be able to find a way to make that work.

Finally there’s the team. Two guys who have been around mobile for years, very familiar with the web and current trends in online services, and well connected to the existing ecosystem. But also not sales and business development geniuses. A lot of this stuff fell to me, and I sent out a bunch of emails and called up the folks I was able to call up to pitch the idea. Some of them signed on, which was great. Mostly they were existing mobile publishers interested in linking out to resources on the web. But I wasn’t able to land any big online content networks. Lighting up About.com for instance with a mobile version for all their pages, or Wordpress.com. Getting integrated to mobilize outbound links from Facebook mobile, or MySpace, or LinkedIn. Someone with a better background than me might have been able to make those kinds of deals. Would it have changed everything? I’m not sure, but it’s an area of execution we failed at which could have shifted the balance. Should we have dumped the consumer focused side of things and instead sold transcoding as a service charged per thousand requests through the adaption engine? Should we have been looking to license this thing right off the bat? There were other methods we didn’t explore at all.

So take that all together and try to draw some conclusions out of it. Here are a few that pop to mind:

• If low capability devices are shrinking in overall market share it’s going to take more than minimal content stripping to make a compelling mobile experience. You should be planning for iPhone style devices to become more the normal and also figure out what needs to be done to service them. That means you probably need more than one engineer working on the problem, and should be looking at folks with traditional web experience in addition to those who know the details of mobile specific markup or you’ll paint yourself into a corner.
• You can’t represent a general adaption network as a premium property unless you find a way to segment. You can’t segment until you have a lot of traffic. Either try to grow in niches, starting in areas where you know you can monetize well and have models other than general network fill available. Or plan to run at a loss for a while and have a strong model for growth you can measure, and make sure you have control over it. “Google sends us traffic” does not count, especially in mobile. They can be sending you 100 thousand searches one day, and 10k the next. That’s their right as a search provider, they’re tuning as they learn as well. You need to have direct control over a majority of your traffic if your traffic is the way you make money.
• Selling the idea of making a mobile version to someone making money off web advertising is a very hard sell. They see small incremental revenue and a lot of technical complexity. Selling the idea of a free service that allows an existing mobile site owner to link to additional content, especially if they can profit from those links - that’s much easier. But even given that I wasn’t able to walk into LinkedIn and say “Hey, I have a great service for your mobile site that would allow you to include the links from the web profile pages in the mobile profile pages as well” and make that sale. I’m sure there are thousands of people who could. If you’re going to do those kinds of things, find those people early on. That means you have to be able to pick a strategy and commit to it.

See, look at that. Concrete helpful points instead of sensationalist hand waving. This was fun, thank you for joining me. I recommend trying this method of “thinking” whenever you can. Right now I’m going back to growing the mobile ecosystem wherever I can.

Russ posted already that we’re shutting down Mowser. I was chatting with him earlier, and we’re looking to sell what we have already rather than just toss it all. I still think it’s a great service that could fulfill a pressing need for a bunch of mobile sites out there. I’m not nearly as down on the idea of Mowser and the future of the mobile web as Russ is. Given the licensing fees associated with a few of the other adaption engines out there focused on mobile we could probably sell it for enough to get Russ out of debt and at the same time save some service provider a ton of money. If you’re interested let me know. miker at mowser dot com.

I was somewhat curious how the new Wordpress 2.5 admin interface would play with the browser on the N810 so I spent a little time poking around. Even though the new interface seems to be a lot more squishy than the previous version, it actually seems to work a bit smoother on the device. I like Maemo Wordpy as well, but it’s nice to be able to go in and do stuff like make sure a sudden spam surge hasn’t completely overrun my comments when I’m on the go.

While I was in a testing mood I poked around with some of the Google apps as well. The search, calendar, maps, and mail apps (as well as a few others) have bookmarks loaded into the browser by default. But I wanted to play around with the reader and the iGoogle homepage. The reader worked pretty much as I expected it to. The fact that it worked at all was great, but it was a bit slow and some screen elements overlapped each other. The kind of thing that might benefit from a bit of Greasemonkey hackery.

What I was relatively surprised by however was the iGoogle version of the homepage. All the controls worked well, even dragging around modules to change the layout. The layout is dense and efficient, I can add calendar and gmail apps in there. I added a weather app in there and then was about to pull it back out cause I already have OMWeather on the desktop of the device. But then I realized iGoogle is actually a better homescreen for the N810 than the device native applet based homescreen is.

When using the RSS reader applet on the N810 the only option is to put a blended list of every item from all feeds I’m subscribed to. No way to pick and choose and select just individual feeds or a single feed to display. The font is ridiculously large and the only options for reading are punching out to either web or RSS app, no expand in place. The same goes for the email app built into the device, just overly simplistic and at the same time fragile when compared to the other apps like Claws mail (but AFAIK Claws doesn’t have an applet to go along with it). Compare that to iGoogle configured similarly. The information density is much higher, configuration options a lot richer and more flexible, and there are just more options there for existing widgets. It’s an excellent example of rising browser capability allowing online applications to displace native apps, even when those native apps have direct operating system level support on a mobile device.

There are a few interesting things going on with “carrier networks” on the whole that have had me wondering about how folks at the carriers/operators can be so painfully dense. There’s the problem with Sprint deploying a proxy transcoder and expecting folks to get whitelisted to not be adapted instead of using standards, stunningly similar to the Vodafone issue which has already been replicated with TeliaSonera. And I have an issue that hits more close to home, my startup company Mowser is apparently subject to some access restrictions on the 3 network in the UK which apparently do not apply to Google or Yahoo.

The common response to issues on these network is that standards be written up to specify the behavior so that carriers stop doing it. I’m going to have to cry bullshit on that one. While listening to a talk by Tim Bray from Rubycon I learned there’s a document up describing the overall architecture of the world wide web. How convenient.

A quick look through the document shows where carrier networks already diverge from published recommendations. For instance take a look at the very first section after the introduction:

In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. One goal of the Web, since its inception, has been to build a global community in which any party can share information with any other party. To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web. The global scope of URIs promotes large-scale “network effects”: the value of an identifier increases the more it is used consistently.

Well when you whitelist and blacklist sites at the network level guess what you’re doing? You’re segmenting the URI namespace based on your access network. Depending on where you are and how you’re accessing the network you might or might not be able to access a resource. And when a transcoding layer is introduced for all requests through a network independent of source link structure, you’re having the network make a decision to change the semantics of a URI, selectively mapping a whole chunk of URIs to other resources. Leaving aside the whole other issue of the general Internet principle of the intelligence for any given set of protocols being at the edge of the network instead of the core, this also conflicts with the overall principle of consistent global identification.

We’ve already had decades to understand and refine the proper functioning of the Internet, and there’s already a tremendous body of work laying down and describing how to replicate and interact with it. But carrier networks continue to break the most basic and fundamental principles when there seem to be obvious and simple alternatives to get to the same goals. I strongly doubt that yet another standard will do anything to help.

Almost all of the Mobile Web docs out of the W3C that I see reference the base W3C architecture description base document like the one I was just looking at. Yet still they go ahead and define something like “in network adaption” when talking about best practices. Best practices on the Internet say that no application decisions should be applied between the two communicating endpoints. Full stop. It’s just incorrect behavior.

Unfortunately nothing really seems to be affecting these folk’s decisions to do things that are disruptive, limiting, and destructive to the long term environment. You can always vote with your feet though. If I were on Sprint I would switch off their service, same thing definitely for 3. It normally only takes a few people switching off and giving the reason of “I can’t access the web sites I want the way I want” for their customer relationship systems to form the correlation and realize it’s an actual problem. I’ll help maintain a list of carriers not to use if you care about the mobile web also, cause people might be more likely to form their decision going into a purchase rather than after they already have things up and running. So here’s my list of carrier not to get service from if you care about the mobile web:

• Vodafone UK and Portugal
• 3 UK
• Sprint

If there are others let me know in the comments.

I made a change to the Mowser Wordpress plugin to add a sidebar widget to promote the mobile version from the desktop version. It’s just a little Mowser badge and a link to the mobile URL for the current page. I have it running on my blog (which is probably where you’re reading this, but if not check it out here), up on the top of the sidebar. One of the problems with publishing a proper mobile version these days is that best practice says things should just automatically be mobile when you hit them with a mobile device. The problem is, years of stuff not working on mobile devices have conditioned people not to just type in a site and expect it to work. So how do people find out about your mobile version? Portals are one way, and search is increasingly driving traffic. But directly promoting your site can also drive users, and also just reminds people that more sites are coming online every day that they can use from their phone.

Sidebar widgets are a relatively recent addition to Wordpress, just becoming part of the default core features during 2.2. If you’re using 2.0 or 2.1 you need to download a plugin to allow sidebar widgets. You’ll also need a widget enabled theme, not a problem if you have a recent install, but I have a theme that I had been hacking over and over again. I decided to scrap it and use a new theme and the widgets to make the customizations I had. Which actually worked out quite well.

If you have a system that supports it you can configure sidebar widgets in the Presentation area or your dashboard, the subsection is simply called “Widgets”. Drag the Mowser Plugin widget from the Available Widgets tray up to the sidebar and save the changes. If you haven’t been using widget at all, adding the Mowser widget will replace the default sidebar for your theme and you’ll have to also add whatever used to be there before. Not really a part of the system I like, but I think I understand why things ended up that way. After you save the changes you should be all set, the badge linking to your mobile version should appear in the sidebar of your pages.

One of the things I liked about the Wordpress sidebar widgets is that they’re rendered server-side. So now my twitters and del.icio.us bookmarks appear in the Mowser version of my blog, which I like quite a bit.

Sounds like there’s some interesting discussion going on at GDC. I liked the summary from MocoNews about the end of carrier control in gaming. It’s an excellent example of one of the positive benefits that comes out of having the mobile web look more like a web than a bunch of standalone content silos. I wanted to call attention to this bit in particular:

Who says you have to support 1,000 handsets from the start? How about 10 and see what the uptake is? Suddenly, you have all the options that weren’t available previously.

First of all cause the idea itself is worth pointing out - that distribution through the carrier often came with a required list of porting targets and you had to hit all of them. It was a pretty cumbersome requirement to go along with distribution. The ability of the developer to pick and choose targets as they go along is great news. But it also means that niche use spread across large areas also becomes possible. An application that appeals to 5% of mobile users was something that any single carrier would never go for unless the return per user was astronomical. Even if the worldwide number of users was large (5% of the worldwide mobile using public is a lot), there was no way for the app developer to reach that user base through carrier deals. Unbundling access to mobile users by hitting them via other distribution and discovery mechanisms makes those kinds of applications realistic again. I like it!

However, the flip side to this is thinking about why the carriers put those porting requirements in there in the first place. They didn’t do it to be jerks, they did it cause they wanted to deliver a consistent experience to as many of their users as they could while not bearing high support overhead. I don’t agree that was a great way to handle that problem, but it does point out an interesting area. What’s going to happen to customer support and consistent user experience in a post-carrier-dominated world? Who do I call or what do I do when an application I downloaded yesterday starts behaving badly or I can’t figure out how to configure it?

I think long term the answers to those questions should mimic the way these things are handled for PCs. The attempt to try to control the whole system of mobility from network to handset to user application resulted in the system we have now, and the whole thing needs to be supplanted with something more expansive. There’s a few things that probably go into that. There’s probably some degree of communal mobile user knowledge that needs to evolve. It exists for desktop systems, though for lots of us it’s so ingrained by now that we don’t see it. Users know what an email address is, they understand that when they install an application they should look for it in the start menu if they want to use it, that when they want to save a web page to use it later they add it to favorites, etc. Common user experience, frequency of tasks, shared understanding, and common sense all combine to make the stuff that people do frequently seem simple. And I don’t just mean “user education” here. I mean application provider and handset manufacturer education as well, cause it’s a two way street.

For an example take a look at the way that iPhone usage has pushed mobile to a different level. What happened with the iPhone was that the market potential for the device wasn’t set by how well the carrier could push services out to the end users. Instead, Apple decided what they wanted the phone to do, designed it the way they wanted it to work, and then marketed those functions directly to end users. Compare the iPhone commercials to the kind of stuff that Nokia makes to describe their products. Very different stances. But it’s not just the marketing, it delivers on what it says. Using the web on an iPhone is simple and intuitive, using the maps app is the same. It wasn’t designed by a committee, which is how a lot of the current phones on the market feel. It was designed with a strong and consistent hand guided by the practicality of the end user, not a reduction in support call costs. And the difference is obvious top to bottom.

I’m curious what else is going to come around and what else changes in this version of mobile. Are the rest of the device manufacturers going to follow suit and rethink their devices now that Apple has shown that it can be done different? I think so, which leaves the door wide open to get more open platforms into the mix. When I bring up OpenMoko frequently I hear responses from people that are tied to the “accepted knowledge” from that old environment. But I think it’s been proven that a single vendor with a strong vision, consistent implementation, and messaging to the end user can make a difference. So really all the arguments against a major disruption in the mobile devices market are pretty well voided at this point. And we have so many efforts lowering the bar for getting a new device out in the market. That could get really interesting really soon.

I’ve been wondering a lot lately about search indexes and mobile content, and the reinforcing effect an established web index can have on the growth of any new channels. I’ve been paying particular attention since Google changed to a unified index for web and mobile searches a few weeks ago. It used to be that as a publisher providing both web and mobile content the only way to really make sure that my stuff would get indexed properly was to create a mobile sitemap for my mobile pages and inform Google of it as an explicit set of mobile pages. Now I’m not sure what to do.

My initial interpretation of the decision was that I should rely on the handheld media type alternate link to let Google know about the mobile version of pages, and rely on Google just indexing the main web version in order to find the mobile version. Makes sense, but what do I do about not having the mobile sitemap there to inform Google about the structure of my site? For instance normally there’s an indexing penalty associated with having duplicate content. Well, my web version and my mobile version are duplicate content. How much does Google use the linking from main web version to mobile version? Should I deny the Googlebot access to the mobile version in order to make sure that the web version doesn’t get penalized?

And of course there’s the problem of mobile only content. While folks can use the loopback handheld media type link hack to keep Google from transcoding their pages, how does that affect their indexing? Say that my statement from the paragraph above is true and Google uses the handheld media link to determine when duplicate content is actually a valid duplication. What does it do when the page points to itself? On our pages at Mowser we have a web version and a mobile version. The web version points to the mobile version as an alternate. The mobile version points to itself. That’s so that if the mobile version ends up in outside search indexes the page won’t get double transcoded. However I don’t have a good understanding of what that does to index ranking.

The layout really seems to encourage Google’s position of dominance with respect to search on the whole. By smacking their index together and refocusing people on increasing the ranking of their web content and relying on media linking to find the mobile version it really makes it hard for upstarts focused on making better mobile search to get any attention at all out of content owners. And with all the uncertainty around the behavior of Google’s index some of us are actually trying to hide away portions of our mobile content in order to figure out how to get the Google index to behave the way we expect it to. While Google controls the lions share of searches online, who would muck around with their content and endanger their position in the Google index in order to increase their ranking in the much lower utilization mobile specific indexes? Besides Russ and I at least. Although I love what the Google folks are doing for mobile in terms of GMail, and Gmaps, and Android - this whole issue around mobile search and advertising gives me the creeps.

Let me give a concrete example of something we just haven’t figured out yet. We have a directory of feeds at Mowser, organized by topics, rendering summaries and providing an adapted version of the full site if the user clicks through. We figured it would be a nice way to introduce mobile users to existing content without having to go to each of the publishers. We give mobile users content, give blog owners new readers, yay! Right? The problem is Google isn’t picking up the pages for some reason.

Take for instance our mobile technology blogs page, a page very near and dear to me cause it includes the greatest website in the entire world (this one). Now do a search for “mobile technology blogs” site restricted to mowser.com. It’s not in there for some reason. It’s not even very link deep from the pages we directly expose in our sitemap. Why does that page not get picked up? Is the sitemap we have there in some way affecting the normal behavior of the Googlebot? It’s not like it isn’t pounding on the site all the time, it’s just not finding stuff. I thought that’s what it was supposed to do.

Obviously, it’s Google’s site and Google’s index and Google’s users so they’re free to do whatever they want. For once I’m not going to bitch and tell them what they should do. But I do think a little extra transparency here would go a long way toward helping us figure out what we should be doing. Even just going through and whacking anything that’s old and outdated from the Google support section might help. Is the mobile sitemap even supposed to be used any more now that the index is unified? The information available for webmasters seems to be really conflicted now.

I was poking around a bit today with identifying mobile search traffic. I dumped a few million records out of the Mowser traffic DB and parsed through the referer URLs to pull out keyword info from searches that land on Mowser pages. First things first, I wanted to share. So here’s my current version of a mobile search term referer parser. I just wanted to get that out of the way cause I’m starting to get tired, by tomorrow I might forget about what I did if I don’t post it.

There’s a lot that’s different between the mobile world and the web world currently (and it’s all headed for what’s sure to be a noisy, violent, and I’m betting pretty damn interesting collision). In the online world Google owns most of the search market, for better or for worse. However on the mobile side many service providers are building out their own search index, usually licensing some technology from someone to run their own site or white labeled version. Say what you want about Google, but at least as a property owner I know how to get search traffic to my site: get ranked on Google. What does the world look like off-deck if every operator keeps building out their own search index? How does it affect end user perception of search as a service as well if every service they try out works different?

Also, how as a site owner do you attempt to tune your site for search traffic when many of the search services that are driving users to your site aren’t available unless you’re a customer of the same carrier? Check out these referers I have from Mowser:

• Mycricket
• Orangeworld

If I can’t even see the pages it really makes it difficult for me to understand traffic flow to my site and attempt to tailor my content appropriately. Carrier searches are actually driving a pretty decent amount of traffic still, but already they’re lagging behind Google in terms of driving numbers. Carrier search is only going to get worse by comparison, especially as higher capability devices work their way out into the market and folks begin expecting their mobile search to work like their desktop search (because that’s the way the rest of the web does).

This is just another one of those issues where we’re probably going to have to suffer through long and painful process of carriers finally coming to understand search after multiple failed and user-frustrating attempts. I’m not saying that mobile search isn’t different than web search. But if you’re going to run a web service run it out on the web. Pay attention to all the people who are affected (and who can help you improve your service). Operators: going off and running web search with everyone having their own instance off in their own little tidepool is stupid. Please stop doing it.