Symphonious

Jeff Atwood chimes in on the age old question of HTML vs Markdown/Textile/Custom Markup/etc. Unfortunately he rules out using a WYSIWYG editor with the one line statement:

Nothing's decided at this point, but we definitely won't be giving users one of those friendly-but-irritating HTML GUI browser layout controls.

Well sure, you wouldn’t give them a friendly-but-irritating HTML GUI browser control, but why not give them a good one? These days it takes a fair bit of effort to find a HTML editor that doesn’t handle the very basics fairly well and Jeff doesn’t seem to be looking at anything more complex than bold, italic and some hyperlinks. I think a lot of people get stuck in a real geek ego thing or remember the really early days of HTML editors and don’t actually evaluate modern editors properly and it’s a real shame.

All these simplified markup languages just don’t make sense to me, why make people learn something new just for some really basic formatting? Is it really that important to have the formatting capability at all?

My view is that you either need good, full featured formatting that a high quality HTML editor would provide, or you really want plain text. Hyperlinks can be added automatically to URLs easily enough which is the main thing you need and if focussing on the content is really what matters you don’t need any formatting markup at all.

Of course, I’ve seen things this way for ages (1, 2).

CMSWire: Vendor Criticism of CMS Watch

In an industry whereby most of the "independent analysts" are heavily dependent on revenues from the very firms they claim to be "independent" of, it's unusual to see truly critical research get published. So it becomes a surprise to both buyers and sellers when they read such criticism. In our reports we widely distribute the compliments and brickbats — if something is truly terrible we will tell you.

The way I see it, criticism is one of the most important things a product company can receive - particularly in an aggregated, general form like an analyst report tends to give you. It lets you identify areas you need to improve in that are actually affecting clients rather than the ones that seem important to you.

The first thing I do when I get a new vendor report is to search through it for any mentions of Ephox (it’s amazing how often we turn up in reports about web content management systems) and see what they didn’t like so we can work out how to fix it. Then I go through and find the general trends in the report etc to establish a wider industry direction and market opportunities etc.

Technology is a funny thing - we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other's to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

• They have the power and ability to implement their own code. To build on things and improve them.
• They are probably using your product to save time so the less they have to do the better (ie: we have to make things simple and efficient for our developer users and our end users)
• Since they are trying to save time, they will probably learn the minimum amount possible about your product and do the minimum amount of work.

Not everyone integrator has all three of those attributes - certainly we have a lot of clients that know our APIs backwards and build all kinds of cool stuff, bu the majority are pressed for time and wanting to drop your solution in and move on.

The trouble is, sometimes a simple drop in solution simply can't provide the high standard of end user experience that you'd want. In other words, sometimes you get a trade off between making it really simple for the integrator or really good for the end user. As an example, EditLive! introduced "inline editing" recently which allows the page to load really quickly and display the content in a standard DIV. When the user clicks on the DIV the editor loads there and they can begin editing. Click a different DIV and the editor switches over to there. It turns out to be a really good user experience with just one flaw: how does the user know that they should click to edit and where to do so?

