Monthly Archives: June 2009

Flickr launches browser-based geolocation

flickr nearbyOne of the most exciting features of OS 3.0 on the iPhone is Safari’s implementation of the HTML 5 spec for browser-based geolocation. This allows Web sites to ask the browser for the user’s location, a capability that  has largely been limited to device-specific applications.

This new capability allows for easier-to-use location-based services. Flickr has jumped on this with a “photos taken nearby” application that will show you pictures centered around your location. Click on the “Photos taken nearby” link at and you’ll instantly see a map of your location with nearby pictures.

The initial implementation is basic; you have no control of the pictures shown. It would be nice to see to search the nearby pictures for specific terms or to see pictures taken by someone. But as a proof-of-concept, it works great.

This is undoubtedly the first of many browser-based location services we’ve seen. Google has already announced that it will launch its Latitude service in a similar fashion. You can imagine other services such as local business search, movie showtime lookups, weather and local news provided automatically in the browser.

It’s a sign of how far we’ve come in mobile since the launch of iPhone 3G. It wasn’t long ago that I wrote asking carriers to set my location free. In principles of mobile design, I wrote “Don’t create an app if you don’t have to.” Now you don’t have to for location-based services.

My one complaint is that the browser sends back a very precise latitude/longitude. This is necessary for cerain applications, like mapping. But most applications don’t need that level of precision. Weather, for example, only needs a city level of precision. I’d like to be able to control what gets sent.

More on: geotagging

Fixing public transit with mobile technology

As gas prices have fallen from last year’s record levels, use of public transit is falling. It makes perfect sense: the cost of driving has decreased, so more people drive.

One way to get more cars off the road is to raise the cost of driving. Paul Kedrosky, Greg Mankiw and others have talked about raising the gas tax to make driving more expensive. It sounds great in theory, but it’s political suicide for any candidate who would seriously push it. It’s also a highly regressive tax.

Another alternative is to reduce the cost of public transit. There are four cost components to public transit: cash, information, time and transaction. We could build better transit systems with greater frequency like in Europe, but that’s expensive. Mobile technology provides a cheaper route.

Cash fare — Typically the cash fare will win over the cash cost of driving or alternatives such as cabs, especially when you factor in the cost of parking in the dense urban areas best served by public transit.

A San Francisco bus stop

This bus stop sign provides very little information. Technology could be used to provide detailed information on demand.

Information cost — Public transit systems are a usability nightmare. Maps don’t have enough detail to figure out where you’re going. You have to decipher dozens of multicolored lines with tiny numbers and then hope that the line runs when you want it to. DC’s Metro system just released a study of the usability of its bus stop signs with one of the findings that information was printed in 4-point type at some stations. And you might not even have a map; some bus stops just show a line number.

Google Maps on iPhone has made this easy. I stepped off a plane in San Diego and put in the hotel address. Google Maps told me which route to take, the fare and how far I’d have to walk. There’s still the matter of finding the bus stop, but that can be solved over time using crowdsourced geotagged photos like the one at right. Google recently announced transit information availability on Android.

There are also dozens of transit-related iPhone applications that focus on specific transit systems.

Time cost — Public transit is often slower than driving. A big part of that slowness is not knowing when the bus or train is going to arrive — the waiting is the hardest part. Real-time transit tracking on mobile devices can help. When I lived near DC, I could see on my phone when the next train was leaving. If it was 20 minutes, I could have another drink in the bar. (Paid for by my savings from not taking a cab.) If I’d been waiting in the Metro, that 20 minutes would have felt like 60, adding to the perceived cost of transit.

Nextbus offers mobile transit predictions using GPS devices installed on transit vehicles. Unfortunately, it’s not location enabled and it doesn’t provide the level of detail (including maps with the location of vehicles) that Nextbus offers on its Web site.

Real-time data can be crowdsourced on heavily trafficked routes. Every Caltrain during rush hour seems to have at least 40 iPhone users on it. A simple app could transmit current position, which could be shared with other riders. (There’s already a Caltrain Twitter account that uses crowdsourced data for service interruptions.)

