Note to self:

That magical file that controls just about everything you ever want to control about IBM LWCM (at least so far as things that are controlled from the file system rather than the web interface) is under the profile directory at /wcm/shared/app/config/wcmservices/WCMConfigService.properties

This includes:

• configuring backwards compatibility for WCM 6.0 -> 6.1 migrations. Primarily the don’t expire content immediately when no expire date is set.
• setting up the SMTP server properties so you can get e-mail notifications in workflow
  • Side note: These get annoying really quickly if you’re not careful.
• A bunch of stuff on caching that looks cool. I wonder what the changes I just made will do…

Also, why did it take me this long to add fancy list bullet styles to my blog stylesheet? Mixing the blue and green is probably a bit much – I should create a blue tick or green arrow, but oh well, I’m drunk with power.

The Australian brings news of the growing battle for mobile banking leadership among Australian banks:

Brisbane-based Suncorp launched the first mobile browser-based banking service and last week made it compatible with iPhone and Google Android handsets.

The Commonwealth Bank has similarly updated its mobile service, which will work on any internet-enabled mobile phone, and has additional functionality for the iPhone.

People have been talking about the coming mobile revolution for a long time. In fact, as the article mentions, the Commonwealth Bank had previously tried to jump on the mobile banking wagon as early as 1999 via a WAP interface. So what’s changed and what does this have to do with accessibility?

1. The capabilities and affordability of mobile phones with Internet access has dramatically improved. Firstly with the iPhone and now a top-notch browser is a must have feature in a smart phone.
2. WAP is out, users want the real web. It’s not ok to provide a text only WAP interface that works on phones, users want the full functionality and they want it to look pretty too. Modern phones support HTML, CSS and JavaScript and most of the time you should be writing just one site that works everywhere rather than a separate mobile site.

It’s that second point that really brings accessibility in. If you design your site so that it can be used with a range of disabilities, there’s a much better chance that it will also work on devices with a range of capabilities. In other words, someone using an iPhone to view the site is just a user with a particular type of disability.

• They have a small screen so the site needs to scale properly (use relative units, not absolute). If your site can handle users changing the size of the font, it can probably scale pretty well to fit on an iPhone.
• If the networks slow, they may not be able to see images. If you have good alt tags, they won’t need to.
• They can’t see flash. While you can design accessible flash, most people don’t so surfing without flash is often very similar to what a screen reader would see (at least for the flash side of things).
• They can’t use a keyboard very fast and can’t drag and drop anything.

There’s also plenty of unique things about various disabilities and the iPhone as well as different limitations on different handsets, but there’s also a lot of overlap.

Accessibility isn’t a cost centre – it’s a competitive advantage.

Pangle on Twitter:

Ephox EditLive Editor will change the world. Well maybe not the world, but it will make WCM content easier to format.

I couldn’t agree more. This is of course in response to the news coming out of Lotusphere that IBM has licensed EditLive! as a standard part of their WCM offering. Ephox has been an IBM business partner for quite a few years now and has built up a lot of relationships with their technical and sales teams as well as selling EditLive! as a third party add-on to a lot of WCM clients. It’s very exciting to see this go up a step and have EditLive! as a standard part of the offering. I don’t have an exact ship date for the OEM version yet, but my understanding is that it will come as an update to Portal 6.1.

So to all the new Ephox clients who are being introduced to EditLive! as part of this agreement – welcome. I really look forward to working with IBM to get you up and running with EditLive! and seeing what it can do to improve you WCM authoring environments and resulting content. I’ve spent the last week putting together a white paper to share the experience we’ve had upgrading WCM deployments to EditLive! and a bunch of best practices for configuring EditLive! to get the most out of it.

To all our existing clients, thanks for all your support so far and  we look forward to continuing to work with you. The OEM agreement includes just the base edition of EditLive! so we’ll continue to ship the Enterprise Edition as an add-on, with some big improvements planned for both it and the base edition.  This isn’t an official source of Ephox news and I want to avoid getting any details wrong so I’ll refrain from giving details, but rest assured that everyone at Ephox is committed to making sure that we keep making all our clients happy – especially those who have supported us in the past.  If you have questions, we’ve got a page giving some information on the OEM agreement and please do contact us if you have any further questions or concerns. The white paper is probably useful for you as well.

