Right now we’re seeing stuff happening in the webbrowser that starts to go beyond the traditional web application. I’m talking about things that make either the browser itself or the interaction between different web applications a richer experience.

On the browser side, the basket of technology commonly referred to as HTML 5 falls into this category. It makes the browser a much more powerful client, thus rebalancing a lot of weight between web server and client to an IMHO much more natural equilibrium.

On the web application side we are seeing are starting to see lots of interesting application mashups, thanks to technology like OAuth and cross-origin AJAX hacks. Facebook’s recent innovation, the social graph and the ability to embed it into other applications, is a powerful example.

As many have noted, there are huge problems with this and they all have to do with security and privacy. Virtually none of the technologies coming forward under the HTML 5 umbrella help with security. Yes there are some attempts to fix one of the most backwards security policies in the browser. But these are mere sticking plasters over oozing flesh wounds.

Weaving a richer web

As I’ve written here before, I think we need a browser designed for the cloud. Back then I was mostly speaking in terms of usability and explicitly ignored the privacy issue. It think it’s time to come back to that now. With HTML 5, we’re giving the browser many ways to be a richer client. But in terms of user data, we’re still treating it as a dumb terminal.

Weave, a Mozilla Labs project, has a different vision. Its broad idea is to create a richer web experience while still having users control their data. Concretely, the Weave Sync service allows you to synchronize your tabs, history, bookmarks, settings and passwords between different browsers. And here’s the thing: the data is all encrypted, on the client. All that Mozilla is storing on their storage nodes (which you don’t have to use, by the way) is a bunch of encrypted JSON.

Sure, you may be saying, that’s great for making Firefox a richer browser, but how does that help the general web?

Well, it turns out that doing RSA and AES cryptography in JavaScript isn’t such a far fetched idea at all. With some inspiration from an abandoned project, I was able to hack together a (very rough) version of Weave Sync for Google Chrome. Since it’s entirely written in JavaScript, it actually works in any browser.

See for yourself. (To try it out, you need to create a Weave account with some tab data in it, e.g. by installing the Weave Sync add-on in your Firefox and syncing your tabs).

Sure, you may be thinking, encryption is great for dealing with personal data, but it would be impossible in a social web. What if you wanted to share your bookmarks with other people?

Well, is it really that impossible? Let’s look at what Weave does. In a nutshell, it encrypts your private data with a symmetric “bulk key.” This bulk key is stored along with data on the server, but in encrypted form: encrypted with your public key. That means to get to your data you’ll need your private key to decrypt the bulk key which in turn can then decrypt your private data.

If I now wanted to share my bookmarks with you, I could simply give you my bulk key by encrypting it with your public key. Job done. You can see my data (and only the data I’ve encrypted with the particular bulk key that I’m sharing with you), but nobody else can. Not even Mozilla.

I know, sharing bookmarks is so 1998. But it’s essentially the same thing as the Like button (or the LUUV button). Or your address book. Or your whole social graph. Point is, we no longer need the server to do the heavy lifting for us because the browser environment is getting richer — be it the HTML templating, session storage or even cryptography. The server can become a dull data storage that we can scale the heck out of and, more crucially, potentially ditch for different one if you like. While all the data is in the client’s hands and leaves it only in encrypted form.

This is the kind of cloud I can definitely get on board with.

Advertisements

Today I had one of those it-came-to-me-as-I-was-under-the-shower moments. For some reason, a conversation from a couple of months ago popped back into my mind. Somebody had asked me about associative arrays in JavaScript. To which I simply replied something like, well, they’re just there, built into the language. Just use an object! You could technically even use an array (since JS arrays aren’t really arrays but hash tables with string keys whose strings happen to convert to integers), but that’s not a good idea for various reasons.

This morning I realized that my answer wasn’t entirely complete. Objects work fine as associative arrays a.k.a. hash tables a.k.a. dictionaries if your keys are strings or can be uniquely converted to strings (in which case you could write toString() methods for all your objects you want to use as keys.) Python is a bit less restrictive with its dictionaries and requires that your object be hashable. Immutable built-in types like strings and tuples are hashable, so as long as you can find a one-to-one unique mapping to those (and implement that in __hash__()), you’re good. The advantage of this system is that string representation and hashing aren’t mixed into one interface.

