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.

After a couple of minutes I came up with the following 2 use cases (in addition to the original standalone don’t block):

dont { ... }
dont { ... } unless (condition)
dont { ... } until (condition)

Implementing the dont { ... } part is easy. The only thing needed to make this work is a function which accepts a block of code and doesn’t do anything with it.

Adding support for the unles/until part is a bit trickier, but still easy. For this to work, the dont function must return an object which contains methods named unless and until. These methods then evaluate the condition passed to them and execute the original block of code if/when the condition is true.

It’s probably best if I just show you the code:

def dont(code: => Unit) = new DontCommand(code)

class DontCommand(code: => Unit) {
    def unless(condition: => Boolean) =
        if (condition) code

    def until(condition: => Boolean) = {
        while (!condition) {}
        code
    }
}

Now there’s nothing else left but to use it in an example:

/* This will never be executed */
dont {
    println("Hello? Can anyone hear me?");
}

/* This will only be executed if the condition is true */
dont {
    println("Yep, 2 really is greater than 1.")
} unless (2 > 1) 

/* Just a helper function */
var number = 0;
def nextNumber() = {
    number += 1
    println(number)
    number
}

/* This will not be printed until the condition is met. */
dont {
    println("Done counting to 5!")
} until (nextNumber() == 5) 

Runnig the above code should print:

Yep, 2 really is greater than 1.
1
2
3
4
5
Done counting to 5!

Nobody knows for sure what the future of NoSQL will be like, which way the development is most likely to head and who the winners will be, but we can still try and make some predictions. Here are mine:

Several subgroups will emerge
This is not as much a prediction as much as it is an observation of already visible patterns. At least two main groups will emerge from the NoSQL movement: networked data structure servers (key/value stores, queues, …) and databases for working with structured data.

The data structure branch will remain very diverse
Typical software in this category is rather minimalistic, both in terms of functionality and in terms of code size. Thanks to this the threshold for entry of new players is rather low; also low is the price paid by users for switching between competing implementations.
Various players will likely specialize in some technological niche and they will continue to be used mainly as means of speeding up applications and not as fundamental building blocks.

Relational databases will fight back
Some databases already have support for storing, manipulating and indexing structured data in the form of XML. I have a feeling that JSON support can’t be far away. For most users this will be enough to stay with the established players in the database field instead of choosing a strictly document oriented database.

Document oriented databases will morph into graph databases
Implementing cross document referencing will take them half way there. Pressure from the relational databases, as described above, will push them the rest of the way.

SPARQL will become the query language of choice
SPARQL is a query language for RDF¹; in other words: a language for querying graphs. It supports querying multiple data sources at the same time (federated queries) and there are projects underway to make it work with Hadoop clusters.
I’m not saying that alternative methods of querying will disappear completely! I’m just trying to say that the key players most likely to be used by the average developer (the next generation graph database equivalents of MySQL and PostgreSQL and similar) will end up standardizing on SPARQL instead of inventing yet another language.

Software will gain weight
Reading about NoSQL databases gives me a feeling of deja-vu. Most of it reads almost exactly like articles about MySQL from the beginning of this decade: “We’re better than competition because we don’t have transactions/triggers/datatype checking/guaranteed consistency/fulltext search/…”. MySQL now has all of those features and NoSQL databases will follow in the same path. Most users will start hitting walls due to lack of features, not due to performance issues and when that happens having features will become more important than being lean.

The cycle will repeat itself
After a decade or so a new class of players claiming that their lack of features is their strength will emerge once again

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

There’s an article hidden somewhere in that screenshot. Can you find it?

Content is no longer king. It is now a third-rate citizen; a stinky bait used to lure in visitors; a parasite eating away at precious advertising space.

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.

After developing some fat client applications using JavaScript frameworks I noticed how some code constantly repeats, making application footprint even bigger than necessary.
A while ago I (once again) stumbled upon article about helping the YUI Compressor. Article is great and in large client side applications could really make a difference in final footprint considering these tips. I think this should be automated as much as possible, so I extended a list of this tips which could be fully automated. And here comes in the YUI Compressor (YUIC).
I am using YUIC for code minification. I also contributed some fixes and suggestions to the author – Julien Lecomte. Those were implemented in past versions. YUIC is a great tool for code minification and munging. I believe it can be further extended and improved generating even smaller output. So here are my tips how to achieve this, ordered by complexity.

