JavaScript editors are all fundamentally based on a technology called contentEditable which makes a part of the web page become editable by the user. While there is a lot of functionality that’s usually bundled under the “contentEditable” title, there are a few core parts which are essential for a browser to support correctly1:

• Selection – allowing the user to position a text caret in the content and select various parts of it.
• Content entry and deletion – allowing the user to type basic text and to delete selected content.

Without these two key components of contentEditable it’s impossible to create a high-quality, WYSIWYG editor with JavaScript. Despite some variations in how things work, this functionality is available on all common desktop browsers and has been for quite a few years.

The Problem

On mobile WebKit, for both iOS and Android, the basics of contentEditable support aren’t working correctly. The problem is two fold:

1. While the user can position a text caret and change the selection, the actual caret (the blinking vertical line), never renders so users don’t know where their typing will appear.
2. The on-screen keyboard doesn’t appear when the caret is placed in an editable section. On devices without a real keyboard it’s then impossible to type.

WebKit is actually surprisingly close to getting this working, with a lot of the underpinning functionality appearing to work but these two issues prevent editors from being usable2.

Why Does It Matter?

While geeks may feel at home writing HTML code by hand or using a markup language like markdown or textile, non-technical users find it significantly easier to use a WYSIWYG editor. Currently, it’s not possible to offer such an editor on mobile devices due to the lack of contentEditable support.

Even worse is that many sites are already using a WYSIWYG editor which then prevents users on a mobile devices from contributing content – even when the rest of the site works perfectly. With mobile browsers improving so rapidly, most sites now work without needing special adjustments so the lack of contentEditable support is one of the few major incompatibilities.

How Might it be Fixed?

To be honest, I don’t know and don’t have the experience with the code involved to find the source of the problem and fix it. However, with both the source to WebKit and Android being open, hopefully someone does have the experience knowledge and a bit of time to solve this.

With WebKit being the browser engine of choice on so many devices, the fix may even flow around to a bunch of mobile OS’s.

Relevant Bug Reports

Android

• 9515 – No onscreen keyboard when inside a contentEditable area
• 9513 – Unable to select text in contentEditable field
• 9512 – contentEditable field shows no caret
• For some background see also: 8253 – isContentEditable returns true even if the browser doesn’t really support it

iPhone

Apple don’t provide a public bug list, but this issue is logged as Radar #8399288. Apple do use the number of bug reports for an issue to adjust priority so if this issue is important to you, please do log an issue and cite Radar #8399288.

Others

I don’t currently have bug reports against other systems but would appreciate pointers to any relevant bugs for other systems (whether they use WebKit or not) so they can be tracked.

1 – The other major component is the execCommand function which provides built-in implementations of a number of common commands like bold, italic, etc. While it’s certainly useful to have these, they can generally be replaced by pure-JavaScript implementations without sacrificing quality or performance. ↩

2 – I’m unaware of any mobile browser that supports contentEditable well enough to make an editor feasible. In fact, WebKit appears to be the closest to that milestone. ↩

If you want to take advantage of the extra benefits of the Enterprise Edition (track changes, commenting, accessibility checking, image editing and more), you can install that as normal once the system is running. Currently Ephox doesn’t have per-hour pricing through Amazon but you can contact our sales team so they can discuss the options available.

1. When you click “Preview Website” you get an unable to connect message.
   • You need to start the virtualization server that provides the previews or configure it’s IP correctly.

2. When you click “Preview Website” you get a blank page and the browser is “connecting” forever.

   • You did the right thing and entered a root password other than ‘admin’ in the installer and now you’re being punished for it. Go and update the virtualization server configuration and give it the admin password you entered.
3. When you click “Preview Website” you get a response immediately that just reports “Virtual website not found”.
   • You started the virtualization server too soon after starting Alfresco. Restart it.
4. When you try to deploy the server it fails to connect.
   • You need to download and install the deployment server.
5. You’re trying to follow the getting started example, but when you get to creating content from the Press Release Form, it just gives you an error: Cannot resolve the name 'pr:company_footer_choices'.
   • You need to get the virtualization server working. Also make sure you have done the bulk import step and can preview the site.

Starting the Virtualization Server

