Just Browsing

Browser of the Week: Flock

I’ll be using the Flock 1.1 this week as part of my occasional Browser of the Week series, posting my thoughts and impressions on Friday. Please leave a comment if there are particular features of Flock that I absolutely positively must put through their paces. I’m definitely planning to try out as much of their “social functionality” as possible. In fact, I’m in their blog editor right now, so if you’re reading this then I at least got that part to work.

Blogged with the Flock Browser

Tags: bofw, flock

| No Comments »

The Trouble with Google Docs (And How to Fix It)

I’ve been obsessing recently with configuring my home office software environment just so. Since I went all Apple, all the time, I’m able to benefit from a lot of goodies that are built into OS X (notably iTunes). And developing on Mozilla means that I can do pretty much everything from the command line, using XCode as my editor (which gets me zero hacker cred but works just fine). I never touch a spreadsheet if I can help it, and if I don’t have to make another Powerpoint-style presentation ever again I don’t think my psyche will suffer in the slightest. So my computers lack an office productivity suite that would sully my Microsoft-free lifestyle or force me to install that lumbering beast that is NeoOffice.

This delicate karma was shattered the other day when I needed to bang out an invoice for my customer. Rather than succumb to the siren call of office bloatware, I decided to give Google Docs a spin. What could be cooler than a free, lightweight web wordprocessor, I thought. Unfortunately the experience proved to be a deep disappointment.

Some issues were relatively trivial. For example, the clipboard commands don’t seem to work on Mac and kept prompting me to use the operating system’s keyboard shortcuts. Annoying but not showstopping. Much more serious was the table management, which is atrocious. I kept bumping into a bug that prevented me from adding normal text underneath my table; it just wanted to tack on additional rows. Resizing columns is a total nightmare and getting the text in the columns to line up properly went beyond the nightmarish into the realm of sheer horror. When I went to export my document as a PDF, it in no way resembled the “WYSIWYG” of my actual document. I spent what seemed like hours (and might actually have been hours) tweaking and exporting in a soul-sapping orgy of trial-and-error until I got something that vaguely resembled a professional-looking result.

So now I know why Google Docs hasn’t encroached more significantly on Microsoft’s turf: it kind of sucks. Don’t get me wrong, I don’t need or want the zillions of bizarre features that traditional shrink-wrapped vendors insist of pushing on users in order to drive revenue from useless “upgrades”. But something as basic as table management should just work, and the exported output should look like the original document, dammit. Concerns about the dismal state of browser-based editors are not new, of course. Clay Shirky was frothing at the mouth years ago over the lack of auto-save (though modern web apps seem to handle that pretty well), and I’ve whinged at length about various other aspects of the same issue myself.

Luckily, Google has a weapon in its arsenal that is perfectly suited to addressing this problem: Gears. Gears honcho Aaron Boodman blogged recently about Google’s ambitions for the product. Basically, the idea is not to replace existing existing browsers or preempt nascent standards. Instead, it is a platform for providing missing functionality in a cross-browser manner while vendors and standards catch up. So how about it, Google? A really kick ass editing component for Gears would fill a gaping hole in current browser feature sets and give Docs a fightly chance of competing effectively with its desktop-based counterparts.

Tags: docs, gears, google, rants | 12 Comments »

Browser Bits and Bobs for May 7, 2008

• Microsoft ships XP Service Pack 3 with continued support for Internet Explorer 6.
• Firefox wins favorite browser in the LinuxJournal Readers’ Choice Awards with 86% of votes cast.
• John Resig implements a complete HTML parser entirely in JavaScript. Multiple interfaces are provided including SAX and a DOM builder. Amazing.
• Flock wins a Webby award in the Social Networking category, beating out stalwarts like Facebook, Bebo and Ning.
• Opera releases the long-awaited Dragonfly, taking it straight to Firebug with CSS and DOM inspectors, JavaScript debugging and more. Particularly significant considering that some developers consider Firebug to be one of the most compelling reasons for using Firefox.

