(Skip to main content.)

Blogs Quoderat Land and Hold Short

Quoderat

Archive for July, 2009

Lessons about web sites for mobile browsers

Thursday, July 30th, 2009

Working on ourairports.mobi, the mobile version of OurAirports, I’m getting a crash course in writing for mobile browsers. Here, in no particular order, are some of my lessons:

  • The OpenWave browser is horrendous, ignoring character encoding, randomly skipping some simple CSS, etc., but it’s one of the most common on small cell phones, so you have to live with it.
  • Some Nokia browsers will accept a 302 redirect but consider a 303 to be an HTTP error.
  • Cell phone browsers all seem to display the title element at the top of the screen, so if you have the same text in title and h1, it will appear twice, probably filling the whole first page. If I leave it out, though, what happens on bigger screens like the iPhone or Blackberry?
  • Breadcrumbs are a bad idea for mobile pages, because they use a lot of screen real-estate on a cell phone. I might move mine to the bottom.
  • Making too many things into links is a bad idea, because it takes a long time to scroll though them.
  • Even small graphics take a long time to load. If there’s no good reason, don’t make people download any. Including your corporate logo is not a good reason. Use colors instead of graphics when you can.
  • OpenWave (and, I assume, other browsers) do not choose intelligent default font sizes for h1, etc. — they’ll fill the whole screen if you don’t change them with CSS.
  • When only a couple of dozen words fit on a screen at once, verbosity is a bad thing. Ask yourself “can I say it with fewer words”? Then do the same thing four or five times more. I’m still working on that.
  • Short previews are a good idea for things like comment lists, to save scrolling time. Leave out as much as possible (for example, I don’t give the date of a comment unless the user views the full comment).
  • Always including “jump to” links at the top of every page to save scrolling.
  • Extra stuff you’d normally put at the top of a web page, like a search box, login info, home link, etc., belongs at the bottom of a mobile web page, so that users don’t have to scroll past it to get to the content.

I’ll add more as I discover it.

Costing out Google App Engine

Saturday, July 18th, 2009

The Google App Engine (GAE) is the newest of the major cloud computing platforms for hosting web applications. I’ve been experimenting with it for a couple of days, and will post my impressions later. For now, I thought it might be interesting to try to make sense of the pricing.

Unlike many of the other platforms, GAE starts out free. Only when you pass the built-in quotas do you start paying for infrastructure usage.

Google has designed its free quotas to allow approximately 5 million pageviews per month. Before we look at what Google charges for passing that limit, let’s look at this number from a business perspective. (Obviously, it will vary wildly depending on what a site does: a well-designed, read-intensive site might be able to get 10 million pageviews or more without passing the quota, while a poorly-designed, write-intensive site might struggle to fit in 1 million. We’ll just stick with Google’s estimate for now.)

Free quotas and the boutique web site

There are many ways for web sites to earn money, and some (such as membership fees) don’t correlate directly with pageviews. Let’s assume, though, that like most web sites, yours is advertiser-supported. In that case, the most important number to you is your eCPM (effective cost per mille), the mean revenue you earn for every 1,000 pageviews. Some people claim very high numbers for this, like $20 eCPM, but they’re usually talking about either a low-traffic site, or what they get for a few premium direct ad sales before they splatter the rest of their pages with low-paying filler from ad networks. When you average everything out, stick with sites with monthly pageviews in the millions, and consider all pageviews rather than just premium ad sales, about $0.50-$2.50 eCPM seems like a typical revenue range from my experience consulting with big and small companies.

A web site receiving 5 million pageviews/month, then, with ads on all the pages, would be earning ad revenue of $2,500–$12,500/month, or $30,000–$150,000/year. Google has obviously chosen its free-quota cutoff carefully: that’s enough to support one person working on a boutique web site, or maybe two people working on the site part time, but not enough to support even a small company with employees, rent, etc.

Still, why is Google offering this for free while Amazon, for example, isn’t? It’s the ad revenue.

Google runs what is by far the most popular web site ad network, so the odds are that most web sites on GAE will also be running Google ads. Since Google keeps about 25% of ad revenue (at least back in 2006), a site hosted on Google App Engine for free, bringing in $75,000/year for the site owner in revenue from Google ads, likely generates about a $25,000/year ad commission for Google. If AWS allowed a similar free quota, all they’d do is generate $25,000/year for Google as well, not for themselves.

Other issues

Of course, that doesn’t mean that you’ll make much money — it’s surprisingly hard to get a site up to even 100,000 pageviews/month, much less millions (and $100/month in ad revenue isn’t going to pay your rent) — but at least you’ll be spending your time worrying about the content and usability of your site, rather than the infrastructure, like most startups do.

Still, GAE isn’t necessarily the best choice, yet. I’ve spent a couple of days experimenting with GAE to see if it can support my OurAirports web site (75,000 pageviews/month), with mixed results. Because GAE has to operate transparently in the GFS/BigTable cloud, its free or low price comes with a lot of constraints: the datastore is missing many basic features I rely on in a relational database (e.g. views, joins, and referential integrity), there’s no local filesystem access, no threads, and extremely weak support for backend computation such as aggregating information or importing data.

It used to be that you could use any programming language you wanted on GAE, as long as it was Python. Now that GAE also supports a Java Virtual Machine (with some restrictions), you can run not only Java, but any JVM-based language such as JRuby (as long as it complies with GAE’s JVM restrictions), but you still can’t just dump a PHP app onto GAE and have it run: you’re basically going to have to rewrite the app from scratch.

There’s also the problem of putting your eggs in Google’s basket, so to speak — the 6+ hour outage last month made it clear that cloud computing doesn’t guarantee better uptime than a dedicated server. And if Google suddenly decides to increase their rates, it may be very difficult to move your code and data to a different site, unless you take very advanced precautions.

If you can live with the constraints, though, the pricing is certainly right.