Wozniak: …By the way, I solved the problem of battery life and [the lack of] multitasking on the iPhone.
Interviewer: Really?
Wozniak: Yeah. I just have two iPhones, so if the battery runs down on the first one, I can use the other. And if I’m talking on one, I can use the other one to look something up. You would not believe how much use I get out of that.

Perhaps my idea wasn’t so far-fetched after all.

Sure, ditching your current setup and replacing it with multiple tablet computers would mean quite a change in how you use your computer. But many people would likely be perfectly happy with the alternative. Like those people, for example, who are ordering iPads faster than Apple can manufacture them.

With iPads having neither a keyboard nor a mouse and being small enough so that you can have several of them in front of you, I imagine switching between them should be a snap. Also, the added screen real estate of what is essentially a multi-monitor setup should also make it easier to work with multiple apps at the same time.

Of course, this idea is not new at all. You may have even seen it on TV decades ago. A user called derefr left the following comment over at HackerNews when I mentioned my idea:

[Using multiple iPads] makes complete sense to me—remember the scenes in Star Trek where someone is sitting at a desk absolutely covered in PADDs, each doing one little thing? We just need to wait for the price to come down :)

Being located in Europe, coming across even one, let alone two or three iPads has proven to be a bit difficult for me. So if someone reading this has had the chance to try working with more than one iPad at the same time it would be great to hear how well it works and what problems you’ve run into.

Not sure what I’m talking about?

Let’s take a look at the browser, for example. Just entering a new URL requires you to go through 3 different screens:

By the time you can start typing it feels like you’re already in a different application¹. Switching to a different window also involves going to a special part of the application designed to handle this single task.

This pattern is not limited just to the browser. Entering an address in the maps application or searching the list of your contacts also involves going through several steps.

Back to the browser…

If you take a look the UI of a regular browser you can immediately see a number of frequently used elements such as the location bar, the back button and tabs for switching between windows. Those UI elements are always visible and usable with a single click. On mobile devices things are a bit different. Because of limited screen sizes most of browser’s UI is either eating away precious screen real estate (like on the iPhone) or is hidden behind a menu button (like on Android).

Except that because of the nature of menus, many of those features are not hidden just behind the menu button, but also behind an item on that menu.

Now, just as I’m typing this, Marissa Mayer is on the stage at TechCrunch50 introducing Google fast flip and talking about how Google is obsessed with speed and shaving milliseconds off of repetitive interactions. So what can can we do to speed up interaction with Google’s mobile browser?

First, we need to understand what’s wrong with menus.

A typical menu is a list of actions available for that application, but most of those actions can’t be performed from the menu itself. Instead, selecting an item takes you somewhere else where that action can finally be performed. In essence, a menu keeps asking the question “What do you want to do?” over and over again and the user then needs to explicitly say that he wants to go to to the place where he can type in an URL or go to the place where he can switch to a different window, etc.

How do we handle this situation where we know that in many applications the user’s answer to the menu’s question is going to be the same most of the time?

Like it is the case usually these days, the solution can already be found on the iPhone. No real surprise there. The iPhone doesn’t have built-in support for application menus which could be copied, but it does have this:

What you’re looking at is a special dashboard for controlling music playback, which can be brought up by pressing the home button twice.

With a bit of bad luck – or bad judgment – this could have easily been implemented as a list of items such as “adjust volume” and “control playback”, with each of them leading to a new screen where that action could be performed. But instead its designers made it possible to perform common actions directly from the pop-up and added a “Music” button that takes you to that other app where the rest of the playback controls are.

So let’s take this dashboard pattern and apply it to Android’s browser menu:

While some features (like bookmarks) still remain hidden behind a menu button, the two most commonly used ones are immediately presented in usable form. The “go” button is replaced by an actual location bar and the “Windows” button is replaced by thumbnails of windows. You now no longer need to announce first that you want to go to a different page or switch to a different tab; you can perform that action directly instead.

A quick before/after comparison:

Removing a single step here and there may not seem like much, but it adds up. Making a typo in the URL or working with several windows suddenly becomes just a little bit less frustrating. A simple improvement that can be achieved simply by ignoring the established meaning of the word “menu”.

This problem should be easily solvable in our age of ubiquitous connectivity, right? All I had to do was take out my mobile phone, fire up the web browser, check the shop’s website for the address and locate it using Google maps. How hard could that be? Very hard, as it turned out.

The experience of trying to perform this task was so horribly bad that in the end I wound up walking to Apple store a couple of streets away and waiting in line for a display iMac so that I could find the information I needed, copy it to a piece of paper and finally walk back. Yes, that was in fact a better alternative to trying to accomplish anything using a mobile browser.

A year and a half has passed since, but things haven’t changed much for the better. Even though connection speeds have gotten better and hardware is now much faster, the gap between mobile devices and computers is still huge and browsing the web on a mobile device can still be rather frustrating experience. Unlike computers, which these days have large displays running at high resolutions and are coupled with mice which give users pixel-accurate cursor control, mobile devices still have tiny touch screens and pointer accuracy of around 400 square pixels… if you’re lucky enough to have pointy fingers.