Tags: bits and bobs, dragonfly, firefox, flock, john resig, microsoft, opera | No Comments »

Memo to Microsoft: Buy Adobe, Not Yahoo

If nothing else, Microsoft’s prolonged attempt to acquire Yahoo has added some zest to the tech news echo chamber. The ongoing saga has provided seemingly endless fodder for mainstream news outlets and blogs to speculate about the financial merits of the deal, the strategic implications for Microsoft and Yahoo’s allergic reaction (a barometer for Silicon Valley sentiment towards the Redmond giant, which remains almost pathologically negative). The Wall Street Journal is reporting today that Steve Ballmer has been given free rein by his board to walk away from the deal or raise his offer (evade the paywall on Google News or read the Silicon Valley Insider summary). Marc Andreesen has a great rundown of the possible outcomes on his blog.

What seems to have fallen by the wayside amongst all the speculation about whether the bid will succeed (and, if so, at what price) is what a spectacularly bad idea it would be. The business landscape is littered with the carcasses of failed mega-mergers (DaimlerChrysler, anyone?). Even when they don’t end in utter disaster, the long-term benefit to shareholders is often dubious. Add to this the fact that Yahoo is so vehemently opposed to the merger that it is seriously contemplating dumping its vaunted Panama ad platform and outsourcing its ad delivery to arch-rival Google. The consider that industry headhunter Boris Epstein rates concerns about the deal as the number one reason for Yahoo staff defections. Not exactly an environment likely to be conducive to a healthy, happy corporate marriage.

Even more to the point: does a Yahoo acquisition imply the kind of strategic direction that Microsoft should be pursuing? The whole endeavor smells of a vain attempt to hang onto Google’s coattails in the internet search space. Google has hit a grand slam homerun in terms of technology, user experience and monetization, but that doesn’t mean that blindly pursuing the same strategy is the right move for its competitors. Nor is it particularly plausible that combining two also rans (which together would still have less than half of the leader’s market share) will create a viable counterweight to Google’s dominance of the search market.

Microsoft should stick to its knitting: operating systems and applications. Its Silverlight initiative is a step in the right direction, reacting to the inexorable shift of applications onto the web. But they are fighting an uphill battle by trying to achieve any kind of critical mass with a brand new software stack. They’ve tried this before… and when was the last time you used an ActiveX control on the web?

Why not look instead to a company that would instantly turbocharge Microsoft’s web application strategy? Adobe has achieved incredible browser penetration with its Flash runtime. As such is the only company that can plausibly achieve Microsoft’s goal of successfully promoting a framework more suitable for deploying desktop apps on the web than current incarnations of HTML and JavaScript. It has garnered accolades and tremendous mindshare for its AIR platform. And today it announced the Open Screen Project. This initiative offers nothing new on the technology front, but makes it clear that Adobe intends to make a splash in the device market with the elimination of restrictions and licensing fees on its various Flash protocols (SWF, FLV/F4V and Flash Cast), as well as the publishing of APIs that will make it easier for device manufacturers to get Flash running on their cellphones, mobile internet devices, set top boxes and who knows what else. This is exactly where Microsoft wants to be. XBox is its strategic crown jewel, after all, and the addition of Adobe’s technologies to its arsenal might finally pull the Zune out of the doldroms.

A purchase price of $32-33 per share for Yahoo would represent about an 80% increase over the pre-bid stock price. Assuming a similar premium for Adobe, the company would set Microsoft back about $35 billion, a full $10 billion less than Yahoo. It’s far from clear that a big honking acquisition is what Microsoft needs to deal with the decline of its Windows franchise and the challenges it faces as the market moves away from the bulky desktop applications that have served it so well. But if it is going to go this route, Adobe represents the cheaper and more strategically sensible choice.

Tags: adobe, flash, microsoft, silverlight, yahoo | 6 Comments »

Redrawing the Browser’s Borders

