Along with something in excess of 10 million other people, I downloaded the newly released Firefox 3 last night on my OS X box. (I'll upgrade my Windows XP installation down the road.)

I was immediately struck by how much more comfortable FF3 felt than FF2 ever has. At first, I couldn't figure out why. Then I noticed the buttons and other UI elements are Aqua-fied so that the browser now has a much more Mac-like feel. That is very cool and for some reason, it tickles me.

FF3 does seem faster and I do like the new intelligent browsing from what I've seen so far. The location box has been turned into a search object so that as I start typing a URL I'm not only seeing a list of URLs that start with those characters, but also recently visited pages that match the criteria. For example, if I type "mai", FF3 brings up my gmail link. Over time, this will probably change the way I browse, though it may cause problems for site owners whose users may not be as readily able to identify them from ever-complexifying lists.

Overall, first impression is very good.

Over the past few weeks, I've been investigating the new state of the art with respect to the Web as an application development platform, focused on Web applications rather than on desktop apps with Web connections. This is all part of my renewed interest in the "Zero-Pound Computer". If we can store our personal data in the Cloud and if we can run applications that run in the Cloud, we can (or so I claim) look to the day when we won't take computers with us when we move, we will simply move to a new computer and our software and data will follow us.

The five major online services who have opened their APIs to developers to encourage the creation of applications that run in the Cloud are Google, Amazon, Microsoft, eBay, and Yahoo. Together they are often referred to as the GAMeY players. A good friend and colleague, Laurence Rozier of Meshverse Journal fame, has been buzzing a bit lately about Amazon's interesting array of Web Services. Of course, I have been aware for some time of Google's offerings, being, as I am, a Googlite. I was aware, too, of Yahoo's efforts to create JavaScript UI technologies and scripting libraries and overall impressed with their efforts. These three (dare I suggest the acronym GAY or might something like GoogazonY be more appropriate?) are getting the bulk of developer attention, with Google leading the charge by a considerable margin and Amazon coming in a fairly distant third behind it and Yahoo.

But Amazon may have The Secret Weapon in all of this in its unique combination of SS3 (Simple Storage Service), EC2 (Elastic Compute Cloud) and AMI (Amazon Machine Images). Couple those with its less known DevPay service and you have a platform that can effectively become your company's server farm and micropayment management system. None of the other players have these tools, and that has some important implications for who can and will use these Web APIs.

I just purchased James Murty's Programming Amazon Web Services from O'Reilly and while I'm just starting to delve into it, I am already fairly impressed by the breadth of the Amazon offering, a breadth which doesn't come through in checklists of API comparisons like this one. (Don't get me wrong, though; that checklist is quite handy in its own way.)

Interesting side note. The example code in Murty's book is almost all in Ruby. Python samples are available via download, but it is surprising to me that Ruby got the front-row seat here. Without Rails, Ruby is a very interesting language but not nearly as mature as, e.g., Python. Strange choice by the author and O'Reilly. I'll have more to say about the Ruby Surge in another post some time soon. Unless I lose interest. :-)

I mentioned Scribus in an earlier post today. I went to download it to give it a spin but I can't quite figure out how to get it to run on OS X without wrapping it in X11, which I refuse to do. If I wanted to run it in X11 I'd run Linux.

There's supposed to be an Aqua port but the links are dead so I don't know what's going on. If you do, let me know!

Meanwhile, the adventure of trying to convert HTML table cell text to justified text in a document I can get to print in a 6x9 book format to a PDF is turning out to be far more work than I ever anticipated. I'm just about at the point of deciding to bite the bullet and manually reformat the text but it's over 400 pages.

Every single approach I've tried -- and I've tried a bunch of them including about 10 or 12 new ones today -- breaks down somewhere. Some come close, but no horseshoe. This really shouldn't be so hard, I keep telling myself.

Right.

I'm about to embark on a project that involves converting a large stack of handouts I've done in HTML over the years into a couple of books intended for publication both as eBooks and as dead-tree products. To do this, I need to convert these HTML files to PDFs that format properly, paginate well, look good from a type perspective, etc. In other words, I need a desktop publishing solution that plays nicely either with HTML or with some format to which I can easily convert HTML without headaches and lots of manual tweaking after the fact.

In my search, I ran into an Open Source DTP tool called Scribus that looks very promising. Some research suggests that it doesn't swallow HTML frogs particularly well (though it may not be too bad; I'm going ot run some tests later this weekend to see, I think). But Scribus imports Open Office format (.odt) documents and, as you may know if you've been hanging here for a while, I use OO to the exclusion of other office programs.

So I followed a couple of links and stumbled serendipitously into a marvelously useful and helpful blog maintained by Solveig Haugland, who has a rep as one of the premier Open Office trainers and writers on the planet. Wow. That blog has taught me about 15 new things in the first hour of exploring it.

If you're using OpenOffice (or its Mac clone NeoOffice, which I prefer and use daily), or if you're just thinking about switching from Micro$oft Offi$e to OO or NeoOffice, you really should take time to look over this wonderful work.

I'm off now to experiment with NeoOffice Writer to see if I can produce a book-quality PDF with it, directly or by importing from it into Scribus.

Oh, and Scribus has another nice feature: it's Python scriptable. Woohoo!

Jean-Louis Gassee, when he was VP of product development at Apple Computer, used to love to say, "God is in the details." (Yeah, I know he didn't originate that quotation; Ludwig Mies van der Rohe did.) I always knew instinctively that he was right. Today brought me another bit of evidence.

I normally use Firefox as my browser. But last night before I turned in, I was exploring Sun Labs' Lively Kernel project, which runs best in Safari 3, so I fired up that browser. (It would be my browser of choice but I rely on some Firefox plug-ins and I still run into the occasional site that doesn't render properly in Safari.) This morning as I went to check my email, Safari was already open, so I just used it to log into my Google Mail account.

As I worked on my mail, I was struck by the subtle, almost undetectable sense that this experience was somehow crisper and cleaner and more "elegant" than my gMail experience in Firefox. As that notion crept into my consciousness, it occurred to me to wonder why I felt that way. So I opened the two browsers to the mail page side by side. (Have I mentioned lately how much I love my 24-inch iMac?)

The only difference between the two displays as far as I could tell was the buttons in the browser. Safari renders the buttons as round-cornered rectangles with clear outlines. Firefox renders the buttons as rectangles with slight drop-shadows. Somehow, the round-cornered buttons stand out more crisply. Also, Safari uses a slightly cleaner font on the buttons. The net result is that the page looks and feels more like an application than a Web page.

My good friend Laurence Rozier of Meshverse Journal fame sent me a link to one of his posts todsy that included a pointer to this great cartoon. It'd be funnier if it weren't so true.

I'm something on the order of 20 or 25 years older than Laurence, so I've seen even more of this kind of language phenom stuff pass by.

Here is Laurence's post in which he takes a quick look at a couple of emerging server-side JavaScript (SSJS) implementations that may have enormous implications for the new direction technology seems to want to flow naturally: fewer restrictions, more openness, more accessibility, decentralization of control.

I wonder what Brendan Eich, the inventor of JavaScript, is thinking about all this.

Anyway, enjoy the cartoon.

Google is moving strongly into the social network space, but not by adding yet another social network to the dizzying array of such sites already vying for eyeballs. Instead, Google plans to offer a neutral JavaScript-based platform for creating apps that run inside social networks. This is a very smart position for Google to take. Its own social network, Orkut, has been a rare major bust for a company that often appears it can do no wrong. At the same time, Facebook has made great strides in gaining users of late, at least in part due to opening up its programming APIs to make it possible for third parties to develop apps that run in Facebook.

For security reasons, Facebook developed its own markup language called FBML and apps designed to work in Facebook must use that markup. This makes those apps unusable on other social networks (most notably perhaps MySpace).

Google chose JavaScript as the core language for developing the new cross-network apps. That's a smart move. JavaScript is clearly the client-side lingua franca of the Web, much as PHP is the de facto server-side scripting language, But while PHP has lots of competition, JavaScript all but owns the client side. The emergence of a loose bundle of technologies called AJAX, which makes it possible to create standalone application look and feel in a Web app, has really all but frozen out other languages in this important space.

Google has already lined up social networks Orkut, Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster, Viadeo and Oracle as partners, along with such rising app development stars as Flixster, iLike, RockYou and Slide. This leaves some awfully big social network players -- MySpace, Facebook, Microsoft, Bebo and Yahoo to name a few. But by choosing the gatekeeper role on the bridge between the social network and the end user, Google positions itself perfectly to ride above that fray. Eventually, assuming OpenSocial takes off as I suspect it will, those big guys will have to adopt Google's bridge even if only as a secondary, "also supported" technology alongside their own. And of course MySpace now has no such bridge; it will come as no shock to me if they adopt OpenSocial in the next 30-45 days.

I've been saying it since the early 90's at CNET: savvy Web developers need to master JavaScript. The case keeps getting stronger.

My colleague and friend Scott Herndon today pointed me at the latest discussion of the proper use of the term "open source" that has broken out recently. This argument started in June on the blog, though it goes back much farther in the real world outside the blogosphere.

The arguments are mildly interesting, though largely academic. But it seemed to me after I read a good many of the comments and thought about it a bit that open source vendors arguing about the proper definition of open source is a little like a pissing contest where nobody's buying the beer.

While I sympathize with Michael Tiemann in his role with the Open Source Initiative (OSI), his attempt to preserve the brand "Open Source" is fruitless. It's not a brand. Never was. Never will be. It's not protectible. At best he's got a decent meme to protect and I might even agree it deserves protection. But open source will always mean different things to different people.

Scott and I were discussing it today in terms of the need we have on one project. We don't intend to use the source code of an Open Source project in our work. What we're looking for are some ideas about issues to be covered, approaches that have been tried, etc. We're not likely to use any actual code from any Open Source app we choose to download and look at. The last two words are key to us: we want to look at source to get ideas about alternative ways of doing things anyone doing a particular type of app needs to do.

So we don't really care what license is being used; our concern is, "Can we read the source?" If we can, it's open source enough for our needs.

Maybe the problem is that the broad range of Open Source needs is too big to be covered by one brand or meme.

Mike Chambers and two colleagues have just had their book about AIR (Adobe Integrated Runtime, formerly known as Apollo) published by O'Reilly. Who else would you expect it from? Those O'Reilly folks are really on top of stuff.

You can get a free downloadable PDF of the book. Mike explains how.

I'm going to devour this sucker tonight, or at least start it.

We used to say, "One of the nice things about standards is that you can have so many of them." This was brought home to me today in a strange way.

A colleague sent me a file containing text and images whose file extension was .docx. Turns out this signals a document stored in Microsoft Word's XML format. It was created under Vista on a Windows system. I'm trying to open it on a Mac with Word:X. No joy. Word doesn't even see it as a legitimate Word document and won't open it at all.

So on a lark, I tried NeoOffice, the OS X port of OpenOffice. Voila! It opens, though the formatting is a bit off here and there. The document is definitely readable and mostly properly formatted.

I figure if NeoOffice opens it, OO on Windows ought to do the right thing. Wrong. OpenOffice, even after upgrading to the latest 2.2.x release, doesn't see it as a document form it recognizes. It offers Word 2003 XML as an option, so I try that. No joy.

So let me get this straight. Microsoft wants us to adopt its XML "standard" as a compatible file format rather than using the Open Document Format (ODF) which is beating the pants off Microsoft XML all over the globe. But the format's not even backward compatible with its own product on OS X. NeoOffice is supposed to be a port of OO, which means it should lag the latter in features.

Moral: resist Microsoft's blatant attempt to establish a new proprietary standard. Insist on Open Document Format.