jasonrumney.net

Google's Picasa is great for managing your photos. It even has an Export as HTML Page option, which lets you generate a webpage for your photos. But all of the page styles it generates are very simple - if all your photos aren't the same size and orientation, the result is messy.

There are some good web page designs around for photos. Lightbox 2.0 is one, but you have to code all the HTML pages by hand, which is tedious and error-prone.

Picasa lets you generate ugly web pages easily, and Lightbox 2.0 lets you generate good looking web pages with a lot of effort. Wouldn't it be great if there was a way to generate good looking web pages as easily as you can with Picasa?

When exporting from Picasa, you have the option to export the page as XML Code. This isn't very useful by itself, but with an appropriate stylesheet, you can easily transform it to anything you want. I wrote a stylesheet for converting to a Lightbox 2.0 style blog entry.

picasa-to-lightbox.xsl

Because I use this for blog entries, not complete webpages, there are some stylesheet definitions missing from the generated html, along with the rest of the html head section. See the Lightbox 2.0 webpage for details on what is needed.

To convert Picasa's generated index.xml using Xalan, I use the following command-line:

java -cp xalan2.jar org.apache.xalan.xslt.Process -IN index.xml -XSL picasa-to-lightblox.xsl -OUT blogpost.html

Leave a comment if you have any more Picasa tips.

With Chizuko and Arata in Japan for the last 2 weeks, I've had a lot of time to catch up on where the industry is and do some thinking about projects of my own that might have some potential. I've been up late reading specs, and trying out new software. Flock has introduced me to social bookmarking, something that sounded like a fad to me before, but with it built into the browser, I am finding it useful, if only to keep my bookmarks in sync between the different PC's I use.

The other main features of Flock are a built-in RSS aggregator, but it is not as good as BlogBridge which I've also discovered recently, and a built in blogging client, which looks suspciously like Qumana, but does not work with Roller, so is useless to me. Qumana on the other hand does work with Roller, but not with non-Latin languages, so for now I'm sticking with the web based "editor" built into Roller.

Part of the thinking about projects I could start has been thinking of names. The main criteria is whether a domain name is available. I thought briefly about placing dot's strangely, a la del.icio.us, but then I thought of the first site I'd heard of that did that - goatse.cx (not linked for a reason!), which put me off that idea. If I hadn't been put off already, I would have been today, after reading about the upcoming social bookmarking site ma.gnolia.com. Too much bandwagon jumping for me, and with the .com on the end they seem a bit confused about whether they want to be a hip Web 2.0 co.mpa.ny or a so last millenium dotcom. I'm sure the VCs are banging down the doors.

Looking at the latest buzz around Web 2.0, my impression is that tagging is to the Semantic Web what the web (or HTML) is to Xanadu. Its the inferior technology that comes along much later and steals your thunder. Its a simpler idea, and is here now and gaining mindshare quickly.

On June 1st, W3C are running a workshop on Web Applications and Compound Documents. Some of the participants seem to think the two are linked, and it is no surprise to see it is being held at Adobe's offices, given their interests in pushing PDF (Compound Documents) Forms (Web Applications) as the platform of the future. Adobe's vision of a future of applications built on Compound Documents seems as absurd to me as Macromedia's vision of a future of applications built on Vector Animations.

Mozilla seems to have forgotten about XUL and, teaming up with Opera, proposes a future set firmly in 1997 where Mozilla and Opera strive for the goal of making DHTML/Javascript applications designed for the benchmark IE6 work properly on their respective browsers. Or not.

Microsoft's two position papers strike me as arrogant. With no substance, they might as well have just said We're Microsoft, give us a place at your workshop. Or else.

Most of the submissions talk about Compound Documents, which don't interest me so much, and a few of them seem to get sucked into making tenuous links between Compound Documents and Web Applications without substantiating them. I guess they just felt as confused as I do about the lumping of the subjects together and felt the need to appear knowledgable.

Origo seem to get it with respect to part of what we are trying to do with Altio. Reduced need for procedural code. Most proposals for the RIA (rich internet application) platform of the future retain ECMAscript (Javascript, ActionScript, whatever else you want to brand it) as the main way of providing richness. UI designers don't make good procedural programmers, and procedural programmers don't make good UI designers. We need to separate these tasks, and that means getting rid of the need for scripting altogether for most common UI use-cases. Then again, Origo goes on to talk about how great XForms is, so maybe they don't completely get it. XForms look great when you put it next to HTML, but it isn't rich enough for developing a real interface without writing dreaded procedural code to run the UI.

I had to laugh at the title of Laszlo's submission: The Future of the Web is not the Past of Windows. I thought for a minute they were going to launch into an attack XAML's obvious origins as a thin XML layer over MFC (AKA a thin C++ layer over the Win32 API). But sadly they are just pushing Macromedia's applications as Vector Animation bandwagon. Standard Widgets? We don't want standard widgets, we want graphic designers who make every app look and feel completely alien compared with everything you've used before. Pretty, yes. Practical, no. They have their place in advertising, games, marketing, interfaces that are fairly straightforward and difficult to get lost in, but for serious business apps, sorry but we need standards.