Traditionally browsing architectures have had a rather arbitrary separation between the rendering engine (suitable for embedding and reuse) and the browser user interface (not so much). These terms are a bit misleading because “rendering” necessarily entails far more than just painting HTML on the screen; the core engine is likely to include some pretty beefy networking capabilities and much else besides.

The other day Todd Ditchendorf (aka Mr. Fluid) tweeted the scope of this single-site browsing ambitions:

My goal is to remove any reason for someone to prefer Safari over a Fluid SSB for general browsing due to a missing feature. Getting there…

Then Mark Finkle gave in to mounting pressure from the ruthless Prism user community and landed a patch to add “basic browsing buttons” (i.e. back, forward and the like) in an optional toolbar. This comes on top of an ongoing struggle to get a preferences dialog into the product since Firefox’s version is not part of the platform. User requests continue to stream in for things like a user interface for configuring proxies and browsing in multiple tabs (a gotcha because the tab browser control is also specific to Firefox). From what I’ve heard, building a usable browser on top of WebKit is at least as onerous, requiring the implementor to reinvent the finer points of the browser’s user interface and high-level functionality one painstaking line of code at a time.

Any preconceptions about where the underlying platform ends and the actual browser begins are likely to be confounded immediately by some unanticipated real-world use case. Future browser architectures should simply do away with the issue altogether by making the entire codebase reusable, right up the finer details of the user interface. Deploying something like an SSB should require an hour or two of tweaking, not weeks or months of intense development.

Some might argue that SSBs are an exception because, for all intents and purposes, they are just normal browsers that happen to restrict which sites you can visit (and do away with some of the UI elements made unnecessary by these constraints). But we didn’t anticipated the idea of an SSB when today’s generation of browser architectures were conceived, so what reason do we have to assume that we are able now to foresee what the future of browsing might bring?

Tags: architecture, fluid, prism, ssb | 4 Comments »

Deconstructing Rich Internet Applications

A post by my Prism partner in crime Mark Finkle sent me spiraling back in time along an interlocking blogathon of attempts to nail down the term Rich Internet Application. Intense speed-reading of so many mammoth posts can scar the psyche, so let me paraphrase them and save you the trouble.

• James Ward, What is a rich internet application?
  People respond to the same things in software that they appreciate in the real world: an experience that is connected, alive, responsive and interactive. Web apps nail the first point but suck when it comes to the other three. RIAs are an attempt to rectify this.
• Scott Barnes, Rich Interactive Applications
  RIAs aren’t primarily about the internet, they’re about improving user experience. I agree with James on this point. What’s lacking is maturity, and at Microsoft we’re nothing if not mature. Nice vision, Adobe, but we’re the right ones to carry the ball forward. (And by the way, I don’t know the difference between “who” and “whom”.)
• Dare Obsanjo, If You Fight the Web, You Will Lose
  No Scott, it’s about improving user experience on the internet. No cares about isolated desktop apps anymore, no matter how slick they might be. Without the internet part, the whole exercise is pointless.
• Ryan Stewart, The ever-changing definition of RIAs and how people are killing it
  Yes, RIAs are about improving user experience on the web. There are host of technologies competing to achieve this: Flash, Flex, Silverlight, Nitro and good old Ajax. But efforts to pigeon-hole RIAs as either browser-hosted (like Silverlight) or desktop-oriented (like AIR) are doomed to failure because a big part of their promise is being able to use the same technologies to develop both types of apps.
• Mark Finkle, RIA is Dead! Long Live Web Applications!
  I’m sick of all these corporate evangelist types trying to pervert the definition of RIAs to their various nefarious purposes. Let’s just put the term out to pasture and focus on good old web apps.

A lot of good and valuable points are made in the course of this discussion. As I pointed out in this blog’s manifesto, the rise of Ajax was all about augmenting the responsiveness and overall user experience of web apps. But Ajax is, at its core, a big hulking (and extremely clever) hack. RIAs are simply the logical next step in this process, providing a more elegant and cohesive way of creating web apps with the spit and polish that mainstream users crave. The term has merit, despite its imprecision, because any significant technology trend needs a snappy buzzword to hang its hat on. People hate the term Web 2.0 as well, but it has served an important purpose by giving us a framework to analyze the new internet technologies of the past few years.