The good news is that thanks to the concept of object identity (present in both JavaScript and Python), you can actually write an associative array that accepts arbitrary keys:

function dict () {
    var keys = [];
    var values = [];

    return {
        get: function (key) {
            return values[keys.indexOf(key)]
        },

        set: function (key, value) {
            var i = keys.indexOf(key);
            if (i === -1) {
                i = keys.length;
            }
            keys[i] = key;
            values[i] = value;
        },

        del: function (key) {
            var i = keys.indexOf(key);
            keys.splice(i, 1);
            values.splice(i, 1);
        },

        keys: function () {
            return keys.slice();
        },

        values: function () {
            return values.slice();
        },
    };
}

I’m not going to bother with a Python implementation because it would look almost identical (modulo syntax). Also, if you find yourself wanting to use something like this in Python, you’re probably doing something wrong. Python’s dictionary implementation is insanely fast and the range of immutable types (strings, tuples, frozensets, etc.) should be sufficient.

And come to think of it, so far I haven’t felt the need for something like this in JavaScript either. But it came to me under the shower, so I had to write it down.

A few months ago I wrote a post about JavaScript titled Curly braces are not the problem wherein I pointed out one of JavaScript’s biggest weakness, the new operator and how to spell an object constructor as well as methods on the corresponding prototype. Some commentators mistook that post for critique of the prototype model itself. It was far from it, I think the prototype model is great, just the spelling was awful. Consider this:

function MyObject() {
    /* constructor here */
}
MyObject.prototype = {
    aMethod: function () {
        /* method here */
    }
};

which is alright until you now want to inherit from this and add methods:

function YourObject() {
    /* constructor here */
}
YourObject.prototype = new MyObject();
YourObject.prototype.anotherMethod = function () {
    /* another method here */
};

There are several problems with this. First of all because YourObject inherits from MyObject, it has to be spelled differently. Secondly, we can’t reuse the constructor, at least not without resorting to func.apply() tricks. Thirdly, we have to know what to pass to the constructor of MyObject at definition time.

It turns out, Doug Crockford not only agrees with me on this but also has come up with a better way. Back in January I thought that we needed more syntax to fix this, but it turns out we need less (by which I mean ditching the new statement). In Vol. III of his excellent Crockford on JavaScript lectures, he defines a constructor maker:

function new_constructor (extend, initializer, methods) {
    var prototype = Object.create(extend && extend.prototype);

    if (methods) {
        methods.keys().forEach(function (key) {
            prototype[key] = methods[key];
        });
    }

    var func = function () {
        var that = Object.create(prototype);
        if (typeof initializer === 'function') {
            initializer.apply(that, arguments);
        }
        return that;
    };

    func.prototype = prototype;
    prototype.constructor = func;
    return func;
}

I’ll let you work out the details of this yourself and instead just show you how you would define the equivalent of the two cases above:

var new_my_object = new_constructor(Object, function () {
    /* constructor here */
}, {
    aMethod: function () {
        /* method here */
    }
});

var new_your_object = new_constructor(my_object, function () {
    /* constructor here */
}, {
    anotherMethod: function () {
        /* method here */
    }
})

See how symmetrical both forms are now? And if both object constructors really were were to share the same initializer, I could easily define that as a separate function and reuse it.

Btw, if you do any sort of web development, I highly recommend you watch the Crockford on JavaScript talks. They’re not only entertaining but are an excellent lesson in history of all the technology that makes up the web.

The Firefox UX team is working on fixing the download manager. I haven’t actually seen what they’re planning yet, but Limi invited me to tell him what I thought. So here it goes:

The separate window sucks. Google Chrome has a tab for the download history which definitely is an improvement over the separate window, and it allows you to search downloads.

There are two cases that should IMHO be handled differently:

  1. downloads that result in the opening of a program (e.g. PDF)
  2. downloads that just drop a file in a directory