There should be a ‘virtual_alf.sh’2 script in the Alfresco install directory. Run ‘./virtual_alf.sh start’ There’s also a virtual_start.sh but you’ll probably need to edit it to replace the @@ALF_DIRECTORY@@ placeholder that the installer didn’t replace.

Setting the Admin Password

At the end of the file ‘virtual-tomcat/conf/alfresco-virtserver.properties’ within your Alfresco install directory, there’s a property ‘alfresco.server.password’ this needs to be set to the admin password for your Alfresco instance. Keep this in sync anytime you change the admin password or your site previews will stop working.

Also note that the user/password you add here will be used for all previews so it bypasses any security you might have. Don’t deploy this on a publicly available site unless you have nothing to hide.

Installing the Deployment Server

No, it doesn’t seem to come with Alfresco by default – the documentation suggests there’s a way to enable it but I haven’t found it. Much easier to just download the component separately (from the main download page, go to “Custom Installs”, look under the WCM section and pick the obviously named package that works best for your platform. Install it by unzip/untarring in a directory and run it with the deploy_start.sh script.

There is configuration in the ‘deployment.properties’ file which most importantly controls where it deploys to. You probably want to deploy to a Tomcat server’s webapps directory or similar. The default config will however work for testing and put the deployed content into the ‘target’ directory.

Why Isn’t This in the Install Guide?

I have no idea. It would seem like something you would want to know about while installing.

1 – probably all of them actually↩

2 – .bat on Windows ↩

The issue at hand is not whether governments should pick HTML or PDF. The issue at hand is whether governments are capable of publishing information at all. Show me an HTML creation tool that creates high quality, standards conformant markup from a Word document or any of the zillions of editing tools that government employees use. Now add in all the tools used by people who submit documents to the government. And all the versions of those tools released in the last 20 years. Now make sure that the HTML/XML works correctly even when the user doesn’t have the right browser or the right fonts installed.

I’ve actually worked with a number of government departments who were looking to move more content online and the content conversion problem is definitely a time consuming and challenging part of the problem. That’s precisely why I wind up getting involved, since EditLive! lets you easily copy and paste content from Word documents and produce clean, compliant XHTML. It can even (optionally) strip out inline formatting and leave just the structure like headings, tables and lists.

Furthermore, EditLive! is actually quite good at making sure the HTML works correctly even when the user doesn’t have the right browser or the right fonts installed, especially when it’s been configured to suit the particular content needs. Even with non-technical business authors this can work very well and is doing so for a significant number of government departments.

That’s not to say it’s the whole solution, there are systems out there where it’s hard to convert the content to HTML and where HTML may not be the best format anyway. Some of those cases may work better with PDF but certainly not all of them. To somehow suggest that PDF is a complete and simple solution to publishing information on the web misses quite a lot of the picture. For example:

• How do web site visitors navigate around and get to that PDF data? How do they search and find it? As much time is spent working out navigation structures as it is converting content.
• How do you expose information from databases with regularly changing information? Wouldn’t a HTML representation be easier to generate than PDF in most of these cases?

Putting information on the web is not simple and no single technology is going to make it simple. PDF definitely has it’s place on the web, but so does HTML and a number of other formats. PDF doesn’t alleviate compatibility concerns, not all users have a recent enough PDF reader, not all PDF embed all the fonts and when they do it makes the download very large etc and not all PDFs are standards compliant. Putting non-web stuff on the web is always a big, challenging project, so review the available technologies carefully and pick the ones that best achieve your goals. Very few companies have success with just dumping a whole heap of PDFs on a web server.

The URL winds up looking like:

http://iweb2.ephox.com:10040/wps/myportal/wcmAuthoring?wcmAuthoringAction=new&
type=com.ibm.workplace.wcm.api.WCM_Content&atid=com.ibm.workplace.wcm.api.WCM_AuthoringTemplate/simple-page/389d16004d3954ac9b4eff0a98a2531c/PUBLISHED&
pid=com.ibm.workplace.wcm.api.WCM_SiteArea/plugins/ca0d04004e034ec59853f8b5e96d1024/PUBLISHED

I’ve verified that the ID for the authoring template is correct by using it in an ‘edit’ action and the authoring template opens in edit mode correctly.

If anyone knows why this is suddenly going wrong I’d love to hear it.

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.

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.

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.

 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.

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.