Two widely lauded benefits of microformats (and semantic markup in general) are data portability and code reuse. A third benefit, perhaps not as widely accepted, is usability. Of course, it should come as no surprise that with data portability and better code reusability, the user experience within an application can be improved, yet the jump from the former to the latter isn’t an automatic one.
Anything that “just works” had to be made that way, and opportunities for integration aren’t always obvious. That’s why I got excited when I learned about Mosembro, a web browser built for Google’s Android platform, whose stated goal is to leverage semantic markup (microformats, in this case) to improve the usability of mobile web browsing. Its name is an abbreviation of “mobile semantic browser,” and its theory is simple: semantic markup means richer data, which means greater automation capabilities, which ultimately means greater usability.
Of course, there already exists software that has taken in-browser support for semantic markup to some interesting places. For Firefox, there is the excellent Operator extension that lets you do familiar things like export hCard data to your address book or easily find content related to the page you’re viewing on other popular sites. For Safari, there is the Safari Microformats Plugin, which does a subset of these same things.
So what makes Mosembro special?
Microformats Built into your Phone
Mosembro can do some of these things too, but this is the first time I’ve seen these functions integrated directly into a Web browser’s code base, and a mobile one at that. These sorts of features are arguably even more important in a mobile context than they are on the desktop, as Mosembro’s developer, Aleksander Kmetec, explains on his post introducing the browser:
[Mosembro] enable[s] the user to quickly perform tasks like looking up an address on a map or adding an event to his calendar. While manually performing these tasks is very simple on a computer, it can be pretty tedious on a mobile device without a proper keyboard, mouse, or even without the ability to copy and paste text.
Aleksander even provides a video of this challenge on Mosembro’s homepage to drive his point home. The video shows a timed comparison between using Mosembro to find locations on a map (that are marked up using adr or geo) versus using Google Android’s built-in browser. You can clock in at 5 seconds using Mosembro, while you’ll struggle to stay under 30 seconds using the default Android browser.
By far the most interesting feature Mosembro provides is a consistent search dialog for searching whole web sites
. Mosembro is able to detect the presence of a web site’s own search form (if it’s marked up using a specific, microformat-like pattern) and can present its own UI—in the browser’s chrome—to interact with this form. (The pattern Mosembro uses is visible on its demo page.)
The benefits of this quickly become apparent when the site’s search form is not immediately visible upon first loading the page, which isn’t an uncommon occurrence when browsing the Web with a mobile device. Furthermore, since many site’s search forms vary in location and appearance from site to site (and even between a single site’s redesigns), having a consistent search UI for the specific site being viewed could often be a helpful thing. Most of all, however, this is a striking example of how shared semantics between a web site and a user agent can be used to implement innovative features.
Semantic Markup is an Egalitarian API
Aleksander Kmetec adamantly states that Mosembro is merely a proof-of-concept application, yet a comparison between Mosembro and Apple’s Mobile Safari, the only browser available to users of the iPhone and iPod touch devices, is not far afield. Both mobile browsers tout usability as a prime feature, and both have some similar hardcoded behaviors.
For instance, Mobile Safari’s users will recognize the mapping behavior if and only if the service being used is Google Maps. Linking to http://maps.google.com/maps triggers Mobile Safari to pass along the query string to the built-in Maps application when the link is followed. Unfortunately, links that point to other services, such as http://maps.yahoo.com/ for instance, don’t get similar treatment.
While I don’t have any business objection with Apple’s “enhanced” treatment of links to Google Maps over links to Yahoo! Maps, I do wish my tools didn’t technically care what mapping service I preferred. (It’s no secret that Google and Apple work closely together, with Google CEO Eric Schmidt having been elected to Apple’s Board of Directors in 2006.)
Although Mosembro’s handling of location markup gets mapped by Google Maps as well, I can just as easily imagine it being routed through Yahoo!’s API. The point is that at the markup level, the location data itself should be vendor-agnostic, and http://maps.google.com/maps certainly isn’t. That’s the kind of abstraction necessary for data portability—and customized user experiences—to thrive.
Mobile Safari provides a number of special-purpose URL schemes that let it do special things with special markup. An example is the tel scheme, which activates a telephone call to the number specified in the URL. After being inspired by seeing Mosembro, I can’t help but wish that Mobile Safari could use the tel property of an hCard in addition to the tel scheme to make a telephone call.
Today, you could use HTML markup with both an hCard and a tel: link to achieve a similar result:
<p class="vcard">
<span class="fn">Meitar Moscovitz</span>'s <span class="tel"><span class="type">pref</span>erred number is <a href="tel:555-1234" class="value">555-1234</a></span>.
</p>
However, now you have to be wary of how user agents that don’t support the tel scheme will behave. You could hide these links in your site-wide CSS style sheet, possibly like this:
a[href^="tel:"] { display: none; }and then re-enable them only for Mobile Safari in a specific style sheet, but this is tedious and vendor-specific. Besides, you may want to link the telephone number to somewhere else that’s appropriate, such as an entry in an online telephone directory. Obviously a more integrated solution, where the browser itself understood the semantic markup, would be preferable.
Ultimately, Mosembro’s proof-of-concept is exciting not because the implementation is revolutionary, but because it helps to pave the road whereby front-end web developers can reach outside of the web page and begin to interoperate with other features of hardware and software that exists elsewhere. Consistent site-wide search UIs, integrated mapping, and telephone calls are just a few of the possibilities that sharing semantics between web pages and user agents can make possible. What other ideas do you have to better integrate user agents with the markup they download over the Web?
Meitar Moscovitz