And despite their differences we use both types of devices for accessing the same websites.

So you’d probably think that browsers running on mobile devices with their tiny screens, clumsy keyboards and imprecise pointer control would be the ones getting all the usability improvements and fancy automated features. But you’d be wrong. What’s curious to me is that despite the fact that mobile devices are the ones with highly obvious usability problems, desktop browsers – which are already much easier to use – are the ones getting all the improvements. Autopager, Adblock, Greasemonkey, Stylish, Readability/Tidyread, Bookmarklets, Web slices, Accelerators and many others are features mobile users can only wish for¹.

What about usability features specific to mobile browsers? Apart form the “.com” button on iPhone’s virtual keyboard I really can’t think of any. As a matter of fact, I’m having a difficult time thinking of a single user-facing feature available in today’s mobile browsers that wasn’t already present in Netscape Navigator in the mid 90s².

So what can we do to bring mobile browsers into the modern times?

1. The single most important feature need by mobile browsers is support for extensions.

When was the last time you tried out an interesting mobile browser extension? I’d say never. Since most mobile browsers have no support for extensions whatsoever, you couldn’t do it even if you wanted to.

Once it’s possible to easily extend the browser anyone can start experimenting and adding features, but without that the existing browser is a dead end. Developers who want to add even a tiniest feature need to re-implement the whole browser functionality around the page rendering component. And I know from personal experience that doing this and then sneaking code for additional functionality in through the back door is a truly awful way of adding features. Not only is it a lot of work for the developer, but it’s also rather inconvenient and unlikely for users to try out a new browser.

2. Mobile browsers need to become content aware.

Now that the miracle of copy&paste has finally arrived to the world of mobile phones, performing some tasks like moving an address from the browser into the maps application has become slightly easier. But is this really enough to keep us happy for the next few years? Even on desktop computers where performing such a task takes only a second, copying from the browser and pasting into another app is no longer considered good enough.

Internet Explorer 8 now supports accelerators (so does Firefox, via IE8 Activities add-on) which perform such tasks for you. They are not perfect, of course. One problem is that all accelerators are offered every time, even if they make no sense in the given context:

Suggested accelerators don't always make sense

This same problem will be bigger on mobile devices – once and if they gain support for accelerators. I predict that more accelerators will be needed due to the limited nature of the devices, but displaying them all won’t work very well on small screens. Which is where content awareness comes into play. If the browser knew what kind of content you just selected it could present you only with options which make sense at that moment. Even better – most of the time selecting the text could be skipped altogether since the browser would already know where something starts and ends and could attach accelerators to that piece of content in advance. It could even grab new accelerators online if it determines using them would make sense.

There are several ways content awareness could be implemented. Microformats and RDFa immediately spring to mind, but since they are about as common in the wild as pink flying giraffes, some other solutions would need to be found. Alternatives might include external content descriptions and extraction rules (possibly crowdsourced), downloadable sets of algorithms for detection, data extracted by services like YQL open data tables or NLP services… But more about that some other time.

What I believe is important is that this content recognition should be performed by a centralized framework and available to all extensions so they don’t need to do their own parsing. Some basic work in this direction has been done with the Operator toolbar and Firefox’s support for Microformats, but in my opinion such functionality is much more needed in mobile browsers.

3. Browsers need to start detecting and exposing available extensions

You’re visiting a page that contains several events which can be added to your calendar and a table which can be displayed as a chart. Someone has created an alternative stylesheet which removes the huge header and there is also a mobile widget which allows you to interact with he same service in a more mobile-friendly way. But you’re never going to know about them and use them if your browser doesn’t notify you about their existence and make it easy to install and use them.

4.  We need support for client-side content modification

Some might disagree, but I believe we do.

How many times have you had to zoom in just so you could click the link to the next page in a sequence of pages, or pan around to find where that huge header ends and content starts? You don’t need to put up with any of this if you’re browsing the web on a computer. All sorts of common annoyances can be solved by simple tweaks, and extensions for desktop browsers have been making it possible to do this for years. By augmenting, modifying and filtering content they not only make it easier to access content you’re interested in, but also make it possible to ignore irrelevant parts of pages.

–

These are just some ideas about what the future of mobile browsers could look like. You might not agree with me on whether content awareness and even content modification are going to be important factors in the future of mobile browsing, but there’s one thing which is difficult to disagree with: a lot of work still needs to be done in order to turn mobile browsing into a user-friendly experience.

If you already have Mosembro installed, uninstall it first by running: adb uninstall com.lexandera.mosembro
The new version can then be installed by executing the following command: adb install mosembro-r2.apk

New features include:

• It is now possible to install addidional actions which extend Mosembro’s functionality.
• Addresses can be copied to clipboard.
• Improved security and various bugfixes.

Screenshots of new features:

Mosembro r5: dialogs for installing and managing installed actions

