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”.

If you looked at OilCan – a Greasemonkey-like browser extension for Android – and Mosembro, you’d quickly realize that they have a lot in common. Both are experimental browser extensions which run on Android, both aim to make websites friendlier, both support installable actions written in JavaScript, and both make it possible for those scripts to modify web pages and launch other applications. And since looking at OilCan’s source code has allowed me to avoid reinventing the wheel at several occasions, some pretty obvious similarities can also be spotted at the source code level.

So, with so many things in common, how are they different at all?

The main difference, I believe, is what causes user scripts to be triggered. A typical OilCan script is triggered by a web page’s URL and is executed only once. Its goal is to change the content or functionality of a very specific document. Mosembro scripts, on the other hand, are triggered by embedded microformats and can be executed dozens of times for each page, while not caring about which page they were executed on.

I could say at this point that OilCan’s approach to invoking scripts could be compared to function calls in programming languages and Mosembro’s approach compared to what is done in aspect oriented programming, with functionality implemented by actions attached to bits of semantic content being cross-cutting concerns, but I’m not sure about it, so I won’t. ;-)

Also, because Mosembro is very narrowly focused on adding functionality to web pages based on semantic data embedded in them it can also provide additional infrastructure, like microformat parsers and action menus, which wouldn’t exactly fit in with a more general purpose framework. And finally, there’s the integrated support for site-level search.

So, there you have it. While it’s true that both apps have a lot in common, it’s their unique features that really matter.

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.

This can be achieved simply by registering a WebViewClient which overrides the shouldOverrideUrlLoading() method in which you tell the WebView to load a different URL from the one the user had requested.

The example below loads lexandera.com first, but when the user clicks any link on the page, he is redirected to yahoo.com:

WebView browser = (WebView)findViewById(R.id.browser);
browser.setWebViewClient(new WebViewClient() {
    /* On Android 1.1 shouldOverrideUrlLoading() will be called every time the user clicks a link,
     * but on Android 1.5 it will be called for every page load, even if it was caused by calling loadUrl()! */
    @Override
    public boolean shouldOverrideUrlLoading(WebView view, String url)
    {
        /* intercept all page load attempts and load yahoo.com instead */
        String myAlternativeURL = "http://yahoo.com";
        if (!url.equals(myAlternativeURL)) {
            view.loadUrl(myAlternativeURL);
            return true;
        }

        return false;
    }
});

browser.loadUrl("http://lexandera.com/");

Please note that calling loadUrl() does not trigger the shouldOverrideUrlLoading() method, which means that we do not need to worry about endless recursion when calling loadUrl() from within shouldOverrideUrlLoading()!

UPDATE: The above statement is no longer true for Android 1.5! Calling loadUrl() will now also trigger the shouldOverrideUrlLoading() method! This means that you need to make sure that you are not creating an infinite loop when calling loadUrl() from shouldOverrideUrlLoading()!

This example is a bit more complicated than previous ones, so let me explain it step by step:

• First, a class called MyJavaScriptInterface is defined. It implements a single public method showHTML() which displays a dialog with the HTML it receives as a parameter.
• Then, an instance of this class is registered as a JavaScript interface called HTMLOUT. The showHTML() method can now be accessed from JavaScript like this: window.HTMLOUT.showHTML(‘…’)
• In order to call showHTML() when the page finishes loading, a WebViewClient instance which overrides onPageFinished() is added to the WebView. When the page finises loading, this method will inject a piece of JavaScript code into the page, using the method I described in an earlier post.
• Finally, a web page is loaded.

final Context myApp = this;

/* An instance of this class will be registered as a JavaScript interface */
class MyJavaScriptInterface
{
    @SuppressWarnings("unused")
    public void showHTML(String html)
    {
        new AlertDialog.Builder(myApp)
            .setTitle("HTML")
            .setMessage(html)
            .setPositiveButton(android.R.string.ok, null)
        .setCancelable(false)
        .create()
        .show();
    }
}

final WebView browser = (WebView)findViewById(R.id.browser);
/* JavaScript must be enabled if you want it to work, obviously */
browser.getSettings().setJavaScriptEnabled(true);

/* Register a new JavaScript interface called HTMLOUT */
browser.addJavascriptInterface(new MyJavaScriptInterface(), "HTMLOUT");

/* WebViewClient must be set BEFORE calling loadUrl! */
browser.setWebViewClient(new WebViewClient() {
    @Override
    public void onPageFinished(WebView view, String url)
    {
        /* This call inject JavaScript into the page which just finished loading. */
        browser.loadUrl("javascript:window.HTMLOUT.showHTML('<head>'+document.getElementsByTagName('html')[0].innerHTML+'</head>');");
    }
});

/* load a web page */
browser.loadUrl("http://lexandera.com/files/jsexamples/gethtml.html");

WARNING
Unfortunately, this approach suffers from a major security hole: if your JavaScript can call showHTML(), then so can JavaScript from every other page that might get loaded into the WebView. Use with care.

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.

final WebView browser = (WebView)findViewById(R.id.browser);
/* JavaScript must be enabled if you want it to work, obviously */
browser.getSettings().setJavaScriptEnabled(true);

final Context myApp = this;

/* WebChromeClient must be set BEFORE calling loadUrl! */
browser.setWebChromeClient(new WebChromeClient() {
    @Override
    public boolean onJsAlert(WebView view, String url, String message, final android.webkit.JsResult result)
    {
        new AlertDialog.Builder(myApp)
            .setTitle("javaScript dialog")
            .setMessage(message)
            .setPositiveButton(android.R.string.ok,
                    new AlertDialog.OnClickListener()
                    {
                        public void onClick(DialogInterface dialog, int which)
                        {
                            result.confirm();
                        }
                    })
            .setCancelable(false)
            .create()
            .show();

        return true;
    };
});

/* load a web page which uses the alert() function */
browser.loadUrl("http://lexandera.com/files/jsexamples/alert.html");

Code for adding support for confirm() and prompt() is almost identical and can be found in Mosembro’s source code.

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.

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.

The solution is actually very simple: wait for the original page to finish loading, then inject your own JavaScript code into it by calling webview.loadUrl(“javascript:your-code-here”) when your webvew’s onPageFinished() event is triggered. Loading an URL beginning with “javascript:” is the exact same approach used by bookmarklets.

Here’s a simple example which loads a page and then sets its text color to red:

final WebView webview = (WebView)findViewById(R.id.browser);
/* JavaScript must be enabled if you want it to work, obviously */
webview.getSettings().setJavaScriptEnabled(true);

/* WebViewClient must be set BEFORE calling loadUrl! */
webview.setWebViewClient(new WebViewClient() {
    @Override
    public void onPageFinished(WebView view, String url)
    {
        webview.loadUrl("javascript:(function() { " +
                "document.getElementsByTagName('body')[0].style.color = 'red'; " +
                "})()");
    }
});

webview.loadUrl("http://code.google.com/android");

That’s it.

Please note though that alert() and confirm() JavaScript functions will not work unless you also register a WebChromeClient which implements the required methods.