Besides the obfuscating effect of the self-serving corporate agendas that Mark rightly laments, the notion of an RIA is confusing because it is evolving along two orthogonal paths. It’s a floor wax and a dessert topping. Or in this case, an effort to improve the usability of web apps and to improve their integration into desktop environments. Silverlight and Prism have absolutely nothing to do with each other because they attack two distinct vectors of the problem. The former makes it possible to write slick browser-hosted apps with elegant software architectures, while the latter grafts web apps onto the desktop in all their messy, spaghetti-coded glory. And yet both are essential parts of the RIA puzzle.

The other controversy revolves around the question of whether the proprietary creations of Adobe and Microsoft will remain viable or perish under the onslaught of the open web. It’s worth noting that Ajax arose from the fusion of two proprietary technologies, XMLHttpRequest and JavaScript. But it is hard to believe that Flex, Silverlight and their ilk will follow in their footsteps unless they open up significantly. This was my interpretation of Anil Dash’s metaphor (also discovered thanks to Mark’s post):

Think of the web, of the Internet itself, as water. Proprietary platforms based on the web are ice cubes. They can, for a time, suspend themselves above the web at large. But over time, they only ever melt into the water. And maybe they make it better when they do.

Proprietary technologies can metamorphosize into standards by opening up and garnering widespread adoption among browser manufacturers. Whether they will triumph over some future incarnation of HTML and JavaScript really depends on whether the vendors who are promoting them accept this (and the inevitable relinquishing of control it implies) before the sometimes glacial pace of web standardization efforts finally renders them obsolete.

Tags: adobe, ajax, flash, flex, microsoft, prism, ria, silverlight, standards | 2 Comments »

The Future of Firefox Extensions: Make Them More Like Web Apps

A few years ago, having just started work on a very ambitious (and now defunct) Firefox extension, my business partner and I met with some of the Mozilla top brass to pick their brains. One of the most interesting tidbits that we walked away with was the rough estimate that only 5% of Firefox users install even one extension. This figure was based, I believe, on an approximation of the total size of the Firefox user base combined with figures from Mozilla’s add-on site, which tracks “update pings” (which the browser uses to check whether new versions of any extensions are available). I don’t know how much that percentage has changed in the interim, but it’s probably safe to say that it is still a pretty small number.

This is striking because extensions are Firefox’s killer app. Opera has widgets. Safari has web clips. These overlap somewhat with extension functionality but fall far short in power and scope. Internet Explorer comes closest with its add-ons, but despite heroic efforts on the part of Microsoft (and a very flexible component-based architecture) they remain a rather staid affair compared with the vibrant Firefox ecosystem. Reducing footprint, boosting performance, improving standards support and adding cool new features are all great, but the limitness possibilities offered by extensions are what truly sets Firefox apart from the pack.

It is in this spirit, perhaps, that Dave Townsend asks what’s next for add-ons (which include themes and plugins as well as extensions) once Firefox 3 is out the door.

Looking at this question first from the supply-side: what can Mozilla do to make it easier for developers to create extensions? I’ve developed quite a few extensions in my day, but I still grit my teeth whenever I have to write a new one. One problem is the plethora of languages that can (and often must) be used. Any web developer worth their salt has mastered HTML and JavaScript. But do they also have a handle on XUL, XPCOM, XPIDL, XBL and a smattering of RDF?

If extensions could be written purely in HTML and JavaScript (both of which are evolving in ways that make this more feasible), this would flatten the learning curve considerably. FUEL is a big step in the right direction, replacing strange-looking (in a scripting environment) XPCOM APIs with more natural JavaScript equivalents, but it could go much much further. Proper tool support would have a truly revolutionary effect. Templates in XCode and Visual Studio generate boilerplate automatically for iPhone apps, ActiveX controls and the like, removing much of the tedious busy work from the process. How about providing the same (in these and other environments like Eclipse) for Firefox extensions?