For a) you don’t really need that many visual cues. Add an entry somewhere to the download history so you can find it later, but that’s all. The user doesn’t need to or want to do much else. The file opens in another program, case closed. The b) case, however, often concerns long-running downloads, and they definitely require more user action when they’re done. Here the UI should be as non-intrusive as possible, allowing the user to continue working while still giving feedback on the download’s progress.

Personally I use the Download Statusbar extension. It gets the workflow for b) pretty much right IMHO: There’s non-intrusive visual feedback at the bottom of the screen, so I can continue doing something else. Once the download is done I can come back to it without having to check a separate window or tab. Once I double click on the file to open it, it disappears from the download bar. So it’s gone from my “todo list” of downloads to process (it’s still in the download history, though). This is definitely better than having a manual Clear button.

A really nice feature, particularly for the a) case, would be if the download history was actually put to use. Here’s something that happens to me a lot: I open a scientific paper (PDF) from the web in Preview.app. At some later point I read another paper and it refers to the first one. The hyperlink in the references takes me to some page where, unaware that I downloaded it already, I end up getting a PDF I have on disk already. It would be very cool if Firefox recognised this and, instead of dropping another PDF turd in my directory, just opened the original download. Of course you’d need to check Last-Modified headers etc., and perhaps there could be a simple enough option to force a re-download.

To summarise, I would do this:

  • The download history (née Download Manager) is in a tab, searchable, and there’s no Clear button (much like your page history it could be cleared from Preferences).
  • Downloads that open in a program get an entry in the history but no visual cues. If people want to revisit the file, they could simply go to the page they got it from and Firefox would search in its own download history for them. Of course, they can always manually search the download history as well.
  • Progress for downloads that are long-running and/or don’t open in a program is shown in a non-intrusive way (e.g. some bar on the bottom). Double clicking or having the file exposed in Finder/Explorer will clear them off this bar, but of course not from download history.

This is part 3 in a loosely coupled series of blog posts about improving the browser for the cloud, particularly Firefox. In the first post of the series I made my case for why we need web browsers that are designed for today’s cloud apps. In parts 2a and 2b I have been exploring tabs, particularly how to deal with lots of them. And how a simple change in tab behaviour can allow me to blend the previously separate concepts of bookmarks and tabs (cf. my BarTap extension.)

In this post I’d like to muse a bit about creating tighter integration between the browser and webapps. We’re using a lot of webapps these days and a lot of them we never quit. Hence people came up with the idea of “app tabs” which are tabs in your browser that are always there. There’s an extension for this, and more importantly, app tabs will be an integral part of the future Firefox UI.

Part of the idea is that app tabs don’t need any chrome, which is geek-speek for the browser UI. Think back/forward buttons, URL bar, etc. In a way that’s true because the webapps displayed in these app tabs are typically self-contained and don’t need navigational UI elements. But this got me thinking: Perhaps there are other UI elements that a browser could provide to make the webapp experience easier? As outlined in the first post of the series, I find it a bit worrying that webapps employ so many different UI paradigms, thereby evading the most humane feature a UI can have: consistency.

But as I also said in that post, closed environments like a mobile platform (e.g. the iPhone) have shown that apps like Facebook and WordPress can actually be made to have a similar look and feel. Why not do the same thing, possibly on a smaller scale, in the browser?

Due to a transcontinental flight I had some otherwise unproductive time earlier this week, so I hacked together a small extension called Vanadium that does just that, albeit in a very very primitive way. It basically hides the navigation chrome for app tabs and instead displays the “vanadium”, a toolbar that represents actions for the webapp. Here is Vanadium in action using Gmail:

Using Vanadium for Gmail. All of the toolbar buttons are hooked up, including the search. The Home button takes you to the inbox.

I’ve also integrated it with Twitter, though of course the Reply button doesn’t make that much sense there:

Vanadium hooked up to Twitter. Not all of the toolbar buttons make sense.

All in all it was a fun experiment (certainly a nice way to spend a flight) and I think it’s worth pursuing the idea further. Of course not all toolbar buttons make sense in all webapps. And the way the Vanadium toolbar works together with the webapp would definitely have to more sophisticated. I think the most promising item would be the search bar so I’m thinking I’ll be investigating a cross-webapp search bar next.