The best possible answer in this case is that the integrator takes a bit of time to fit the functionality into their UI and make it intuitive for users. Depending on the environment the editable section is in changes the way you should indicate the editable section. For example, if the entire page is a form specifically designed for editing, the simplest way to make the user see that the DIV is editable is to apply a border that makes it look like a text area. Users expect to be able to click in a text area and start editing so it becomes a natural reaction. Sometimes you want in context editing so the page should look as much like the final output as possible - perhaps just a tooltip on the DIV is the right answer or maybe a specific cursor (probably combined with some user training since this isn't as natural). Whatever UI is in place it should also fit in with the rest of the site and only the integrator can do that.

Unfortunately, I went off and got married and when I came back they'd shoved a hideous pencil into the product to indicate where user's can click. So when the user hovers over an editable section it gets a blue border and a hideous yellow pencil floats over the content. It has to be the single most jarring part of the user experience anywhere in our products - particularly when blue and yellow aren't part of your site's color scheme. Now I can understand the logic behind adding it, the alternative was to have no visual indication to the user at all which is clearly even worse. We wanted to make it easy for integrators to use the functionality and not force them to implement their own way of indicating editability. There's a problem though - now we've taken ownership of that indicator, if it looks ugly it's our fault or if it isn't intuitive enough, it's our fault. There's very little we can do about it though, the only person who can create the right UI for this is the person who's laid out the rest of the editing page and knows the color scheme and knows how to fit the right UI in (including just writing Click To Edit under the DIV). The integrator is busy though, so they see a UI in place, however terrible it must be, and just go with it. We've managed to make the UI "good enough" for the integrator to ignore, but still terrible for end users. If we'd done nothing the integrator would have felt compelled to do it themselves and would most likely have created a much better UI for their users.

On the plus side, we did add an option to turn off our default rendering so that you can do what's best for your own users. Just call editlive.disableObviousEditableSections(); There's a good example over on LiveWorks!

Bottom line: sometimes you need to be cruel to be kind - if you can't do the job right, make sure you do it badly enough that others will feel compelled to act. Avoid the zone of mediocrity.

PS: I really miss Kathy Sierra's blogging.

 My open tabs in NetNewsWire have exploded in the last couple of days with really good articles about driving wiki adoption and generally making wiki's work. First up Making Wikis Work is a pretty good overview of all that is wrong with wikis. It's odd to think that a technology as young as wikis has legacy cruft but they do.

In particular, WikiWords are no longer required or a good idea, use an editor that makes creating links easy or use a simple shortcut for creating links (the square bracket notation was easy for most people to learn, but you need to provide a completely GUI alternative as well).

Wiki syntax is the other big bit of legacy cruft - it's probably the biggest barrier to wiki adoption now and wiki creators are all scrambling to add WYSIWYG editors instead but many are struggling to make it all work because wiki markup is so non-standard. Should have used HTML instead…

There's some good suggestions in there for how to create a good wiki too. Not too sure that everyone would agree that hierarchy is the best way to organize things, but you certainly need to include good organization tools which most wikis lack.

Next up, Steward Mader nails one of the big problems with getting people to try out wikis - fear. It's natural for people to fear new things and to fear criticism or looking stupid. Wiki's have always tried to reduce barriers to entry for contributing but they still struggle with people's fear of looking stupid. I think Stewart is too dismissive of this - we've got to find something that makes people feel safe while they get started and build up their confidence. It's social not technical though so the solution isn't going to be simple.

Nat Torkington talks about O'Reilly's problem with ever growing mailing lists - Ephox has the same problem in both directions, extra people and extra content constantly being added to mailing lists. Our engineering alias has grown to include half the company so noone uses it anymore, they just type in all the actual engineers directly. Wikis are often a great solution to this if you can get people to use them - instead of pushing every message out to everyone you let people self organize around the conversations that interest them. Of course, you have to get people to actually use the wiki and pay attention to what's going on there and it doesn't resolve O'Reilly's problems with NDAs etc. It does create a much more useful archive of information if the conversations are actually creating information (rather than just discussing and inspiring ideas). Probably not the solution for O'Reilly but wikis certainly can reduce the email load in a company and allow people to be more productive and actually get the information they need. Email tends to include a lot of people that don't need to be involved and miss a lot that do, plus anyone who needs to know later has to start the discussion all over again.

Rahul complains about Google Docs rather primitive diffing capabilities. Being able to see what's changed is another of the really obvious features that is rarely done well. Our internal wiki has some pretty awesome diff capabilities now but it still needs more work as quite a few types of changes confuse it. I'll have to investigate how track changes could be used to improve it.

HiveTalk discusses how to hold meetings on a wiki. Good advice here but I'm hesitant to call it a meeting, mostly because noone likes meetings. I'd just call it a discussion. The idea of having a deadline is really important as is following up on actionable items. Of course because this is asynchronous people who don't have good time management skills (most people) will tend to put it off in favor of doing something that feels more urgent so you need to be cautious of that and pester people if you really need their contributions. Often the best way to teach people to get involved is to go ahead and make decisions without them (doing the best you can) and let them live with it - depends how important the decisions and the person involved are as to whether you can get away with this though. Probably best to start with something like where the company picnic will be instead of business critical decisions.

Lots of good stuff in there - hopefully I'll get a chance to look at them in some more depth because there's a lot of overlap with the stuff I'm thinking about at the moment.

There's a constant argument over whether data should be structured or unstructured in content management and knowledge management systems. The key advantage of structured data is that it's easier to process and manage - the system can manipulate and report on the data far more accurately. The downside is that it's more difficult and frustrating for users to be limited to the specified structure so less data tends to get captured and it can be more difficult to get adoption.

So how do you get the best of both worlds? There's been a number of approaches taken from Google refining search techniques for unstructured data and a number of other systems attempting to parse natural language to identify dates, appointments and other items. Meanwhile the structured crowd invest in ways to improve user interfaces and define more flexible types of structures.

I think the middle ground looks something like microformats, little bits of structure within a generally unstructured system. The downfall of microformats is that they tend to be way too complex to apply but the concept is sound. There needs to be a focus on making it easy and natural for users to create the right structure. With tool support and appropriate feedback to users the experience can be really smooth while still capturing the vital information. We've been playing around with ways to make creating links in our internal wiki easier and I think it's a reasonably good start towards finding the magical balance. The wiki uses HTML and a WYSIWYG editor to avoid users having to think about markup but having to open up the hyperlink dialog just to link to another page gets in the way on a wiki, so we've preserved the ability to use wiki markup and put the page name in square brackets. This is good, but looks ugly and doesn't provide feedback on whether or not the user got the pattern right.

The second iteration added a plugin to the editor that automatically identified correctly formatted wiki links and converted them to real hyperlinks, so when the user hits ']', the link switches over giving them clear indication that they got the pattern right and showing them the results. The main problem at the moment is that if they enter a valid pattern that doesn't do what they want (say they get the display text and the link target mixed up), it's not simple enough to correct the mistake because what they've typed has now completely changed. Undo works but the backspace key doesn't yet and it probably should. We also need to identify what happens when they edit the text of the link after it has been converted - in many cases they intend the link target to change as well, but not always.

You can imagine this kind of system being extended to task lists and appointments as well - when the system recognizes a date it should mark it appropriate so the user can tell they got the format right and what the results are. For somethings it may be better to use a standard convention like the square brackets - for instance, tasks to be completed might start with an exclamation mark. Simple to type and if appropriate feedback is given simple to use.

The key element is providing clear feedback right inline with the text. Most of the existing systems I've seen provide a plain text area and build up a list of things it recognized over to the side. The problem is that the user is focussing on the text they're writing and not on the list of items the system is building up so they have to keep stopping and looking over to check that it all worked correctly.

There's a lot of really cool stuff to come out of this area in the future and we're seeing the start of it in existing systems but I suspect there's a whole new level to be reached as systems begin to act more and more as intelligent agents that assist the user in getting their work done. The next major challenge that I see is to get the feedback system right so it is clear but not intrusive.