To everyone within Ephox, congratulations on making such a fantastic editor, from engineering and product management making sure the product is great, to sales and marketing getting the word out and making enough sales to keep us in business and the admin team for letting everyone else focus on their jobs.

Now let’s get back to work and keep changing the world.

One of the popular geek pissing contests is comparing how far back your email archives go. It’s a game I’ve enjoyed playing in the past and quite regularly one given that I’d never deleted an email (ahh the days before spam…). Still, as Andy has just discovered, it’s not always as useful as it first seems:

 I have to say though I’m not sure keeping all of this email was the best idea. I’ve glanced at a few old emails while sorting this evening and… well put it this way, would you want a detailed account of your uni years?

If your email is just building up without requiring any effort on your part then there’s no real advantage to deleting it and it may as well sit there. Once you come to expend time and effort migrating that email though it just becomes a waste of your time. The trouble is, now that you’ve got all that email, you’ve got no idea which bits are important to keep and which aren’t. You’re stuck on the treadmill of migrations until it eventually gets so time consuming that you figure it’s easier to just dump everything and start again.

On the other hand, if you only keep emails that are worth keeping from the outset, you have a much simpler migration path when you change systems and if you do want to cull anything that was once useful but now isn’t, it’s a much smaller set of emails to sort through. I switched to this system a few years back and am very happy with it. I still have too much stuff in my “Other” folder which tends to hold all the web receipts and things like that which are critical to keep until a certain point and then become useless. It’s not really worth setting up a system to make them easier to manage though so I’m just leaving the folder to grow – it’s still a far more manageable mess than if I saved every email.

Of course, this isn’t just limited to email – anywhere you store content is susceptible to this kind of problem. As you get more and more content in the system, migrating to a better system becomes harder and harder, but more importantly, it gets harder and harder to find the actual information you want. Even with fantastic search and incredibly detailed categorization, there’s only so far any information architecture will get you and keeping that information architecture running requires more and more effort as you get more and more documents.

So deleting outdated content and any other content that’s no longer useful from your system is incredibly important.  Just as programmers should remove unused code from their programs, content management users and administrators should remove unused content from their repositories. Remember, it’s about quality, not quantity – a small set of really useful content is far better than a massive repository of everything the company ever created but that nothing can be found in.

Remember, the challenge of information technology isn’t in storing stuff, it’s in storing only the good stuff.

Update: See, what did I tell you – Rich Bowen: What we've been saying for *years*

What seems to be missing from this story is the time component. That is, if they don't do it now, they will have to do it later, and the longer they wait, the more it will cost. Every new record adds costs to the total, and that cost will be paid by the entire health-care-consuming public.

Believe it or not, it’s been almost exactly 2 years since I kicked off LiveWorks! as essentially a skunk-works project to get some of our internal experiments out into the open so they proved useful. As it turns out the bigger success has been the weekly hints and tips that we started adding a few months later. Unless one of the migrations has messed up the dates, the first tip was a simple overview of how to integrate EditLive! that Rob wrote. I still regularly refer people to that article.  Since then we’ve posted a new article every single week without fail.

The net result is that we have a huge collection of knowledge that’s built up, from common tasks to quite specific ways to customize and extend EditLive! It’s actually quite rare for me to resolve a support case without linking to a LiveWorks! article at least once. With the recent addition of a few video demos as well I’m finding it more and more common to put together a customized package of LiveWorks! links for new prospects as well.

What’s particularly amazing about this is that I refer people to the LiveWorks! articles far more often than I point them at our official documentation. We’ve been talking about reworking our official documentation for at least as long as LiveWorks! has been around but it always seems like such a huge project so we never do it.  This leads me to the secret of improving documentation: set up a regular schedule for making improvements and stick to it.  Whether you write a new article a week, review an existing article a week or add 3 good “See also” links each week you’ll wind up improving your documentation faster than if you constantly try to find time to fix it all at once.

The draw back is that it’s very hard to improve the discoverability of information gradually like this. LiveWorks! really needs a knowledge management expert to come in and make it easier to find what you want – I happen to have a pretty good memory for what’s there and know what to look for, but most people would find it far less useful.