The Kennedy is packed -- take the L instead!

The Kennedy is packed -- take the L instead!

Real-time traffic information can also help increase the appeal of public transit. Subways and regional rail are often faster in rush hour. When I last flew to Chicago I was about to step into the taxi line when I decided to check the traffic conditions. The Kennedy showed all red on Google Maps. I flew by all that traffic on the Blue Line for $1.50, instead of paying $40 or more in a cab.

Transaction cost — Transit systems use many different payment methods. On San Francisco’s Muni there’s cash, multi-ride coupon books, transfers, multi-day passes, monthly passes. Want to ride the bus and all you have is a $10 bill? That will be an expensive ride. Want to ride the Muni and then transfer to Caltrain? You’ll have to decipher a new system. See my recent experience trying to pay for a Muni ride.

This is the area that has seen the least progress. Some regional systems have been implemented or are in development. Being able to pay by credit card or cell phone at the turnstile would make this a lot easier. A “buy” button after I select a route on my cell phone with Google Maps would be ideal.

Combining easy routing with real-time arrival information and easy payment will help increase the appeal of transit to people who don’t have to use transit. That would help address an ongoing problem with transit in America: we view public transit as for poor people and fund it like we fund welfare. Get more people choosing to ride transit and we might have more widespread support for it.

Heck, if Apple ran ads showing people using iPhones to find public transit, it might even become hip.

Dash acquisition and the standalone navigation market

This week it was announced that RIM bought Dash Navigation. I’ve written before about Dash. I’ve long been excited about the service, but Dash suffered from three big problems:

  • Bulky and expensive hardware — The device was nearly three times as big as most of its rivals. It’s weight necessitated an industrial-strength mount. The combination wasn’t something you could easily throw in your bag when traveling. At $399, the price was at the high end of the market.
  • High monthly service cost — Dash had a built in cellular modem, which added a steep monthly subscription fee. Many of the features that you might expect to see in such a beautifully engineered service — weather maps, videos, pictures of businesses — couldn’t be provided because of the high rates charged by wireless carriers.
  • Lack of distribution — Dash Express was available direct form the company and through Amazon, but never made it into the big box retailers where a lot of GPS units are purchased.

The RIM acquisition solves the first two problems. If RIM adapts Dash for use on Blackberrys, you won’t have to have a separate device and the service can ride on top of your existing data plan. Dash will be in a position to offer a better product for a lower price.

Distribution may still be a challenge; it’ll be interesting to see if carriers will allow RIM to ship a navigation offering that competes with their own. Two years ago I would’ve said there’s no chance; now I’m more hopeful.

Dash/RIM will face stiff competition. I expect that in the next two months we’ll see TeleNav, TomTom and others come out with turn-by-turn navigation applications for iPhone. (See my earlier post on what an iPhone-based navigation service could do.)

Between iPhone and Blackberry, this could spell the end of the standalone PND. The 2-way connectivity offers the ability to deliver a wide range of services that unconnected PNDs can’t offer: up-to-date business search, integration with Web apps like Zillow home prices and radio station finders, buddy finders, realtime traffic, gas prices, pictures of businesses, etc. Integration with the phone’s address book provides additional opportunities.

TomTom and Mitac have been struggling with rapidly eroding margins. Navigon has left the U.S. market entirely. If iPhone and Blackberry-based navigation take off, the standalone PND market may just be price sensitive consumers buying low end devices at Wal-Mart for $60.

Success of cell phones in the PND market will depend, in part, on the accessory market. We need to see car mounts that will let you charge your phone, serve as a speakerphone and let you transmit music from your phone to your car.

Disclosure: I worked on the distribution agreement between Tellme and Dash Navigation.

Principles of mobile design