Concatenate static strings with +

If you have a big chunk of text to insert into page you would probably split it into multiple lines and making multiple strings. YUIC already has functionality concatenating static strings into one. So code like this:

var x = "This is " +
        "some text";

becomes:

var x="This is some text";

Don not use arrays for this, because YUIC cannot tell you are actually concatenating strings.

Variable declarations at the beginning of the function

Scope in JavaScript is per function. So if you declare a variable twice in the same function, second time variable is just overridden with new value. As JSLint suggests you should declare all variables at the beginning of the function. Looking at this from minification view this means only one var statement! So instead of:

function iterate(array) {
    var result = "";
    for (var i=0, len=array.length; i<len; i++) {
        var el = array[i];
        result += el + ",";
    }
    return result;
}

write:

function iterate(array) {
    var result = "",
        i, len,
        el;
    for (i=0, len=array.length; i<len; i++) {
        el = array[i];
        result += el + ",";
    }
    return result;
}

You should note when declaring global variables there is no need for var statement at all.

This as local variable

Writing serious JavaScript code means writing object-oriented code. In JavaScript we access object members in conjunction with this keyword. This means a lot of this keywords.

Person.prototype.getInfo = function()
{
    var result = "",
        i, len;
    for (i=0,len=this.length; i<len; i++) {
        result += this[i].name + " " + this[i]. surname + " - " + this [i].age;
    }
    return result;
};

Assigning this to a local variable means YUIC can munge local variable to a 1-3 letters which means smaller footprint.

Person.prototype.getInfo = function()
{
    var x = this,
        result = "",
        i, len;
    for (i=0,len=x.length; i<len; i++) {
        result += x[i].name + " " + x[i]. surname + " - " + x[i].age;
    }
    return result;
};

You should note local variable must be declared first, as we could access members of this object in the following variables declaration/assignment.

Person.prototype.getInfo = function()
{
    var x= this,
        result = "",
        i, len = x.length;
    for (i=0; i<len; i++) {
        result += x[i].name + " " + x[i]. surname + " - " + x[i].age;
    }
    return result;
};

You should also note using this as local variable is only reasonable when this keyword occurs at least two times per scope, but that is most of the time.

Shorten numbers

Although this seems to be strange it is simple to trim leading zero from decimal numbers. So instead of:

var n1 = 0.1,
    n2 = -0.1;

you should write

var n1 = .1,
    n2 = -.1;

Common strings

As with JavaScript frameworks and it’s hash style configs there is a lot of string repetition.

var form = new MyForm({
    id: "form",
    items: [{
        type: "text",
        cls:  "blue",
        name: "name"
    }, {
        type: "text",
        cls: "blue",
        name: "surname"
    }]
});

This code can be minified (in a inner scope) as:

var textString = "text",
    blueString = "blue",
    form = new MyForm({
    id: "form",
    items: [{
        type: textString,
        cls: blueString,
        name: "name"
    }, {
        type: textString,
        cls: blueString,
        name: "surname"
    }]
});

A special caution must be given to a strings declared as variables as they can be changed. So we cannot use this variable as a constant. These two strings should be separated into two variables unless we are sure value has not been changed until constant string usage.
We could go even further by moving common strings to outer most scope which uses this string and accessing it in inner scopes with closures and even further replacing substrings (in this case »name«). This raises a question about performance penalties doing string concatenation.

Repeating access to object members

function focusInput()
{
	if (this.msgInput) {
		this.msgInput.focus();
	}
}

this could without any problem been written as

function focusInput()
{
	var msgInput = this.msgInput;
	if (msgInput) {
		msgInput.focus();
	}
}

Shorten object’s member access

JavaScript libraries have a nice namespace convention, but in a large usage of library you get a lot of code repetition.

var store  = new Lib.data.Store(),
    record = new Lib.data.Record();
store.add(record);

We can see a common namespace is Lib.data which can be shorten by assigning to a variable

var Data   = Lib.data,
    store  = new Data.Store(),
    record = new Data.Record();
store.add(record);

There could even be further improvements if we are dealing with (static) object which does not have this key word in the function. Good example is the utility function JSON.stringify(), which can be assigned to a local variable.

var toJSON  = JSON.stringify,
    result1 = toJSON(obj1),
    result2 = toJSON(obj2);

