waffle

This post is about Rouse.

When you first heard about Rouse, you may have drawn a connection to this year’s early independent email client effort Letters, which ongoing development keeps a pace that is far slower than the initial explosive discussion. If you did, you may ask: “If I consider Letters to have failed because the pace has dropped and a beta is not in my hands today, how would you keep from falling in the same pit?”

There are several answers to that question. First, I am not privy exactly to the Letters development process because I haven’t kept up. I know that, short of a team of ten full-time paid programmers cracking down, they would have had to slow down as part of implementation anyway. Discussion is easy, programming is hard; speculation should be swift and open, specification should be a bit more controlled, tied down and allowed to take its sweet time if that’s what’s necessary. And a good email client takes time and dedication to construct in any case. It’s my intent to respect the Letters project, and I really don’t know what it’s currently up to, but I bring it up because the question is warranted and the comparison inevitable. So let me get to the substance.

Rouse, like every other “wouldn’t it be great if” scheme, could easily spiral out of control into something that will never be implemented. That’s why it’s so important that scope is set. For me, the goal for Rouse is very clear and consists of a few tiers.

The first tier is to implement a functionally minimal tabbed web browser, with vertically arranged thumbnail tabs and an address bar. Bookmarks will be there in a hardcoded form. There won’t be physical buttons for New Tab, Refresh, Back or Stop. It’ll be keyboard driven. It’s how I use OmniWeb.

The second tier is to bring in good functionality from OmniWeb. Adding “this tab has loaded since you last visited it” indicators, site-specific preferences, an address bar that comes and goes and has search shortcuts, some form of state retention. The tabs should work as well as they do in OmniWeb; drag between windows, reorder, multiple selection (for dragging and closing).

The third tier is to add integration features where your code get to partake in the loading and rendering. Bookmarklets and user scripts change the page after it’s loaded. Imagine what you could do if you could change the page as it’s being loaded, or partake of the WebKit internal representation to fool around with already loaded resources.

Two more clarifications are in order: I do not intend for everyone to use Rouse, so there’s no need for it to appeal to anyone else but people who think like me. Think of Rouse as the skin of a NowWhattian Boghog, the trade of which “only hung on by its fingernails because there was always a significant number of people in the Galaxy who were not in their right minds”. There’s enough people surfing this web that some of them ought to think like me, and why shouldn’t we have a tailored browser?

Furthermore, some people may think “oh god, why another browser?” and they are partially right. The dreadful aspects of multiple browsers are generally those of multiple rendering engines. Rouse will endeavor to stay as close as possible to the behavior espouded by Safari underneath the UI, and may even report the Safari user agent string. No one should need to be locked out of their online banking.

So, in closing, I expect for Rouse to be fully possible, if not easy. My personal goal is to be able to use Rouse for what I shall call “above casual browsing” by August this year. That’s the ambition.