Help Is For Experts

November 30th, 2005

Jensen Harris: Help Is For Experts

One of the most interesting epiphanies I've had over the last few years seems on the surface like a paradox: "help" in Office is mostly used by experts and enthusiasts.

How can this be? I think my biased assumption was that experts know how to use the software already and eager novices would be poring over the documentation trying to learn how to be more effective using it.

Definitely an article worth reading. My experience has been that expert users don't use help because they assume it will be useless - usually because it is. Quite possibly it's useless because it's incorrectly targeted at beginners.

Making Wikis Work

November 29th, 2005

Jonathan Boutelle talks about how he made a wiki work with his software developers:

  • Start off maintaining existing documents
  • Make it easy to login
  • Insist on Wysiwyg

So, so true. The first two could be a little more generalized: Start with a reason to use the wiki and make it easy. Making it easy encompasses insisting on Wysiwyg but the editor is the most important touch-point of a wiki that it's worth stating separately.

I've previously commented on this kind of thing before, so it's good to see others learning the same lessons. Of course, I'd suggest using a really good editor like EditLive! for Java, but I am somewhat biased…

On Standardizing Office XML

November 28th, 2005

Interesting argument between Tim Bray and Robert Scoble about what benefit standardizing Office 12's XML format will provide.  Tim Bray suggests that Microsoft should use the open document format as the basis for its XML format with custom extensions when required.  Scoble argues that documents are more complex than Tim believes and that it would be impossible to create a compatible version of Office around the open document format. Maybe Tim Bray has done a lot of work with Word documents and office documents in general that I'm not familiar with - I know he's done a lot with XML but that's not enough to comment on the needs of a office-style document format1.

Frankly, I'm not entirely sure that either of them are particularly well qualified to comment - an accusation not often leveled at Tim Bray and far too commonly leveled at Scoble (usually unfairly). For the record, I'm not particularly well qualified to comment either considering I haven't looked at either specification. Having said that I have spent the last five years or so creating a HTML editor that should feel familiar to Word users, including the ability to import content from Word.

With that in mind, I'd say they are both potentially right. The vast majority of documents people produce are really quite basic. A bunch paragraphs and headings, maybe some lists and potentially a table. The advanced users create an automatic table of contents and play around with borders and shading. The really advanced people get into complex tables, columns and indexes. So Tim is right, the vast majority of documents out there are really, really simple and could easily use pretty much any half-baked language for documents.

On the other hand, with the vast number of Word documents out there, even though only a very tiny percentage use more complex features, that's an awful lot of Word documents, so supporting every last feature down to the tiniest little detail is important to Microsoft. Considering how difficult the task of backwards compatibility is, Microsoft has done a surprisingly good job with it (the lack of forward compatibility is what they use to force people to upgrade so they can read documents that are sent to them).

So, is it possible to just add extensions to the open document format to support the extra Word features? Probably. Would it be simple? Heck no. The trouble with converting to a different format that uses a different model for the text is that inevitably you come across some document model property that shows through to the user which is different between the models. Trying to convert Word's model for styles to CSS is one such problem. CSS has a completely different concept of inheritance to Word so to create something that is familiar to end users, you spend a lot of time coming up with ways to make the new model appear just like the old model. What makes it really difficult is when you then have to support a document that was created based around the new document model and does things that simply aren't possible in the old model. You've got to find a user interface and series of editing operations that melds the two differences.

The other problem you run into is how to test every possible document that could be made. We have a ton of code for handling special cases of Word documents and yet we still keep finding documents that present new corner cases. There's a difference between identical looking documents that were created in Word originally, compared with documents that were copied and pasted into Word from a web page, compared with documents that were copied from Outlook and so. The number of possible variations is staggering and impossible for any QA department to identify them all.

All up, my suggestion for finding out if it's possible or not is find someone who is familiar with the old Word document format (an Open Office developer perhaps), that is also familiar with the Open Document Format and is familiar with the new Office 12 XML format. You need to be very, very familiar with all three to be able to accurately gauge how possible and how expensive it would be for Microsoft to base its file format off of the open document format. Anyone who isn't in that position most likely doesn't have any idea what it would take to use Open Document Format in Word, including me.

[1] Docbook and most XML document formats do not in any way, shape or form count as an Office-style document. Office-style documents are mostly focussed on formatting and not so much on content. Most XML based formats are the opposite of that.

Swing Text Survey

November 28th, 2005

Though everyone should already know about this, there is a survey out on what features to add to Swing's text packages for Java 7. While that's still a fair time away, and a long, long time away before you can count on everyone having it, now is definitely the time to make yourself heard about what features are required if you want to get them in.

Most of what's on the list is possible to do today but takes a heck of a lot of effort to achieve, as well as a lot of very specialist knowledge. Making it easier would be a pretty big plus.

Scripting Framework For Java 1.5?

November 16th, 2005

Dear lazyweb,

Do you happen to know if the scripting engine stuff that will be part of Java 1.6 is available for previous versions anywhere? I know there's things like bean scripting framework, rhino etc but would like to use the one standardized API to drive things if possible. I haven't seen much information come through about the scripting APIs which is a bit surprising actually.

Thanks!