Thursday, December 06, 2007

Rich Text Editors

As a regular reader of this blog, you may have noticed the different line-spacing on my last two posts.
I started using the 'Compose' editor in Blogger, instead of the 'Edit HTML' editor.

The 'Compose' Editor only started working for me recently, once Safari 3 came out. It is easier to use, but I am not sure I like the tighter spacing for reasons of readability.

As an aside, I was mildly shocked recently to realise that when you use some of the new breed of RTEs like the one on Dojo 1.0, the output HTML is different, depending on the browser you use.

While it is really great that cross-browser/platform RTEs are becoming a reality, I imagine that this lack of consistency is going to freak the bejebus out of some content-management types I know.

Sharing Calendars

Always on the hunt for replacements to the functionality that dot mac used to try to provide me, I decided to try out CalDAV. I chose the implementation by Apple, released as Open Source on MacOSForge.

Using these instructions, it was easy to install.

In short order, I had it installed, running on HTTPS with a self-signed certificate. A bunch of users and locations setup and ready to go.

Leopard comes with a built-in CalDAV client, the iCal application, I only have Leopard installed on one machine ATM (I have CalDAV running on an old Cube under Tiger), so wanting to experiment with sharing, I invited by brother in Australia to join me.

Once you have added your Cal Server account in iCal, it is as easy to create new calendars on the server as it is locally. I am confidant that when I have more machines running Leopard, they will all be able to share the same calendars between them.

Sharing a single user's calendar between multiple users is still a problem though. According to the plan, you ought to be able to assign levels of sharing in your own calendars from the client, this does not seem to work yet as far as I can tell.

My brother and I can share a calendar, and it works well, but in such a way that it has to be setup in advance via server configuration. I made a 'location' and added our two users to it. We can both add, edit and delete each others entries. We have not tried any of the auto-scheduling features yet.

I do not have access to Leopard Server, so I do not know if the version of Calendar Server that comes with it suffers from the same problems, but regardless, the free MacOSForge Calendar Server is already a very useful tool for any workgroup, club, family or individual with more than one computer (CalDAV is a cross platform standard).

If you have a server knocking around, give it a go :)

PS. I am spending the next two weeks in Holland doing some work. I will know pretty soon just how good or bad it is to be on the road using a remote calendar !!

New Design

I have updated and relocated again.

I have had a home page of one sort or another practically ever since it was possible to have one. I do wonder sometimes if it is worth the hassle, but occasionally people do find me through it, whether for work or some friend or family member looses my contact details, I guess it is still useful.

I really had to do something about the design (clearly ripped from Blogger), I had got so sick of it. Being such a stickler for good code, I had always hand-coded my site before. This time, feeling a bit lazy, I decided to see how iWeb would work.

iWeb has the look and intuitive feel of the iWork applications, which I like. However, unlike Keynote etc. it seems to lack the ability for the user to build new templates, most of the built-in templates are pretty nasty, but luckily there was one (Modern) which I found bearable.

I found iWeb very easy to use. I found not having to write the code myself (and make it work across platform), freed me up to think much more about what the purpose, message and content of the site should be, which was refreshing.

The Prototype AJAX library is built-in to iWeb-generated sites, this brings some quite funky behaviour, like a half-decent slideshow widget etc. which I appreciated. The implementation is a bit over-the-top though IMHO. The slideshow dynamically loads photos using an RSS feed to specify the contents, which while being clever, is a bit pointless, every file is overwritten during export, so this could have just been burnt into the html. Some of the things they do are just plain silly. If you want a link that opens in a new window, instead of just adding a target attribute, they add several JavaScript Event Handlers to do the same job ;-)

One behaviour I definitely appreciated was the ability to dynamically pull html snippets into the page at runtime. I used this for my email address, crawlers looking for this info will not find it, unless they execute the JavaScript.

Since iWeb was never designed for someone like me, I inevitably had several issues with it, here are some of them :

Layout: Not surprisingly, considering how the program works (like a DTP program) all of the layouts are generated using absolutely positioned div tags. What is unfortunate is that Apple decided to use fixed units of measurement (a bad mix of pt and px) meaning that the layouts do not scale properly if a user presses command-+, the individual divs begin to crop their content or overlap their neighbours. Interestingly, Apple realised this, but instead of fixing the code output, they seem to have fixed Safari 3 not to zoom iWeb sites (Safari 2 and Firefox still zoom) which to me is a strange way of working !! The way I have solved this in the past is to place a default text size on the body tag (font-size: 10px;) then use a relative unit em in the elements I want to scale properly. In this situation 1px = 0.1em. Easy.

Meta-Data: The ability to control meta-data is almost non-existent. You cannot do things like add your own title attributes to links, alt attributes on images, or add your own meta tags to the head. I am used to having full control over stuff like this, I like proper Dublin-core and geotags in my pages, yeah I am geeky :)

Standards: I am used to making my sites fully compliant with w3 standards, I like to get WAI-AAA compliance etc. as well. Of course this is just professional pride, so few people visit this site, it does not really matter ...... but it could have been something Apple just got right ......

URLs: Being a Cocoon developer, I am used to having absolute control over all URLs. iWeb is not really designed like that. iWeb is designed for pumping multiple 'sites' out to a single dot mac address. Each 'site' in iWeb has the site-name at the top level of it's URL. So that you can go from my.tld/ to the default 'site' Apple output a /index.html with a meta-redirect. I do not like that and you do not seem to have any control over it.

Conclusion: Well, the fact I actually published the HTML made by iWeb shows that I found it just about  good enough. I did resort to some post-processing on the exported files to solve some of the problems above, but this is obviously a nuisance. The point of tools like iWeb is that they make it really so easy to make and publish changes, you are likely to do it more often. Having to post-process the HTML really spoils that experience.

Note: Since publishing this site a few days ago, it has gone from 1st to 2nd position in Google when you search for my name, hmmm what have I done that they did not like?

[1] The site was hosted as a favour by Andrew Savory for many years. Many thanks Andrew! Now it is on an old Mac Cube at home.