Symphonious

Permissions and an edit link.

All too often we think of wikis as some special breed of software that’s completely different to CMS. In reality any good CMS should be able to be a wiki simply by opening up the permissions, removing the workflow and adding an “Edit this page” link when viewing the site. The problem is, most CMS implementations spend all their time focussing on locking things down and adding 10 stage workflows. It’s no wonder user adoption is such a problem, no one has the required permission to do anything!

So it was refreshing to see James Robertson’s article What intranet CMS’s can learn from wikis:

At the end of the day, I don’t care about the publishing tools that underpin the intranet, as long as they work and are used appropriately. I am also not arguing for throwing away our intranets and replacing them with wikis. That would be naive.

It is, however, a good time to take a fresh look at how we manage and grow our intranets, and to learn lessons from the wider community.

Indeed. Learn to find the balance. There are a lot of documents on the intranet where you need to get them right first time - critical policies and procedures etc, but there are also plenty that should be more living documents and evolve over time, benefiting from the experience of your employees. Open up those documents like they were in a wiki and you’re on the road to a successful intranet, without the confusion of having two completely separate systems.

Dear lazyweb (actually, just more intelligent web, I’ve done a lot of searching on this already…),

I have a nice install of WebSphere Application Server and IBM Portal 6.0.1.3 up and running with the WCM component configured. This is great, really happy.

I’d like to add Quickr (later also Connections and maybe even Sametime) but all the Quickr installs I can find want to deploy a second instance of WAS which isn’t ideal. Is it possible to just add Quickr to an existing install or is it possible to install it separately and move it into an existing install?

Since the search function for Apple’s mailing lists is pretty much useless, I’m making a note of the Reading PICT Images thread which contains numerous options for rendering PICT images in Java on OS X.

So here’s a surprise - FireFox 3.0.1 can’t handle RSS/Atom feeds that have a port number in the URL. The problem stems from the fact that it uses a custom feed: protocol instead of just working off of the mime-type of the content.  So if you visit http://www.example.com:10038/ and it provides an RSS autodiscovery link that points to /feed/, FireFox will try to go to feed:http//www.example.com:10038/feed/.  Note the missing colon after http.

What’s even more odd about this is that the actual request it sends is for the URL: http://feed://http//www.example.com:10038/feed/.  Bizarre!

I’ve always liked the Atom spec. It’s neat and tidy with strict rules about what’s valid and what’s not with all those rough corners and incompatibilities of RSS sorted out (well, mostly). If I run into one of the silly sites that offer both RSS and Atom I pick Atom just because it feels right even though both would work perfectly well for me. So it came as quite a surprise to me to discover a major weakness in the Atom spec - it’s a right pain to generate. Let me explain…

For various reasons, I’ve spent a fair bit of time over the last few months converting LiveWorks! from being hosted on WordPress to being a “real” website running on Lotus Web Content Management (IWWCM - yes I know the acronym doesn’t match the current name).

Anyway, one of the things that’s baked into WordPress because of it’s blogging culture is the concepts of RSS/Atom feeds. IWWCM comes from an entirely different world so the concept of feeds is quite foreign to it. Fortunately, it’s a very flexible system and has some simple tools you can throw at the problem. All you do is use a “menu”, which allows you select content from the repository according to certain criteria and order them any way you want. In this case, we simply order by published date. Menus in IWWCM have a head, a bit that’s repeated for each item and a footer. So you throw all the XML from before the first item in the head, a template for each item in the repeated bit and close off any remaining tags in the footer.  Simple enough.

The problem is, Atom doesn’t follow that structure. Atom includes one key piece of the content items below in the head: the most recent update time. In order to generate that head section of the XML, you have to have the meta data about the most recent item in the system. In most cases that’s fine and having that element makes parsing an awful lot simpler, but it’s a surprisingly annoying requirement. The IWWCM menu structure, simply can’t handle this and so can’t generate a valid Atom feed.

RSS on the other hand wasn’t as nicely designed to make detecting changes simple. It doesn’t have to have that updated element in the head section and so it’s perfectly suited to the IWWCM menu structure. So, LiveWorks! has now switched over to RSS 2.0 and apart from an implausible date due to some weird leaps around time zones and an article publishing a day early, it’s feed validates.

This isn’t the first time I’ve cursed Atom for this either - at least for me, it just seems so natural to follow the simple iterator pattern that IWWCM’s menus use so I’ve run into this a few times. Mostly it just takes an extra if statement or similar to special case the first item but every so often it requires some major reworking and in cases like this, it’s just about impossible to do.

That’s trade offs for you though. If that updated element wasn’t required, there’s a whole bunch of cool stuff on the consumer side that wouldn’t work. Oh well.