This would help to build on the already impressive library of available add-ons, but it wouldn’t in itself entice more users to give them a try. My favorite improvement tops Dave’s list as well: allowing add-on install without requiring a browser restart. This is famously tricky, and would require modifications to existing extensions, but it would be well worth the effort. People will be more willing to experiment if they can install an extension and play with it (and remove it if it doesn’t catch their fancy) without having to shutdown Firefox every time.

But by far the biggest benefit would come from a more robust sandboxing model. Extensions are an all-or-nothing affair; install one and you give it complete control over your computer. If it decides to scan your disk for deviant porn and post an exhaustive list (with handy thumbnails) to your Facebook account, there isn’t a thing you can do about it. Except, of course, to avoid downloading it in the first place, which is why add-ons throw up a host of security roadblocks: a domain whitelist, an intentionally annoying nag screen and the new digitally signed update manifests.

But most extensions don’t rely on any dangerous capabilities to do their job. The need to access the local disk is greatly tempered by new offline storage capabilites. They rarely use more than a tiny subset of available XPCOM interfaces. And while any extension can include binary components that give it carte blanche to do with your computer as it will, only a handful take advantage of this unbridled power. The vast majority don’t need to since all they do, for the most part, is modify your browser chrome (adding toolbars, sidebars and/or status bar panels), tweak the contents of web pages and provide more immediate access to specific links or data.

This isn’t to say that we should remove the heavy artillery entirely. When you need it, you really need it, and some of the coolest extensions take advantage of Firefox’s exceptional flexibility. The answer is to have a two-tiered platform. Most extensions can explicitly forgo the scary stuff and benefit, in exchange, from reduced security requirements. This would give users the confidence to try out extensions from untrusted sites in the same way that we don’t hesitate to visit an unknown website, firm in the knowledge that it can’t do anything too terrible. Extensions that need unfettered access would still require the same signatures, nag screens and other security roadblocks.

As a result, most extensions would be like normal web apps that happen to be able to hook into the browser chrome and stick around when you surf away from the website where you got them. Ease-of-installation and airtight sandboxing have served web apps so well that they may eventually take over almost the entire application space. The best way to take the Firefox extension ecosystem to the next level is to follow their example.

Tags: extensions, firefox, rants | 7 Comments »

Does Joost Presage the Demise of Downloadable Software?

An article this month in Portfolio chronicles the disappointing stagnation of Joost, one of the most hyped startups of recent years. The conclusion appears to be that web-based video a la YouTube has trumped the technical advantages of Joost’s P2P-powered client. Given the choice between downloading a special piece of software to get full-screen, high-resolution video and watching grainy clips on the web, users have opted for the latter in droves.

There’s some truth to this, of course. Success on the internet is all about exploiting network effects, and anything that acts as a barrier to adoption is anathema to this goal. It’s tempting to conclude that the era of downloadable software is over, at least for media consumption. If a high-profile startup with rich, famous founders and tens of millions in investment can’t entice users to venture outside the walls of the web browser, what hope is there for other special-purpose browsers like Songbird and Miro?

This view is oversimplistic, however. The real competition for Joost isn’t YouTube, it is BitTorrent. And BitTorrent requires a special client, proving that users aren’t averse to downloading software if they see enough benefit. The real problem is that Joost tried to position itself as a distribution platform for traditional media companies. Unfortunately, control over distribution is really all that the media companies have left in their arsenal as they flail desperately against an inevitable future where artists ply their wares directly to consumers. The record companies are famously unhappy about the power they ceded to Apple by making their songs available on iTunes, and the video folks aren’t keen to make the same mistake.

The Portfolio article quotes Jeff Zucker, the head of NBC:

“I was not that comfortable with Joost,” Zucker says. “We wanted greater control over how our content was presented and distributed, and the key things advertisers and consumers are looking for are ease of use and a safe haven.” By safe haven, he means a site where no one will stumble across those barfing videos or even Motors & Babes.