Shorten object’s member names

While using namespaces is good in an organizational way it means a lot of code for just accessing object. The idea is to shorten object’s member names. So instead of

function Person(name, surname)
{
    this.firstName = name;
    this.lastName  = surname;
}
Person.prototype.getFullName = function()
{
    return this.firstName  + " " + this.lastName;
};

code looks like

function Person(name, surname)
{
    this.a = name;
    this.b = surname;
}
Person.prototype.c = function()
{
    return this.a + " " + this.b;
};

This is only reasonable for automated process, although keeping short member names can also save a lot of bytes.
You should keep in mind that you must replace member access in all places, this means where they are defined (set) and used. You also cannot shorten reserved members such as Array’s length or documents getElementsById.
So a good idea would probably be keeping a white list of members which should (not) get munged.

I was already doing some work in YUIC about variable declarations at the beginning of the function, shorten numbers and common strings, but it is not 100% stable, although I successfully minified some of the JS libraries.
Also I did not measure any performance penalties of these tips, but it would be interested to see some.
You should note that this would best perform if code is also JSLint compliant.

Wolfram Alpha is not a Google killer!
Wolfram Alpha is not a Wikipedia killer!
Wolfram Alpha does not want to dismember any company and bathe itself in its blood!

Please ignore unimaginative claims made by linkbait authors. Let’s forget the 1999’s prehistoric “me kill” mentality and focus instead on more peaceful opportunities. We now live in the age of mash-ups, so here’s my modest proposal for symbiosis between Wolfram Alpha and Wikipedia.

The opportunity for symbiosis comes from their different strengths. Wolfram Alpha’s FAQ section gives a very clear description of how it compares to Wikipedia:

Wikipedia gives you pages of narrative about topics. Wolfram|Alpha computes answers to specific questions you ask, just giving facts, not narrative. Wolfram|Alpha often includes sidebar links to Wikipedia.

Wikipedia describes a concept; Wolfram Alpha gives you the ability to try out that concept in practice.

And because everything needs a car analogy…
Wikipedia is like a car magazine and Wolfram Alpha is like a car simulator. You can open a magazine and read more about a car you just took for a virtual test drive, or start with the magazine and go for a ride in a car you just read about.

You can see in the above quote that one-way links from Wolfram Alpha to Wikipedia already exist. What’s still missing are connections from Wikipedia to Wolfram Alpha, which might one day look like this:

A hypothetical Wolfram Alpha / Wikipedia mash-up. Click for full size.

There you have it. Wolfram Alpha and Wikipedia can not olny coexist peacefully, they can help each other. No need to argue about who is going to kill who.

While most commenters see his rant as a sign of the old man slowly losing his mind, it is also a sign of another thing: filter failure. Filter failure is what causes information overload and was also the topic of Clay Shirky’s Web 2.0 Expo keynote in NYC, which you can watch below:

So what’s happening here?

RSS readers are partially recreating the conditions which make reading email such a chore. They require you to check them every so often, read all the messages and make sure that the number of unread messages goes down to zero and stays there! But it never does. Every time you check your reader, there are new messages waiting and demanding your attention, even though they don’t really need it. Posts worth reading are lost among dozens which are not. After a while you start drowning in a flood of content you’re not interested in, you become overloaded and you don’t even bother unsubscribing from the feeds, you just stop checking your RSS reader altogether.

You switch over to twitter where all the links you see are already pre-filtered by other people. Think about it – in order for a link to end up in your Twitter stream, somebody must have already read the article and decided it was worth sharing. In addition to this, your previous experience tells you whose links are worth clicking and whose not. And yes, there is a new lump of messages waiting for you every time you log into Twitter and their number is very likely to be overwhelming, but Twitter has no “unread count” which would force you to check every single tweet and doesn’t have a “mark all as read” button which would make you feel like you were missing something every time you used it. It allows you to check as many messages as you want to and doesn’t demand anything from you.

Or as Stephen Baker puts it:

On Twitter, each of us can recommend a link. If you have 500 followers, maybe 50 of them see it. Maybe five of them take a look. Let’s say two appreciate it. The other three may be less likely to open your links in the future. Maybe one will “unfollow” you. But that’s ok. Each of us finds our own audience. But the key is that there’s little guilt or obligation associated with Twitter. It’s a managed pool of serendipity.

