We’ve slept only a few hours today, to wake up early and drive in awful rain to Koper. Tim Bray was speaking at OOoCon 2005 and I didn’t want to miss it.

I wasn’t disappointed. He’s an excellent speaker and even though I can’t say I’m a dedicated user of any office suite, I found his talk very engaging and thought provoking.

As every WordPress user knows, blogging interfaces can be rather underwhelming. And WordPress is just an example, as the same can be said about most of them. But users are certainly not getting help from current versions of suites. Sad state of Blogger plugin for Word only exemplifies that.

Therefore OpenOffice of the future should recognize the rising popularity of blogs, wikis and personal voice on the web and do for them what yesterdays suites did for business communication (forgetting downsides for a moment). Making personal publishing less painful and more flexible.

If I understood Tim correctly, he wants to go even beyond that and imagines a world where OpenDocument is a sort of an HTML of tomorrow. Meaning it’s an open container for our data, that would get used by a different applications in myriad of ways, but would never lock our data in.

I’ve been looking at Atom and its publishing protocol lately and just thinking about it and about Tim’s talk, makes my head go dizzy from all the possibilities.

Update: You can also find video and audio of keynote and other talks here .

Sometimes, I really am an idiot. A couple of years ago I was involved in development of a front-end Zope application for a major Slovenian ISP with more than 100 000 users. No matter what we did, Zope just wasn’t fast. In fact it was so slow, it was soon abandoned for one more suitable solution.

The failure of our project was largely my fault, because I haven’t made sure Zope was a good fit for what we wanted. I learned a lot, but it also left a bitter aftertaste and a question, why are people using it?

The obvious answer is of course, because it DOES fit their needs. It’s just that they are not building a site or an application that needs to handle few hundred simultaneous requests. They handle a few at most, so Zope or Plone or what-have-you is more than speedy enough and it’s their features that count.

It really took me awhile to grasp this and it only became really clear this week, after reading a little Plone benchmark and having a discussion with Sebastjan about slowness of Slovenian sites.

On a positive note, we generate pages in less than 6 ms now and can reduce it even further, if needed.

There’s one thing that really bothers me, when it comes to design of forms. Well, more than one really, but let’s limit this discussion to just one.

Submit buttons.

I can’t stand their look, especially geek chic design of early nineties presented in Firefox and its relatives. I guess industrial look and Motif widgets were never really my taste. But even more pleasant design of buttons in Safari can look out of place with some designs.

There’s also an alternative that is often used. Image input buttons (type=image) can provide a more pleasant look, but they have one big disadvantage compared to submit buttons. They don’t scale. Not really something I’d want in an accessible interface.

I used a hardly novel idea of defining image measurements in relative units. Browsers usually don’t do this. They lay it out in original size using absolute values. Hence, when you change the size of fonts, the size of image stays the same. But if you use relative units, you get desired scaling effect. It might look like crap, but at least it can be readable for people with impaired vision.

As you can see in simple demo , experiments with em’s haven’t worked really well. There are two distinct problems. First is to find the relative size that doesn’t stretch an image in either direction. Second, to do this in a cross-browser compatible way.

My demo kind of works in Safari, but not really in Firefox and I have no idea about rest of the bunch. So, has anyone solved this problem?

Update: I managed to get a better result. You can read about it here.