WCM rant

CMS GUI Language support (and removing it)

2008-11-18T11:31:00.006+01:00

There's two sides to every Web CMS when you look at it from a multilingual perspective. One side is the authoring interface language, the other is the websites that come out of it.

The websites are usually not much of an issue these days, with UTF-8 support and things like that. Much also depends on the implementation. CMS vendors will tell you that you can publish websites in any language with their product. Which is, in general, true.

Another aspect is the authoring interface language. Most content management tools will provide that in English out of the box, and then offer some manner of translating it. Either by installing extra language modules or a manual for translating the gui. For opensource tools these language modules will likely be free or provided by the community around the tool. Commercial products could have several languages out of the box (like Interwoven TeamSite) and/or provide the option of buying extra language packs (Tridion for example).

Whether or not you want a translated interface is another question. Your companies first line support may have trouble explaining which button to click in a french version of the interface, let alone one in simplified chinese. But that's another matter.

Interwoven offers TeamSite with several localizations out of te box. When they say their tool is available in a certain language, they mean that everything is localized; also the documentation! That's not something you should take for granted.
It supports these locales: English, French, German, two types of Japanese and 2 types of Chinese (Traditional an Simplified; don't ask me about the difference...).
I'm mostly interested in the first three, and in the one that's missing from that list for implementations in my region; Dutch. But that's not really a big problem, since most users here are accustomed to working in english interfaces and don't expect everything to be translated.

However; When Dutch speaking user, perfectly happy with working in an english interface, sees his French speaking colleage at the next desk working in a translated interface, he may start to wonder. In the worst case you get a union guy or gal pointing a finger and screaming "language discrimination!", demanding that the interface be made available in dutch as well.
Anyway, that isn't at all a situation happens regularly, but you may want to avoid it regardless. Together with the first line support aspect I pointed at earlier, we do have something of a case for removing the support for a particular language and making sure it's always in the same language; English. (sorry for the people that put all the hard work into translating every last label)

So a customer comes up at you and asks to make sure there's only one language available. Ok, you say, "we'll take a look at that and get back to you" (never say "no problem", very dangerous two words). Probably thinking it will be trivial, you go about browsing the documentation, contacting the vendor, checking out the code even.

There a two main ways a browser based tool can let a user choose their language; a "preferences" page where the choice can be made and persisted, or deduce it from the locale setting of the browser.
TeamSite does the second; If a browser sends "fr", then the interface shows up in french. That has the advantage that it's automatic; It saves you the trouble of having to push buttons with labels you can't read to get them showing up in a language that you do understand. Removing the support for a locale shouldn't be too difficult, you think. Just make sure it's not available on the server. There must be a way of doing that right?
Much to your surprise, when you ask customer support how to do that, they tell you (after elaborately explaining how to add an extra language) that removing one is not actually supported...

Bummer

Well, if all the browsers have their locale set to "en", they'll all have the same interface language , right?
A difficult task awaits you now when you'll try to explain that to your customer. But that gives you an opportunity as well. Now that you customer is thinking of a way to sell the multilingual interface to the support department, you can show off your understanding of web technology and the product and say; "there may be a workaround".

It may not be completely supported, but it's a minor hack that get's you what you want. TeamSite consists, among other things, of an http daemon that sits listening on port 80, takes each incoming request and considers where to dispatch it.
The server chooses the interface locale based on something that comes along with the browser request, so if you could step in and rewrite just that part, making the server believe that English is requested, you have a solution. That something is a header value and in this case the "Accept-Language" header.
And we can rewrite it with the mod_header module loaded into the http daemon.

So, to get to the point;

In the file [iw-home]/iw-webd/conf/iwwebd.conf.template

Add the following line somewhere in the middle;
RequestHeader set Accept-Language: en

Then do an "iwreset -a"
And you're done.

Language support isn't actually removed, but all users will see the interface in English now.
You have a happy customer. (but be sure to document this change; upgrading will remove the change, and by that time you will have forgotten all about it).

An alternative would be to have a separate reverse proxy in front of the TeamSite server that does the change to the header, thus avoiding any change in TeamSite config files and discussions on the supportedness of the change.

Alfresco 3

2008-10-30T11:44:00.012+01:00

The release of the long awaited and advertised Alfresco 3 Enterprise edition was announced yesterday. Just in time for a seminar I'm presenting next thursday, together with 2 colleages.

Unable to constrain myself I immediately started downloading and installing the trial version, and noticed it is now a 275Mb download. For comparisson: version 2.2 was about 90Mb, including the WCM module.

I had already started looking for the hidden flight simulator, when I figured out where a large portion of the extra size comes from; OpenOffice and the JDK are included in the install package. The same principle was applied to the Labs 3.0 beta, where you had a Full package, a package including only OpenOffice, and one called MiniSetup, which contained nothing but the actual Alfresco stuff (and a Tomcat servlet engine).

That's perfectly ok for a trial version; it makes it easy to quickly install and get into the product to see what's so great about it.

So that's what I did.

Besides; the installer still let's you choose not to install the packaged OO and JDK;

You also get the option to either choose Derby or MySql as the database.
I had a pretty good idea of what I was going to encounter, but being stubborn as I am, I chose MySql...

Oops

That looks scary to a lot of people, I know. But it's actually not such a big problem, so don't let it put you off. To fix it, all you have to do is;

1. Create the directory "lib" in [Alfresco install dir]/tomcat/shared/
2. Drop the jar containing the MySql driver in it (for instance mysql-connector-java-5.0.7-bin.jar)
3. Restart the Alfresco server

Then wait a few minutes until all the automatic database creation stuff and configuration is done and you see the line;
INFO: Server startup in 395189 ms

Next, point your browser to http://localhost:8080/alfresco/ or http://localhost:8080/share/ and start playing around.

One of the things that I wanted to check out was whether the difference between the latest Labs 3 release and the Enterprise edition was less than it had been in previous releases. Strangely Labs 3 seems to be still in beta at the time of writing :-( but on the nightly build page, I found a file called "alfresco-labs-war-3c.zip", which sounds promising. Don't know what the "c" stands for though. Maybe for "CMIS release"?

TeamSite UI Customizations

2008-10-28T13:44:00.002+01:00

TeamSite has a neat way to manage user interface customizations like adding or removing buttons, changing who can see them, adapting the look & feel of the interface a bit, ... A lot of it is well documented. Still, it's likely that you'll encounter stuff you'll have to figure out for yourself.

One possible situation is that, for whatever reason, you want to change the label of some link somewhere in the gui. After a lot of searching and a lot of coffee, you find out that this label is rendered in a class file that is is located in a jar file in, for example, [iw-home]/httpd/webapps/content_center/WEB-INF/lib
You're happy; you've found where the label came from and you know what to change to get this done. All you need to do now is go ahead with it a check the item on your todo list.

There are several ways you can apply this change;

1. The Hacker's way
Unjar the jar file, decompile the class file, remove the call to getLocalizedLabel4Key("thiskey") and write your new label there in stead. Recompile, Re-jar the bundle and restart TeamSite.
There, that's done. You're proud of yourself for having proven your technical skill etc.

This is not the best aproach for a few reasons;
- It's byebye multilingual interface; all languages will get the same text for this label from now on.
- After the next patch install or upgrade, your change will be gone
- Interwoven doesn't support this type of change.
- ...

2. The smarter way
The second option you have is; look a little further and figure out which property file the label is set in. Extract that property file and all localized versions of it from the jar. Change the label text into what it should be. Create the folder structure for the namespace in the /WEB-INF/classes folder and drop the updated properties files there.
Then restart TeamSite.

The properties file in the classes folder will have priority over the one with the same name in the jar file, so no need to make any changes there.

This is getting closer to where you want to be, but still not ideal;
- The next upgrade may mess things up again
- Interwoven will probably not support this.
- How are you going to keep track of this type of changes?

But we're almost there.

3. The way to go
Tell your client it can't be done and get on with the next thing. Or;

To do this change in a more manageable, maintainable, and more likely to be supported by Interwoven kind of way: Use the ui customization toolkit (aka uictk);
- In [iw-home]/local/config/lib/content_center/customer_src/etc create the folder "classes" and in that the folderstructure for the namespace like above.
- Take the updated properties files from option 2 and drop them in that folder.
- run make_toolkit.ipl

Always applying your ui changes in this manner will make it straightforward to maintain and manage. You won't have to keep track of all the things that need to be copied along when you go from dev to test to production.
On top of that; Most of the changes you make this way will be supported by Interwoven (you can still mess your TeamSite up if you make a mistake). I say "most", because it still goes slightly beyond what Interwoven intended to accomplish with the uictk.

In my opinion, changing a label in a properties file should be supported. As for the unjar-decompile-recompiling-deploy strategy; I wouldn't want to support changes like that either on a worldwide install base. Would you?

Alfresco Simple WCM

2008-10-03T14:18:00.004+02:00

I'm proud to say I just went through my first Alfresco WCM implementation. Well, to be honest, I didn't get to do a lot of actual coding. My involvement was rather on the functional/solution part. Other (better) programmers wrote the code.

We were migrating an existing site from a .Net based custom made cms to Alfresco. Most pages were just static content, but the most important part of the site is the integration with a crm system through web services.
In a first phase, the one that just finished, we planned to just migrate the site as-is, without any functional or graphical changes. So for website visitors; nothing looks different.
A second phase will be a total graphical overhaul and functional improvements of the site and the back-end authoring interface.

The setup was simple;

Alfresco 2.1 Community Edition on the back-end
Tomcat on the front-end
WebForms to manage the content
The rmi based deployer to get content from the repository to the website.

The Community Edition was chosen because the customer, at the moment, doesn't have the business case to justify the cost of an Enterprise Edition. Not yet anyway; if all goes well more sites will be hosted on the same environment. So we look at this project as a pilot case.

Using the Community edition, however, does have some small downsides; mainly stability. But because Alfresco is only running on the back-end, the website will not be impacted by occasional hickups (which is already a great improvement compared to the old website).

When I say "Simple" wcm, I do mean simple. There are a lot of different ways to use Alfresco in a web content management context, and this is the easiest, most straight forward way.
Most importantly, we ended up with a wcm implementation the way it should be; easy to use, straight forward, flexible, scalable and future proof. Not too many bells and whistles, just the ones that are needed to make the difference.

The site is currently in undergoing acceptance tests, so it's not yet live. But it will be soon. I just couldn't wait any longer to vent my enthusiasm.

I'm looking forward to the next project.

Interwoven TeamSite 6.7.2 and LiveSite 3.1 just released

2008-08-27T14:26:00.003+02:00

The long awaited TeamSite 6.7.2 version just became generally available. A major change versus 6.7.1 sp1 is the merge of the SitePublisher module into the installation package (you do need a new license key, but that's a minor hurdle). And moreover;

"...several new features & usability enhancements for both the administrator as well as the content contributor..."
(Sounds promising)

The SitePublisher module itself also has some enhancements;
"...Fixed Area Layout, support for FireFox browser, ability to define "search engine friendly" vanity URLs..."

As for the new LiveSite 3.1, the following looks rather interesting;
"...For customers looking to integrate LiveSite into their existing J2EE web applications, a set of "tag libraries" for rendering SitePublisher pages within the custom web application are now included ...
Developers can also take advantage of a "dynamic token substitution" framework that allows them to insert data into the META tag on the page dynamically using the tokens..."

I'll have to figure out what that last one is, but it sounds neat.
All that, and Page- and SiteControllers... I can't wait to start playing with those :-)

If you want to read more about this release; Here's the complete announcement, or you can visit the Interwoven support site.

LiveSite java version

2008-08-07T13:05:00.002+02:00

This is something you will almost certainly meet with when implementing LiveSite externals and controllers; When installing TeamSite 6.7.1, the bundled jdk version used to compile the custom java code is 1.5. The LiveSite runtime, however, can get installed with 1.4.x

When adding functionality to the livesite_customer.jar, you'll deploy that jar to the runtime servers. Chances are that, if you didn't make sure the back-end and front-end use the same jdk, you'll get a java error that contains something like; "Unsupported Major/Minor version"
To solve this; install the 1.5 jdk on the runtime servers.

This will likely be solved in TS 6.7.2, which was scheduled to be release end of last month... !?

Blog about TeamSite & LiveSite

2008-08-06T18:09:00.005+02:00

Just came across a good blog about Interwoven TeamSite and LiveSite, hosted by a UK based company called littleforest. Amongst other things, there are a few good tips there for developing in LiveSite. I also learned a new word; ‘componentisable’ in the context of using CSS in LiveSite, something that I also posted an article about a while ago.

WCM tool comparisons

2008-08-05T23:18:00.006+02:00

I notice from the keywords people search on, where this blog turns up in the top 5 results (I use the google webmaster tools for that), that a lot of you out there are looking for comparisons between specific web content management products.
That there was demand for such information is something I was aware of; it's part of the business I'm in. Another thing this tells me is that there is not a lot of information regarding product comparisons out there. If there was this page wouldn't turn up in the top rank.

Why can't you find those comparisons? You may wonder. There are a few reasons for that, among which;
1. Vendors may publish comparisons from time to time between their product and that of their direct competitors. These, however, are rarely unbiased, which is understandable.
2. To really compare two products, you need enough experience in both. This experience is valuable, so people tend to want to sell it rather than just give it away.
3. The reason you want to compare products, is usually because you want to know which one best fits your requirements. Your requirements are the key. Perhaps two tools are very similar, but just because of a few specific requirements of yours, one is a better fit than the other.

Analyzing those requirements and searching for the best fit is one of the things I do. When eventually I propose a certain tool, that doesn't say anything about the quality of the others that I investigated. It just means that this one was the best fit based on what I learned about your business.

Having said that, there are some obvious differences between some of the top players I have come across. In my description below I'll be rather brief and only highlight what I think are the main points.

OpenCms is an open source web content management tool that was initially a good fit for publishing a single website. It has evolved and matured over the past years to a platform that can be used to manage multiple websites and handles multilingual content quite well.
If you have advanced workflow requirements, you may want to look further. Apart from that it has a very user friendly GUI and an interesting caching system.
It's also free of licensing costs (which is irrelevant if your company has an opensource-unfriendly software policy)

Tridion is great if your requirements rely heavily on translations (they merged with/got bought by SDL that also has Trados). Their blueprinting concept is a unique way to handle content reuse. They are in the process of moving the entire product to .Net, which isn't going fast enough to my taste. But I understand the difficulty of supporting their existing install base while completely rewriting their codebase. A challenge not a lot of vendors would dare to take on.
The dependency on VB in some of the product's components, does make it increasingly more difficult to find programmers with the right skill set. But that will probably be a non-issue after the next major release.

Alfresco... this one is almost moving too fast for anything I could write to stay valid for very long. When it launched it focussed on collaboration and document management, but is quickly moving ahead and adding promising wcm functionalities. The standard GUI is not adapted to plain web content management though, but with the latest addition of "Surf" in the Labs 3 beta version, I'm curious as to what's next.
Of course; if your company has the "no open source" policy... But you may want to convince them to reconsider after taking a look at this one. Especially if your requirements are both document and web content management related.

Interwoven; When I get questions about a comparison between (for instance) Tridion and Interwoven, I assume people mean either TeamSite or SitePublisher and LiveSite. Those are the Interwoven web content management related products. TeamSite is a wcm tool that has been around for a long time and has proven stability and usefullness, but also carries with it the burden of some aspects of the past. (It uses perl templates on structured content objects to transform them to html or php or whatever you need. Although it has it's merits, I try to avoid using the perl templates wherever I can).
Some improvements have been made to the templating possibilities, but in the meantime SitePublisher has surfaced. First as an extra module to be installed on top of TeamSite. With the next release is will be part of the TeamSite product.
SitePublisher is fun to work with for us, developers (xml, xslt & java), and gives authors a lot more control and direct visual feedback (drag and drop pieces of content on pages) over what they are editing.
Another point that differentiates the TeamSite/SitePublisher combination from it's competitors, is the previewing capability. You're able to see exactly what the page will look like on the website while you're editing it and moving components around. Even for dynamic parts that retrieve content from other systems (a database query, a crm export, ...).

Drupal, another open source tool. I don't have much hands-on experience with this tool, but I've heard and read good things about it. It mainly targets implementations with a lot of community and web 2.0 related requirements. But it's evolving rapidly, and there's a myriad of community contributed add on modules to expand the functionality of the standard product.

As I already mentioned; there's a lot more to say about each of these products than what you read above, and there are a lot of other wcm tools out there. If you're looking for a wcm solution, take your time to look around. Above all; start by gathering your requirements. Without those, nobody will be able to implement exactly what you need.

Besides, does it really matter which tool you use?

OpenCms 7.0.5 - syntax highlighting

2008-07-30T10:57:00.007+02:00

I was amazed when I noticed that OpenCms added syntax highlighting to their editor. It may seem trivial, but it's a great help for us, template developers. Before, you might as well have been developing in notepad.
But now;

And that is something a lot of us have been waiting for in other wcm tools, like for instance Tridion and Interwoven SitePublisher.
Tridion now does have a Visual Studio integration, and the Interwoven story for TeamSite has always been that you can use any editor you like, although for SitePublisher components you're still bound to a textarea to edit the xml and xslt. Alfresco has more or less the same story; you'll be using Eclipse most likely. I'm not sure what Drupal has or suggests.
Even for OpenCms you can use an Eclipse integration, but it is still nice to have this in the web interface, even if it has it's limitations (no syntax completion for instance, that would have been too good to be true).

There are a few other improvements in the new version. Check out the release notes for details.

WCM Functionality

2008-07-29T13:55:00.008+02:00

What is the functionality that I look for in a web content management product? When I advise customers on which wcm tool would best fit their needs, those needs are of course the basis. And that's where the first effort goes to; determining why they need a tool to manage their websites. What do they have websites for in the first place?
Out of that investigation comes a list of things they need to be able to do or control. Next to that, there's also a list I keep of things I look for in such a tool.

What is needed before I call something a wcms?

1. First of all; a clear separation between content, presentation and business logic. You want authors to be able to manipulate content with some control over the presentation of it, but not too much. You certainly don't want them to have to bother about the header, site navigation and footer layout. Those things are for the graphical designers. They control the presentation part. As for the business logic; graphical designers are good at graphical design, you don't want to have to count on them to create robust and maintainable code. It's not that they couldn't do it, it's just not the thing they enjoy most. So for the business logic you need programmers (which in turn you don't want to have to rely on for a killer graphical design).
A clear separation between those three parts doesn't just look good on a powerpoint slide. You need it for the three very different profiles responsible for building your wcm implementation, and to keep it maintainable. If a programmer has to fumble around in the css to get something done, it'll get done, but it will come back at you before long. (I'm more the programmer type, I know what I'm talking about ;-)
Having control over presentation without impact of business logic or content, will also allow for smooth changes in the branding of your website. It the most ideal case, you will only need a designer to deliver a new css and images. And not also a programmer to reprogram the templates and an editor to fix the content to fit the new branding. A lot depends of the implementation, no matter which tool you choose. It's not always fair to blame the tool, although that is usually what happens after a bad implementation. So if a tool provides the possibilities to implement it the right way, make sure your implementation partner uses that possibility.

2. Ease of use for the editors (a.k.a. usability). In large organisations, and also in smaller ones sometimes. The time between one site update and the next for one person of one department can be long. Some editors only update the part they are responsible for once a month. To make sure they don't call the webmaster that one time each month, the system should be easy to use. It must be obvious what they need to do to update a certain part of the website.
Training can help, as a start, but you can't train everyone 12 time a year. A good manual will be very usefull. But if the system is complex to use, the manual will be too thick for that editor to find the page that tells him or her exactly what to do. They just won't bother (and quickly call the webmaster).

3. A wysiwyg editor. Yes, you want to limit the possibilities as much as possible; otherwise what was the point of seperating presentation from content. But the basic bold, italic, underline, links to other pages (internal or external) and especially a good table creator are a must for the editors. You don't have to take away everything. Most of it, however, can be solved by;

4. Structured content. Providing a structure, usually presented as a form to the editors, where they can easily enter their article title, introduction, banner, paragraphs, ... will make it a lot easier for them, and will help them work faster. The main advantage from a maintenance point of view is of course that you can control the look and feel of your site by setting the style for article titles in the css etc. Another great advantage is that you can pick out identified pieces of that content and display them elsewhere on the site in a different (but preferably related) context. For instance; title and introduction on the homepage, everything else on the detail page. Which brings us to;

5. Content reuse. Apart from the above, content reuse means to me that you have the possibility to reuse content on other sites in a completely different layout. Actually, if you think of it further, you also need a separation between the content and the site structure (the pages). You will probably not want to reuse all text on a particular page, but only part of it on another site. Or perhaps just the text for an rss feed.

And then there are a number of more technical features I look for;

6. Scalability is an important one. Perhaps you don't have the business case or the budget now for a clustered/load balanced environment with a webserver farm and a separate database cluster or whatever. Next year you might, and you want to make sure that you're not stuck on the one linux box with mod_security on the local apache server for the ever increasing load on the hardware.

7. Deployment possibilities kind of follow out of the previous. Some wcm tools have back and front-end (authoring side and web site) on the same software. This could mean that, if one of the editors is uploading a large pdf, your visitors meet with a very slow website. Having the option to publish your pages from an authoring environment to a website environment is very nice.
Another good reason to split those up is to optimize uptime; maintenance of the authoring environment shouldn't entail downtime of the website(s).

7. Open interfaces for integrations. There's a number of buzzwords here; Java content repositories, jsr 170, webservices, ...

8. Migration possibilities for your existing sites. As a first step you could have a system where you just import all the existing frontpage, ultraedit, notepad managed site on one common platform, and already start using the versioning and deployment functionalities of it. And then one by one migrating them to a templated/structured/content managed form on that same platform. A great way to sell the initial business case to you managers.

9. The dynamic aspect of the tool. How quickly does it adopt new hypes and technologies. Is it still the same plain page editor tool that it has been for years (ok, you could call that reliable) or did it have a blog module before the web 2.0 hype broke through? If I had a corporate website, I'd want it to be dynamic. Is that a task for the tool? Perhaps, perhaps not.

These are the main things I pay attention to. If you have other important aspects in mind, feel free to comment.

[update 2008/10/21]
Some links to articles related to this topic;

Technical Considerations for Choosing a CMS (Carol Skelly's WCM Journal)
Web Content Management (WCM) : Tips & Advice (Shane K Johnson)
How we work (3): selecting a CMS (Column Two)
WCM Best Practices: How Many Web Forms? (Jean Barmash)
The Content Building Blocks of Web Content Management (CMS Myth)
CMS Deployment Patterns (Enter Content Here)
Choosing the right CMS authoring tools (Step Two Designs)

LiveSite Controllers & Externals

2008-06-26T19:16:00.007+02:00

Since Interwoven's LiveSite 3 (or SitePublisher 3, depending on your religion), there is the cool new functionality that allows you to use "Controllers".
We already had what was called Externals, which are used to call java classes that return xml. This xml is then in turn passed to the component's xslt in order to do some transformations and produce html, usually.
This type of call to external java classes had the disadvantage that they were executed too late in the processing to influence the response stream. That meant, for instance, that you couldn't use those to redirect to a different page should you encounter a condition that required this.

Now with Controllers, you can. Depending on whatever condition you define, you can react on that by returning a different forward url. And, should you not forward, still call an external java object after that.

In the appearance xslt, is looks like this;

<Data>
<Controllers>
<Controller Name="ActionName">
<Object>com.your.name.space.Class</Object>
<Method>methodtocall</Method>
<Param Name="CaseAUrl"/>
<Param Name="CaseBUrl"/>
<Param Name="CaseCUrl"/>
</Controller>
</Controllers>
</Data>

The documentation is slightly incomplete, however. What it doesn't say, is that if you don't add an External element within the Data element, the controller code won't get called :-(
I Don't know why this is so, but it is. I added a dummy External to get around that.

So if you ever decide to use these Controllers, and you can't get it to work; check if you have an external there.

Vendor support

2008-06-17T22:17:00.007+02:00

Vendor support departments sometimes get me really nervous. One of the things I've learnt, is never to mention the word "custom" when you explain what your problem is with the software. I know that, still I made that mistake recently. The rest of my explanation was not heard anymore I'm affraid. I never got an answer back after mentioning "the word".

In a way I can understand their reaction; "They built something custom and it doesn't work. How are we supposed to fix that, and why should we?"
But the problem I sent to one such support desk recently, was about the extension interface, not the actual extension. And that is, in my opinion, a problem with the software. Or at the very least something not mentioned in the documentation.

I figured it out in the end and fixed it. Although it took me a while. Finally AC Doyle's "when you have excluded the impossible, whatever remains, however improbable, must be the truth" got me the breakthrough I needed. Changing something that had apparently nothing to do with it, but was the one last thing that was left, got it to work.

After a while, we just know the product better than the vendor's support personnel. I'm sure that if there would have been a notice about a bug in the api in their database, they would have pointed me to it and helped me out. I was just so lucky to be the first to bump into it I guess. (which makes me wonder what everybody else has been doing with those cool new features ;-)

When you log a ticket with support, it's usually as a last resort. But never stop looking for the solution yourself after that. In the end it's only 1's and 0's, so how hard can it be.

Tridion R 5.3

2008-03-31T18:15:00.002+02:00

I went to a "Pizza and Templating" session last friday, organised by Tridion for the more technical people. Finally we got a view on what the .Net part of R 5.3 actually entails and what we'll be able to do with the new Template Builder.

We'll be doing some research internally on these new features, and plan to organize a seminar on that sometime in may this year.

Stay tuned for details

LiveSite and HTML

2007-09-14T22:05:00.001+02:00

Interwoven SitePublisher/LiveSite, which recently released version 3.0 sp1, is a great tool to develop websites in. The end-users love it, it's easy to work with and develop in. And you can implement new functionalities for your websites very quickly.

It does, however, have some characteristics that require considering from the start. The most important one is the way LiveSite renders it's pages on the front-end.

1). Pages are created by placing components (in this context; pieces of content and/or functionality) on them. The pages themselves don't contain a higher level that you can control, apart from these components. A component could, for instance, be a header or the main navigation.
2). The pages, that are created in SitePublisher (LiveSite's back-end counterpart), are deployed to the front-end application servers as xml. These xml files contain the components and their absolute location on the page, and are then transformed, using xslt, to html.

Because of the way this is done, you don't fully control the actual generated html, which has it's consequences for the graphical design. More specifically, for the html code, css and javascript used. Some examples below. It's going to get a little technical, but that's the only way I can make my point;

HTML
The implementation of the graphical design should already take into account the bounderies of the components that will be placed on the pages. In other words; the parts of content that should be able to live independently of others on a page. In practice, these should be in separate divs, if you use div style layout.

CSS
You cannot apply any positioning on these divs, or apply styles depending on their context, if that context is outside one component. You can position pieces within components, but not relative to others, or absolute on the page. LiveSite takes care of that. The LiveSite runtime engine will actually surround each component with two additional div tags, which are used for positioning on the page. This also means that you should use classes to apply styles, and make sure that these are not hierarchical in the sense that they depend on styles applied to surrounding html elements outside the component.

Javascript
Using inline javascript is a bad idea. You'll be writing these out from a component, and any component can be on a page more than once and positioned anywhere within the site (unless you restrict this, but now we are drifting too far from the subject). You can use javascript, but you need to put the code in a js file and link it to the site.

A summary; it's not as straightforward as taking any html and transform it into a LiveSite template, as it might be for some other web content management tools. There are some technical peculiarities you need to look at before starting to generate html and css.
In my opinion, this is not negative. It forces developers to produce snippits of html that function well regardless of page context. That basically leads you to good html & css design.

ECM Summer Seminars

2007-08-13T12:44:00.001+02:00

Ines and I will be presenting some of our idea's about how web content management projects could, ideally, be handled. We'll be talking about how you can structure a WCM project to avoid many of the common pitfalls.

In a second part we clarify how you can nicely integrate your content with state-of-the art online applications in technologies like Flash, Flex and other web 2.0 applications. Having a content management system shouldn't, in our view, limit the boundless creativity you want to expose on your site.

You will get a practical demonstration of some of our points using Interwoven TeamSite and LiveSite.

If you're interested in attending and you can make it to Antwerp next Thursday (August 23rd), visit the Panoptic site where you can subscribe (it's for free, food included ;-)).

Customer centric websites

2007-06-05T23:18:00.001+02:00

So you convinced your corporate marketing department to create customer centric websites and structure your site based on task completion after attending a Gerry McGovern masterclass. Now what?

It's definitely not as easy as the guy makes it sound. But doable nonetheless, for most websites. Before doing anything, make sure that you are convinced that this is the way forward for your business, and you're not just jumping on the train because everyone else is (ok, not you, but there are some :-).

First you'll need to analyse and design how you want the "task", as Gerry puts it, completed. Build or implement the back-end applications that will support it. Then ponder on what visitors will want to see on your site (if you sell cars; take a wild guess). Map the task completion processes to the structure of your site (keeping in mind that this is not just the navigation tree), and fit in the content (preferably only the part that visitors will want to read, but this can be tricky) in there.
Now you have a perfect task completion based customer centric website no-one will find... Nope; you're not finished.

SEO!! Great.. It's worth wondering about wether you really need it. If you're BMW; everyone in germany looking for your site will find it without search engines, so why bother trying to get on page one? Especially if you'll only pay some guy a lot of money to help you with that, only to read in the papers that he did it so well google banned your site from the results.
I'm not a fan of SEO specialists, you may gather. Mostly because it's quite easy for a technical guy to get your html right for search engine indexing. And also because it's really not a one off job. The people managing the content side of your site need to be aware of what to do, and the content management system has to be built so that they can do it. No need for tricks to crank up the ranking, just get the right people involved from the beginning, and keep them involved as long as your site is online. Also don't forget the rest of marketing strategies. The internet may be the future, but getting your brand known may involve more than just a good website.

Once you jumped that hurdle, your brand is known, people find your site, they are happy to complete the tasks because they are in a website that is built for them.
At this stage; do not sit-back-relax-and-enjoy-the-ride. Make sure you stay on the great wave; keep your site up to date. Make sure the content is accurate, the layout up to standards, your brand consistent accross site/flyer/billboard..., update keywords based on trends to keep your ranking in search engines to page one if you ever got there... It's a never ending job. And that is one of the biggest mistakes I've seen happening at customers; the project is finished, they've got their website filled with lot's of good content, and then they move on to other challenges. Don't think it's over; it's only just started.

Tridion and .Net

2007-04-27T09:57:00.000+02:00

Apart from the SDL acquisition, there were some other interesting topics covered at the Tridion World conference last wednesday and thursday. The one I found most interesting was the sneak preview of R5.3.

Tridion seems to be moving in the right direction technologically;
* What they demo'd was the integration with MS Visual Studio; At last the templates can be developed in .Net and in a real IDE instead of a browser text field. They can even be debugged locally! If you've never worked with Tridion as a developer you're probably wondering what all the fuss is about, but this is actually a huge step forward.
* Another thing that a lot of us have been waiting for for a long time, is the ability to publish binary content in the folder of your choice, and not all in the same one. Digital assets all ended up in the same 'Images' folder before, resulting in one folder that could contain thousands of images and caused some hassle in certain situations. This will finally be taken care of in the new version.
* There will be some workflow enhancements, hopefully making that part ready for more than just the simple "yeah it looks ok, publish it" type of workflow.
* Tridion's side product ContentPorter, used mainly to move content and templates from one Tridion server to another, is said to have a new version underway with many many enhancements. They didn't demo that or detail the changes however, so we'll have to wait and see. But it all sounds very promising.

Tridion must have spent a fortune on research and development to get all those new features in. Perhaps that's why the acquisition by SDL suddenly looked like a great idea ;-)

SDL acquires Tridion

2007-04-26T17:07:00.000+02:00

On Tuesday the news arrived that Tridion (WCM product vendor) was bought by SDL (leading global translation software & services). Mergers and acquisitions have been around, especially in the CM software business, but these two companies are at first sight an odd combination. I participated in the TridionWorld 2007 conference on Wednesday and listened to both CEO's explaining why this acquisition is good news for everyone involved.

It sounds like they have their story together, but it is quite a unique combination of two companies with, admittedly somehow complementary solutions, but still quite different, especially in the way they approach their customers. The integration between the WCM and the SDL translation software is something many companies with global websites will welcome, but then again, lots of existing Tridion customers have already a custom developed integration with either SDL translation software or other. We'll have to wait and see how this evolves.

The press releases;
SDL
Tridion

So Why?

2007-03-21T20:46:00.000+01:00

Why would anyone want to spend a fortune on a commercial wcm tool if you can find free of charge open source software that has, at first glance, the same features? I get asked this question a lot, mainly by junior consultants that are stupefied when hearing the prices of commercial software license fees.

The answer, of course, is not that simple. Sometimes it depends on who went to play golf with whom and who let who win... but that type of arguments would side track us too much, and in all honesty; I don't think I'd really want to know.

An argument large enterprises have for investing in expensive commercial software, rather than in free open source software with the same functionality, is the question of support. Who will support the open source tool? The www developer community? Well yes, of course they will, but these large enterprises don't think these are trustworthy enough to provide long term support and besides, who will they blame if the software crashes? Try negiotiating a support contract with an "anonymous" mass...

Some smaller companies have been looking into open source for their website management. Even government departments in several european countries are using them. However, for larger and more high profile implementations, they too still go for the commercial ones.

Still, open source software is gaining market share, so they must be doing something right. Let's keep our eyes open.

What is it?

2007-03-01T10:20:00.001+01:00

So what is "web content management"? A way to manage your website's content I would say. You can do that in a myriad of ways, a lot of which would not be described as "managing" your site's content by most people in our line of work.

You could, for instance, have a folder on your hard disk where all the webpages are, which you edit with, say, frontpage, and then publish to your hosted site over ftp. And what would be wrong with that? Nothing, really, if it's your own personal website. But even then it's a lot easier to maintain it using one of the available online tools, like the one we use for this blog for instance.
If you're the one maintaining your company's website, well, you'll find out soon enough what's wrong with the content being on your desktop's harddrive when the marketing department suddenly decides the corporate site's layout should be "revamped" as they like to put it. Or the phonenumber mentioned in the footer on each page needs to be changed. I suppose you could get away with a "search & replace" tool for that one, but do you really want to rely on that?

When we talk about web content management, we think of certain tools that can help us with creation and update of our site's content, layout and perhaps even functionality. We may even consider reuse of either of these on a different part of the site, or on a totally different site. Having the same piece of text or image in a different layout and context on a separate site, but only having to make any changes to the content once in one place. And, even better; having someone else actully do it. The one that currently provides you with a word file regularly, containing the text of some webpage on your site, with the request to transform the word file to a webpage and put it on the site. Even the simplest and cheapest (meaning: free, open source) web content management tools available these days allow you to have people with no knowledge about html or markup, update the content of web pages, making your time available to spend on more challenging tasks.
The more expensive commercial wcm tools can, as one would expect, do a lot more. But we'll get to that later. Actually; some open source wcm tools do a lot more as well...