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.

Regular users of BlueInk may have noticed that BlueInk now has backend search functionality. Brad began work on this near the end of last week, and got it rolled out on Monday–which also happened to be National Inventor’s Day, though, like most inventors, we forgot to celebrate.

The new search functionality provides a quick and easy way to find content items without needing to remember its name. Additionally, users will see a list of pages the content item appears on. This allows the user to know exactly where the item is in use before they decide to edit it.

If you’ve not tried BlueInk yet, please check out the demo. We’d love to know what you think about it.

One of our primary goals with BlueInk is to save web content editors as much time as possible. We hope this adds to the arsenal of usability BlueInk already offers.

Resource Description Framework (or RDF) is something that’s long held my interest. RDF stores things like we thing in triples. Triples are very similar to sentences. They have subject (resources), predicates (traits or aspects that express relationship to the object), and objects.

Without going into to much more technical information, imagine that your computer had access to data stored in a similar method that your mind stores information (once you know a language anyway). Applications could then create relationships between things that have similar subjects, predicates, or objects–”if the sky is blue, what else is blue?”

In the book, Practical RDF, I picked up this “rule of thumb” for when to use RDF:

Use RDF if “the data is of interest, descriptive, and not easily discovered by any other means.” — page 11, Practical RDF

That said, RDF seems to be best suited for data that’s not available in the document, but that the computer may need to know about (now or later). Things like “last modified,” “program used to create,” “mood of author upon creation of piece,” or whatever.

As the “Semantic Web” (or “Web 3.0“) finally begins to become a reality, you may run into the letters, RDF, as you wonder around the web. In any case, RDF will likely form the backdrop for many programs you use. If you’re using Mozilla Firefox or Thunderbird, it already does.

I personally hope to see RDF take a bigger role in our data processing and distribution as the web becomes more open and useful for more than just browsing.

A bite-sized case study of declaring fonts in a PDF document:

Zend_Pdf (from the makers of PHP no less):

$mainstyle = new Zend_Pdf_Style();
$mainstyle->setFont(Zend_Pdf_Font::fontWithName(Zend_Pdf_Font::FONT_HELVETICA), 9);

FPDF (open source project last updated 3 years ago):

$fpdf->SetFont(’Arial’,”,9);

FPDF wins.