Mobile is an exciting new space with the opportunity to create highly personalized, immersive experiences. Here are some of the principles I follow when designing products for mobile devices:

  • No shovelware — Mobile has very different constraints and user environments than the Web and your design should reflect that. Just as attempts to paste newspapers on to the Web failed, so will attempts to paste Web sites on to mobile. If a vendor pitches you a zero-effort solution that will automatically transcode your Web site, just say no. (The exception to this is mobile-specific templates for articles, blog posts, etc. stored in a content management system.)
  • Focus on the here and now — Mobile users are looking for quick hits and aren’t likely to engage in elaborate planning tasks. Focus on the key tasks a user is likely to be doing while mobile. When possible, show what’s going on when and where the user is. Make the server do the work instead of the user. For example, if your site has a conference schedule and it’s the middle of the show, you should have a page that lists the tracks that are happening RIGHT NOW instead of forcing the user to look through days of listings.
  • Don’t create an app if you don’t have to — Apps are great, but they also cause a lot of user friction. If you can accomplish the user’s goals with a mobile Web site, do that first.
  • Every click matters — The difficulty of input on mobile devices makes it all the more important to ensure that every click counts. Mobile sites should use personalization and location information to get the user to her goal as fast as possible. Provide quick links on your home page to tasks that the user has recently done.
  • Make every byte count — Wireless networks aren’t anywhere near the speed or reliability of home or work networks, making it even more critical to have tight pages without gratuitous graphics, headers, toolbars, etc. Many Web designers have gotten sloppy over the years as increasing broadband speeds have masked the slowness of their pages. You can’t do that on mobile.
  • Be forgiving — Phones sometimes do things like automatically capitalize usernames. Accept the capitalized username. (Assuming, of course, that your namespace is case insensitive.) Recover gracefully from dropped connectivity.
  • Auto detect mobile clients — If your mobile site is at “” and the user goes to “”, show the mobile version anyway. Deep links for stories, photos and other objects should also be rendered in the mobile version; if the user goes to “”, show “”. flickr does this correctly. The New York Times does not. But be sure to offer a link to the full version just in case your server guessed wrong. And cookie that state.
  • Be cross platform — Carry over user data between the Web and mobile. If the user searched for something on the Web, that search should be included in the history and typedown on mobile. Let users easily create reminders on their mobile device for things they need to do when they go to your Web site. (e.g. write a review, read a long article)
  • Think different — In the post iPhone era, handset manufacturers and carriers are providing more access to phone features than ever before. Designers have access to cameras, GPS, accelerometers, microphones and more. The best applications will take advantage of these capabilities to deliver experiences that can’t be created on PCs. For example, wouldn’t it be great if when you added a contact to your address book, it would automatically log where that happened?

Welcome to reDesign mobile

I’ve been working in wireless application design for more than 10 years and it’s really exciting to see wireless data take off. Mobile applications and widespread connectivity are bringing oceans of information to our fingertips. In the last year I’ve been more informed, eaten better, taken public transit more and been more adventurous than ever before. I’ve also been less bored and less lost.

The explosion in the availability of data and the creation of data is going to be transformative, perhaps more than the wired Internet. Realtime information from our friends, neighbors and sensors will allow us to be more efficient and avoid a lot of everyday annoyances.

There are challenges:

  • Network quality — Wireless networks in the U.S. aren’t nearly as fast or reliable as networks in the rest of the developed world. I’ve got a love/hate relationship with my iPhone. I love it works and hate it when I can’t use it because of network issues.
  • Filtering and alerting — With all of the content that is being created through mobile devices (tweets, photos, videos, etc.) sorting through it all to find what’s important is becoming a big problem and the tools that we have today are crude at best.
  • Platform overload — There are too many mobile platforms today. Developers have to choose among iPhone, Blackberry, Windows Mobile, Palm, Symbian. And that’s just the smartphones. It’s just not cost effective to develop for everything.

This blog will look at interesting (good and bad) applications of mobile technology and the good and bad of mobile user interfaces. If you have an application you’d like me to take a look at, please drop me a line.

My personal blog will continue to be an eclectic mix of pieces on social networking, search and media.