Several simple actions can be installed from the bottom of the demo page which is loaded when Mosembro starts up. Go & try them out.

If you already have Mosembro installed, uninstall it first by running: adb uninstall com.lexandera.mosembro
The new version can then be installed by executing the following command: adb install mosembro-r2.apk

Major changes from r1:

• Multiple actions can now be attached to a single link.
• Microformat parsing logic was separated from action logic. Each microformat is parsed only once now and parsed data is then passed to one or more actions registered to handle that microformat.
• Two new “travel to…” actions were added for addresses. One uses London Journey Planner and the other one uses Bay Area Trip Planner
• alert(), confirm() and prompt() JavaScript functions now work.

Here is an example screenshot of multiple actions on one link:

Multiple actions attached to one link

More screenshots and/or a video should be available in a couple of days.

Thanks to the fact that you can replace any piece of software on an Android phone – even the dialer, the list of missed calls and the notification window that pops up when you get an incoming call – it would be possible to replace those standard components with smarter ones which know how to fetch more information about the caller. So, instead of displaying “0315551234″, your phone could check the phone listings, your addressbook on Facebook, the list of everyone in your company and other sources to find out who’s calling. It could even fetch the person’s profile picture and display it next to their name. This way you could see all sorts of info about someone you haven’t added to your phone’s address book yet. Or, if it turns out that the call is coming form a telemarketer, it could simply drop it immediately.

Ribbit mobile appears to be doing something similar with their caller id 2.0. But somebody really needs to integrate a realtime version of this functionality directly into the phone software. And with Android, that’s actually possible! It might even be worth millions…

Speaking of which…

I performed some major surgery on Mosembro’s internals this past weekend. Scripts don’t do their own parsing of microformats anymore; instead, there are now dedicated parsers for each of the supported microformats. These parsers then call any scripts which might be registered to handle that particular microformat. This gets us closer to being able to implement support for installing third party scripts. It will also make it possible to attach multiple actions to a single event/address/etc., as shown on this mock-up:

Considering how small the codebase of Mosembro is, this shouldn’t take long to implement. Expect a new release soon™.

Meanwhile, if you have any suggestions, I’d be more than happy to read them.

At first, I tried replicating what the ring does by pushing on the same part of the can with the handle of a spoon. That didn’t work. Then I did the same thing again, except this time I tried hitting the handle with a meat mallet instead of pushing it down with my finger. That didn’t work either. Then I considered making a hole in the can with a knife, but decided against it at the last moment, as I really wasn’t in the mood for some early morning bleeding. It wasn’t until 5 minutes later, with the can back in the refrigerator, that I thought of the solution.

What do you use, when you’re dealing with an unopened can? A can opener, of course! It worked beautifully.

In retrospect, it all seems silly. But at that time, the connection between a malfunctioning can of energy drink and a can opener wasn’t clear to me at all, as I had never thought of opening a drink this way.

And normally, this would be it. I would fill my system with caffeine and go about my daily life without blogging about it. Except, this is not the only time something like this happened to me over the weekend.

While commenting on Daniel Appelquist’s predictions for 2009 the other day, I described myself as someone who had only recently developed interest in mobile. Which is completely false.

I wrote my first (and only) WAP pages using WML back in 2000. If you never created anything using WML, you should be glad, as you saved yourself some completely wasted time. That attempt at creating a separate mobile markup language was a long walk down a dead end street to nowhere. Then, at one point, I worked on an SMS based quiz. People would send in a message to start the quiz, to which the system would respond by sending them a question, and if they answered correctly, they would be entered into a drawing for prizes. I even bought a book titled “Learning wireless Java”, downloaded the J2ME SDK and created some MIDlets.

But all of this didn’t come to mind. Because that was the old idea mobile.

Mobile today is not about SMS messages and sandboxed Java applets anymore.  It’s about native Android and iPhone apps; it’s about beautiful design; it’s about mobile web, AJAX, web apps that look and behave like native apps; it’s about bigger screens, location awareness, voice recognition, augmented reality, and I could go on and on and on.

Today’s idea of mobile is so different in fact, that I completely failed to make a mental connection between it and my experience with the old idea of mobile.

So, if you are a web person (like me), who spent the last decade thinking that maybe you should get into mobile, don’t worry, as you haven’t missed anything. If you are someone who spent the last decade only in mobile, on the other hand, you probably missed a lot.

Mosembro, short for “mobile semantic browser”, is a proof-of-concept web browser for the Android mobile platform, which has integrated support for microformats. It was my entry for the Android developer challenge (but was called SmartBrowser back then), and while it wasn’t one of the 50 finalists who made it to the second round, it did finish in the top 25% of all entries, which is pretty good, I suppose.

The goal of this project is very simple: to make a better mobile browser with the help of embedded semantic metadata.

What does it do? It scans any loaded web page for microformats and inserts special links into it, based on any microformats it may have found. These links then enable 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.

Full feature list, demo videos, downloads and source code are available at the Mosembro project page.