Task specific browsers with Fluid - the making of the "Acquia Browser"

For those better in the know then I am, Fluid.app might be quite old news. I however just got on the bandwagon recently, and I thoroughly enjoy it. Fluid is a Mac OS X application, which acknowledges the fact that we are not using "the browser" anymore, but we are working on our days jobs, using our private email, posting photos, chatting with friends, etc. And these are all distinct activities or tasks we do. So we would be more comfortable looking for our "photo app", "chat app", "email app" or even "work app", but most of our interactions are now done on the web, so all these are tucked under the "browser app".

Fluid liberates us from that mess, allowing us to generate what are called site specific browsers (SSB). We can for example, generate a gmail app which is a full blown Safari browser with a custom icon we provide, even with support for an application icon badge which shows the number of unread emails we have in our mailbox. This also separates the gmail process from other Safari processes, thus letting it run even though a photo or video site slows down your generic browser. There are lots of cool things to Fluid, examples being support for site specific styles and user scripts, so that you can customize the websites to look even more like a web app, or support for custom browser strings, so that your app could ask for pages as if it was an iPhone, essentially getting a more streamlined look for certain apps (not necessarily good for gmail of course). Among other goodies for developers, there is a JavaScript API to show Growl notifications on certain events or display a badge on the dock/app switcher icon.

Fluid site specific browsers for Acquia and Gmail

On the screenshot: Coda, Forklift, Gmail app (Fluid), Acquia app (Fluid), Safari, Firefox and IEs4OSx.

What I also found it great for is task specific application generation. At Acquia, we have our own webmail interface, a user story and bug tracking system, we are running different levels of staging setups of what is going to be launched next, so there are lots of tabs to have open for work. If this is all hidden behind a generic browser icon, preferably with multiple browser windows open (for different task areas like the aforementioned work stuff, community module maintenance or blog post research), even getting right down to work after the occasional personal email detour is time consuming.

There come the Acquia Browser. Fluid can be set up to allow any URL to be opened in an SSB, thus making it a more general purpose browser. While this sounds like going against the SSB concept, you can still assign a custom icon to the browser, make it remember your usual tab set for that task and from there, you can either open links in the same app or in your default browser depending on your choice in a right click menu on links. This lets me keep my Acquia related web applications, test sites, etc in the Acquia Browser app, while more general purpose web browsing is done in the default browser app. It also helps security, since my work related browser sessions are kept to the Acquia.app and not shared with the browser used for general browsing. And it also improves productivity in more minor ways like the actual Acquia icon bouncing in my dock when an Acquia calendar notification fires due to a meeting coming up shortly.

Some tips if you are building a task specific browser with Fluid:

  • Choose to show the address bar and tabs in all cases. Check some demo videos of Fluid features to get a better idea of what is possible: http://www.viddler.com/explore/itod/videos/
  • The favicon generated application icon will most probably be useless. Just grab a suitable icon from the Flickr group (http://www.flickr.com/groups/fluid_icons/) or make yourself a quick one, like I did with the Acquia logo. Make sure to have transparent backgrounds where appropriate.
  • Choose to open new tabs instead of new windows, which works great for Google apps. Unfortunately Fluid does not support dragging and dropping tabs from one window to another in the same app, so keeping tabs in the same window in a focused app looks like a good idea.

By the way, Fluid is not a unique concept at all, it was mostly inspired by Mozilla Prism which is a similar – albeit due to its cross-platform nature less feature-complete – single site browser application by Mozilla Labs. It is available as a standalone version and Firefox extension version as well. Fluid is developed by Todd Ditchendorf, who used to work for Apple as Dashboard Engineer, developing Dashboard and Dashboard Widgets for Leopard, so no wonder he is doing closer integration of the site specific browsers to the Mac desktop.


dalin's picture

So this is basically a fancy shortcut that moves us away from tabs and back to the cluttered separate window concept?

I don't quite understand the appeal.

Gábor Hojtsy's picture

Well, we have different work styles for sure. Some reasons from the top of my head on why is this good:

  • Tabs cannot tell you number of unread stuff, upcoming events, etc in the dock icon.
  • A specific browser tab you cannot switch to with any application switcher.
  • Tabs in the same browser are in the same application, thus slowing down together or crashing together; having different processes avoids this problem (Google Chrome does this, and you can achieve this by using separate apps with Fluid).
  • Tabs in the same browser share the same cookie space, so if there are CSRF problems on the important sites you use, other sites you visit can take advantage of that.
  • When a custom browser app displays a notification, such as with Google Calendar, your actual app icon starts to bounce to notify you, not a generic browser icon. I think it is great to see the Acquia icon bounce when I have an upcoming item in my work calendar.
  • Tabs cannot be assigned to Spaces in Leopard.
  • Generic browsers don't have APIs to emit Growl notifications.

Add new comment