BigBlueHat

Firefox 3.0 is the upcoming version (currently in beta) of the most flexible browser on earth (very little bias, promise ). I recently installed the latest version available to Ubuntu 7.10 users (Firefox 3.0 beta 3, I believe), and so far it’s been a joy.

Overall Firefox 3.0 beta 3 seems faster and looks better with the rest of my operating system. In the past, Firefox had its own set of user interface (UI) widgets (the buttons, menus, tabs, checkboxes, etc). While perfectly usable and even attractive, they were inconsistent with the surrounding interface.The Firefox team has done a great job of using the native widgets that your operating
system uses. This means that when I restyle my desktop theme (which you can do easily in Ubuntu by the way), I’ll see those changes reflected in my browser.

Beyond just a more consistent UI, Firefox 3.0 now passes the infamous Acid 2 Test. Acid 2 tests how well your browser implemented standard web technologies. The Internet Explorers have been notoriously bad at getting Acid 2 to work. IE 8 will, but only if you “opt-in” to use the standards. A List Apart, Issue 253, has more on that coming apocalypse.

As Firefox 3.0 continues to work through the beta process, many extensions are getting an upgrade. Many of mine worked when I installed Firefox 3.0 late last week. Others, like Firebug, didn’t initially, but it turns out there’s a beta for that as well (1.1) that gets things running again. Firebug really deserves its own post, but if you’re a web developer and you’ve not snagged a copy of this free (BSD-licensed) powerhouse, you should. It’ll change the way you build sites and web-based applications. If you use AJAX or other “Web 2.0″ technologies, the JavaScript and DOM inspector will remove much of your need for coffee, but I’ll save the specifics for another day.

In any case, if you’re into what’s next for the web, get a copy of Firefox 3.0. Do be warned, though, that just like other cutting edge technology, your mileage may vary.

Most web sites build with a Content Management System (CMS) do not send the correct “Last-Modified” date to the browser. The average CMS (include WordPress which runs this blog) show the current time as the date the page was last modified. The truth, though, is that the average web page or blog entry hasn’t been touched for some time (and certainly not in the last 30 seconds).

BlueInk, however, outputs the date the page was actually modified last. If you view the home page, for example, and click “Tools | Page Info…” (or the like for your specific browser), you’ll see “Modified: 02/13/2008 11:19:30 AM” That is, in fact, the last moment I made a change to that page. Yesterday, though, before we added this marginal but useful feature you would have seen whatever your current date and time are.

So why should I care?
While this may be the first time you’ve ever bothered to look at the page info for a web page, this data is useful to other web sites and web services that may interact with your web site. Search engines would be the first most obvious group of services to perhaps use this info. The growing number of “Web 2.0″ applications and even what are being called “Web 3.0″ or the “Semantic Web” applications could (and likely will) make use of that data.

We hope that our increasing “geekiness” about HTTP, REST, and other web standards will continue to pay off for our users in ways none of us may yet have envisioned. We’ll keep the future in mind.

With the new year come new ideas. Ben and I have been brainstorming and/or barnstorming about the future direction of BlueInk, and let’s just say some exciting things are in store. Our major goal is incorporating control over the site layout and design, so that those who want to manage more than just content can do just that. Perhaps we can coin a new acronym, CDMS, to stand for Content and Design Management System. And like my long lost cousin Jesse James Garrett, I too will become known for condensing a perhaps vague and far-reaching concept down to four capital letters.

There is an excellent series of startup related posts at AdaptiveBlue’s BlueBlog (found via ReadWrite/Web).

One thing I found confusing, though, was the recommendation in the infrastructure tips to use Google Analytics because of its API. Google Anayltics does not currently have an outbound API, though they do have a custom tracking API via ga.js (rather than urchin.js) [2]

The dashboard is customizable, but the only way to integrate your stats into another product or a centralized dashboard for all your sites is via a web-scrapping API (for CakePHP no less).

I’d love to see Google open up the analytics data we’re giving them, so we can present it elsewhere. There is Clicky and probably others, but Google’s done so much to “open” their infrastructure, it would be great to see them open this valuable source of data (that we’re providing them, no less). Perhaps Amazon could leverage their Alexa service offerings to create a more direct competitor.

The articles are good reads in any case.

“Comet is an umbrella term for any technique that allows a web server to “push” events down to a browser.” — Simon Wilson

Imagine web-based chat apps, calendars, and weather widgets that don’t poll the server ever ‘x’ seconds, but rather update only when notified by the server. That’ll save some bandwidth, certainly.

It’s certainly something we’re looking into. We’re already heavily (and happily) invested in AJAX technology, and I think Comet will be a nice addition for some new applications we have in the wings.