In some cases filters alone are no longer enough to avoid information overload. We also need a way of ignoring what can safely be ignored.

Here’s a quick overview of the situation.

Named parameters in URLs: BAD
http://domain.com/list?type=fruit&page=1&items=20

Positional parameters in URLs: GOOD
http://domain.com/list/fruit/1/20

Named parameters in function calls: GOOD
foo.list(:type => “fruit”, :page => 1, :items => 20)

Why is this so? It might have more than just a little bit to do with the fact that coders spend a lot of their time reading, writing and modifying function calls, while URLs are only rarely modified by anyone (or even read, for that matter). The need to modify URLs is so rare in fact that many security holes exist only because developers never even remotely considered that someone might insert an unfriendly value into one of the parameters. It makes sense then that if URLs are only meant to be looked at, to make them short and pretty and clean of any characters which make them appear as if they’ve been involved in an explosion at the ASCII factory.

Why then is the URL, this unfriendly sequence of characters, still presented as a fully editable value? Is it really not possible to turn it into anything more than a barely readable “you are here” sign?

Microsoft managed to do something interesting with the way directory paths (URL’s distant relatives) are displayed in Vista and Windows 7: each directory is a separate button and clicking any one of them takes you directly to that directory.

Two different ways of displaying the same directory path

Couldn’t something similar be done for URLs? Here’s my suggestion: make it easy to experiment with different parameter values. Hide all the “noise” characters. Turn each key/value pair into a button and offer alternative values when somebody clicks them.

Now, this might not catch on with your average Joe Streetperson, but it does look like it could be useful to developers when they are testing a website or a web service which returns different XML/JSON based on parameter values.

Think of it as Intellisense for the location bar.

Currently, all attempts at providing semantic metadata require server-side changes which means that we need to rely on page authors to implement them. This, of course, is a major obstacle. But what if we could change that? What if we could bypass page authors and have the crowd add semantic metadata to existing pages?

I believe that this is more than possible.

Semantic metadata would usually be added to web pages by adding additional attributes to HTML elements or creating new elements where needed. But as it turns out, existing web pages are already broken up into a surprising number of elements, so why not just use these?

Let’s take this search result from Amazon as an example:

Relax, it's just a mock-up. Let's please resist arguing about the correctness of the labels.

Everything in the above image you see having a blue border is already a separate HTML block, addressable using an XPath expression. In order to attach a meaning to a block, we could use this XPath expression and associate it with a meaning, like this:

//div[@class="productData"]/div[@class="productTitle"]/a = “Book:Title”

Behind the scenes URIs from an OWL based ontology would be used instead of simple text labels. These mappings could then be uploaded to a server and made available to anyone.

So let’s forget forget about convincing thousands of web developers to learn and start using semantic markup. Forget Microformats. Forget RDFa. Everything about the semantic web boils down to one thing: reusable data. And existing data already published on the web can be made reusable by the crowd, using simple tools. Within a year we could have thousands of reusable semantic data sources!

Possible uses

Once we have a large collection of rules for determining what the data inside a certain HTML block represents, what can we do with them?

We can begin by creating an application which knows how to extract data from web pages and transform it into various formats like the original HTML with RDFa mixed in, pure RDF, RSS and others. That’s right – we can still have RDF and therefore compatibility with existing and future data published in the same format! This would also create a business opportunity for hosted RDF services, similar to how Feedburner is hosting RSS feeds. A service could even be created for hosting SPARQL endpoints.

What about some uses that would benefit the regular people instead of just linked data nerds?

I believe that one area which desperately needs semantic metadata is mobile web browsing. Limited screen sizes and tiny or even virtual keyboards make tasks which are trivial to perform using a desktop computer a real chore on mobile devices. With semantic metadata, mobile browsers could be much more context-aware and could offer a better browsing experience. Please see my experimental browser Mosembro for more information on that topic.

Some other things which would suddenly become easy to implement:

• Automatic browser-generated mashups. Put a map next to any address, a “find on Amazon” link next to any book, etc.
• Ad-hoc personal search and comparison engines: search all international Amazon stores, search used car ads on multiple sites or find all the 26″ screens costing less than 400€ by pulling in data from several electronics retailers and then filtering it.
• Autonomous agents that notify you when one of your favorite travel agencies posts a last minute offer that matches your criteria.
• Site-level search integrated into the browser (by using semantically tagged search forms). I never want to use browser’s “find in page” functionality again just to locate the search form! And since there would also be semantic metadata for search results available, local search results could then be combined with Google search results for that same domain.
• Autofill for all kinds of forms.
• Custom RSS feeds from any source, filtered by any set of criteria. (show Hacker news feed filtered by your favorite posters, or only posts with more than 5 comments)
• Backup tool for your data stored in web apps: store tagged content in a reusable format; then import it into another app (which can also be automated using tagged input forms).
• Data portability
• Pretty much anything else promised by Microformats and RDFa advocates. The list goes on and on.

I suggest you also have a look at demo videos for the Aurora browser concept, as they are full of great examples of what would be possible if lots of semantic metadata was available.

At this point you might be thinking: “This sounds nice and all, but it’s never going to work”, so here’s a closer look at two existing browser extensions which are based on similar approaches.

Extension 1: Autopager

Autopager is a Firefox extension which automatically loads the next page of a site inline when you reach the end of the current page. It’s interesting for us because it uses XPath expressions for addressing HTML blocks, user generated rules and a central server for sharing those rules.

In order for it to do its thing, Autopager only needs to know two things:

• which page element is the link to the next page
• which element represents the contents of the page.

This is done using XPath expressions, like shown in the image below:

Autopager is very popular and is an excellent proof that this approach works – at least for simple tasks such as sharing rules for locating the “next page” link.

Extension 2: Intel Mash Maker

Intel’s Mash Maker is also a Firefox extension and it comes remarkably close to the idea described above. Poking at the JSON encoded data returned by its web service reveals that it also uses XPath expressions for addressing HTML elements. It also makes it possible to further narrow down the selection using regular expressions to only capture a part of the element’s contents. The part where it falls short, though, is that it only uses plain text lables instead of URIs for defining the meaning of blocks. This unfortunately makes the definitions pretty much unusable outside of their mashup platform.

Unfortunately, the project appears to be dead or on hold. The newest user contributed mashup is more than two months old and the latest blog entry was posted more than a year ago. But it still is worth checking out and it does prove that this approach can be implemented to handle more complex situations than those from the Autopager example.

Finally…

There you have it, folks: a simple and straightforward way of solving the semantic web’s chicken and egg problem if perfectly within our reach.

The question now is who would be willing to sponsor such a project?

Let’s have a quick look at what I’m talking about.

If Java Swing libraries supported this kind of coding, then the following block of java code, copied from a random blog post, could be rewritten from this repetitive sequence:

JFrame mainFrame = new JFrame("Hello World");
mainFrame.add(label, BorderLayout.CENTER);
mainFrame.addWindowListener(new MainFrameListener());
mainFrame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
mainFrame.pack();
mainFrame.setLocationRelativeTo(null);
mainFrame.setVisible(true);

…to this chain of methods:

new JFrame("Hello World")
    .add(label, BorderLayout.CENTER)
    .addWindowListener(new MainFrameListener())
    .setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE)
    .pack()
    .setLocationRelativeTo(null)
    .setVisible(true);

It’s amazing how much cleaner the code looks just by eliminating all those mainFrame references.

But wait… doesn’t this look familiar from somewhere? Doesn’t it remind you of a certain language feature you may have used years ago?

Yes, you’re right! It looks remarkably like the “with” control structure available in Delphi/Pascal and VisualBasic! If Java also supported it, the above example could be rewritten like this:

with (new JFrame("Hello World")) {
    add(label, BorderLayout.CENTER);
    addWindowListener(new MainFrameListener());
    setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
    pack();
    setLocationRelativeTo(null);
    setVisible(true);
}

It looks almost almost exactly the same as the one using the fluent interface, doesn’t it?

The main difference is that such a built-in construct works with any object you happen to throw at it, doesn’t require any additional effort from the library designer, and doesn’t require you to write repetitive code or wrapper classes if the library author failed to include the fluent interface pattern into the library in the first place. It also doesn’t interfere with the command-query separation principle and is perfectly compatible with step through debuggers.

But the fluent interface pattern does make it possible for us to have a special name for a simple concept, a Wikipedia entry for it, and dozens of blog posts about a solution to a problem that’s been solved, in a better way, decades ago.

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.