The safe haven line is a smokescreen (though a more vulgar term comes to mind). What Zucker really means is that they want to keep the virtual equivalent of their bricks-and-mortar distribution monopolies for as long as humanly possible.

I’ve been hearing constant rumors about Joost’s plans to jettison their client and move to a web-only model, but there’s no reason to believe they’ll be any more successful with their existing content in the overcrowded web video space. A better bet would be to reposition themselves as a competitor to Big Media, providing a superior outlet for artists keen to bring their creations directly to the masses.

In the long term, the web browser may garner enough features and flexibility to make special-purpose media browsers obsolete. But in the meantime there is plenty of room for software that offsets the pain of downloading with the gain of better quality content, lower costs and tighter desktop integration.

Tags: joost, media browsers | 5 Comments »

Another TechCrunch Guest Post on Single-Site Browsers

My first guest post for TechCrunch, on the subject of single-site browsers, attracted a lot of interest and no small number of questions. Without seeing them in action, it’s pretty hard to grasp what’s so great about what sounds like a stripped down, less functional version of a normal web browser. I’ve followed up with a more detailed look at some of the leading contenders, Bubbles, Fluid and Prism, highlighting the advantages their provide over traditional browsers. I also threw Adobe AIR into the mix, contrasting its holistic approach to Rich Internet Applications with the minimalist take of the other three products.

My conclusion:

AIR has the full weight of Adobe behind it, great tool support and a lot of mindshare in the web space. If enough vendors are convinced by its advantages and decide to use it to create desktop-enabled versions of their web apps, it may be hard for the other SSBs to compete. API standardization will be key in determining how things pan out. A common, well-designed API for single-site browsers would even make it realistic for vendors to integrate desktop-oriented code directly into their web apps. If this were to happen then loading an application like Gmail or Flickr into Bubbles, Fluid or Prism would give you all those fancy dock menus, popup notifications and the like with no customization required at all. Considering that users are increasingly leery of downloading and installing standalone apps, this would be a compelling advantage indeed.

Note: The link to my script customizing Bubbles for use with TechCrunch isn’t online yet in the main article. I’ve posted it here for those who are interested in taking a look.

Tags: air, bubbles, fluid, prism, ssb, standards, techcrunch | No Comments »

SlimTimer and Prism, a Case Study

In my new incarnation as an independent software development consultant (read: programmer who works in his pajamas), I need to track the hours that I spend working for my clients. I’ve been using SlimTimer, a simple but wholly sufficient web app (highly recommended). It displays a nifty floating browser window with a list of my active tasks; click once on a task to start the timer and again to stop it.

Immediately, problems with running a tool so vital to my work inside my normal Firefox instance became apparent. Not insignificantly, I had to right-click on the Firefox dock icon and select the right window every time I wanted to call up the timer. When you’re doing something potentially dozens of times a day, every little bit of superfluous effort starts to get on your nerves. More importantly, I sometimes restart Firefox, which causes the timer to stop (costing me money, or at least mental effort as I try to reconstruct my hours forensically after the fact).

Today it dawned on me that I should serve myself a heaping portion of my tasty dog food, so I fired up Prism and entered the SlimTimer URL. Maybe it ain’t rocket science, but a minute later it was running as a standalone application in its own process. This means that it can be accessed with a single click on the dock icon (even when it isn’t running since I’ve configured it to leave the icon in the dock).

I’m biased, of course, so let me make it clear that similar products like Fluid and Bubbles would doubtless yield the same results. But anyone who says that single-site browsers are just like other web browsers with a bunch of useful stuff stripped out are plain wrong. For web apps that you use a lot, this type of desktop integration is of great value. My next task is to implement a dock badge that shows me state of the timer for the active task, in real time (which should involve nothing more than a short snippet of JavaScript).

Tags: prism, slimtimer, ssb | 2 Comments »