What do you guys think?

A book on Grok!

February 10, 2010

Carlos de la Guardia has written a book on Grok, a Python web framework I helped kick off and contributed to quite a lot. I was honoured to be asked to write the foreword for it. Here’s what I wrote:

A little less than a year ago, Zope 4 was released. As the successor of the complex, verbose and certainly not agile Zope 3 (now called BlueBream), it was instantly welcomed with much cheer. Naturally I chimed in and announced without much hesitation that the forthcoming 4th edition of my book would already be based on lean and mean Zope 4.

Sadly these were all just April fool’s jokes.

Sadly? No, I should say luckily. Because something much better came out of Zope land just a few months after we jokingly invented a new Zope version. Grok 1.0 was released. And thanks to Carlos’ tremendous effort, there’s now a book to accompany and celebrate this achievement, too.

There is much to say about this book, but I’m sure you’re eager to get started with your web application. So let me just tell you what I like best about it.

Carlos has managed to capture the Grok spirit in this book. It is concise, not too heavy and doesn’t beat about the bush. Yet it manages to hit all the bases of web development. With a spikey club, of course. It is as smashing as the framework itself and I hope you’ll enjoy both as much as I have.

Have fun!

Good news for tab addicts

February 5, 2010

Hi. My name is Philipp and I’m a tab addict.

I treat browser tabs as applications, bookmarks, to do items and many things more. I keep a lot of them open all the time. To organise them I use the excellent Tree Style Tab add-on. But more on that below. First let’s talk about the implications of having lots of open tabs.

Pay now, drink later

The thing is, when you’ve got lots of open tabs, you become reluctant to restart Firefox. Not I want to do that often, but sometimes I have to, e.g. when Firefox is being a memory hog again. Or when you need to restart your computer because of a software update.

So why do you become reluctant? Sure, Firefox’s excellent session restoring facility can bring all tabs back, but having ca. 100 tabs restored sucks up a lot of network traffic and a lot of CPU power. That can effectively render your browser unusable for a minute or more.

Here’s the deal, though. I don’t need all the tabs immediately. As said, a lot of them are just bookmarked as “I want to read that later” or “need to check that out.” That means Firefox shouldn’t need to restore all tabs immediately.

Hence BarTab was born.

BarTab is a Firefox extension that hooks into the tab mechanism. It intercepts when tabs are restored and/or opened in background (this is configurable) and doesn’t load their contents until you actually visit them. When restoring tabs from a previous session, it will even pull the favicon and website title from Firefox’s history service so you won’t have to stare at a URL. This is what it looks like:

Firefox after a restart. The three tabs on the left haven't been loaded yet, hence their dim appearance.

There’s a usability lesson in this

Now some of you might give me a perplexed look and wonder why I don’t simply use bookmarks. The answer is pretty simple: tabs are right in front of me. Bookmarks are either in some menu, toolbar or sidebar. And as a concept they are orthogonal to tabs. But why have another concept when one will do?

So BarTab effectively blends bookmarks and tabs into one. In that process the session store service has replaced the bookmark service. That’s good because the session store keeps track of all tabs I have opened and even the ones I’ve recently closed. That makes my interaction with the browser a more humane experience, because not only do I not need to do anything special to make Firefox “bookmark” something, I also get a second chance, or “undo,” if I accidentally close something.

Beautifying tree tabs

As said, I use Tree Style Tabs to organize my various tabs. Two weeks ago I started creating my own custom theme of the tree, modeling it after the trees we find in sidebars of various OS X applications (e.g. Finder, iTunes, Mail.) This effort has now culminated in SidebarStyleTab 1.5 which replicates the OS X experience quite well, including tricky things like resizing the tab bar and drag’n’drop. Here’s what it looks like:

SidebarStyleTab 1.5 in action. The tree looks native to OS X. Notice the altered status bar with buttons and slider.

The best news, however, is that thanks to the author of Tree Style Tab, Shimoda “Piro” Hiroshi,  most of SidebarStyleTab will be integrated into the next version of Tree Style Tab (0.9). He has also provided some useful insights into the development of  SidebarStyleTab and BarTab, so much thanks to him.