I started playing with AJAX before it got its silly name and true to X I used XML in my application. At least at first.

What I discovered is that flicker caused by processing data and simultaneously writing results to document can be completely removed if I do a Google and fetch javascript object instead (what later became JSON ) and use that. Difference was so vivid, I dropped XML almost completely.

Fast forward to autumn. There’s a debate after our regular weekly talk and a question comes up. Why would Google or anyone else for that matter choose to use something else than XML?

Relying on personal experience I offered speed as obvious and most important reason. I couldn’t back it up, but since I’ve seen it with my own eyes, I didn’t doubt it either. It wasn’t the sole reason. I find dabbling with javascript objects simply easier than handling XML and I’ll care about XSLT when javascript in Safari can access it.

I got reminded of our discussion when I read this article . Read it, if you haven’t yet, because it’s well worth it. Anyhow, I decided to make a new test. I wrote a simple test page , that fetches sample json file and basically equal xml sample and measures how much time it takes to fetch same data.

Result?

After 15 minutes of wild reloading in different browsers (Safari 1.3+, FF1.0, IE6) and different local and non-local servers, I can’t see a difference that couldn’t be attributed to latency. It seems browsers have moved on and there’s little reason to avoid using XML today.

So use whatever you like most.

Jensen Harris posted an interesting observation few days ago regarding “help” in programs. Microsoft’s usability tests showed that help is mainly used by experts and enthusiasts.

I don’t have data to back or refute his observations, but I did check our logs to see how often is our help accessed and the number is so low that I’ve seem to have talked about it with practically everyone who actually visited it. Sure enough, all of them belong to more experienced users who probably need it the least ¹ .

So let’s assume that Harris is correct and inexperienced users don’t access help. I think there are three basic questions you’re faced with when designing a help system ² :

1. How do you get users to discover and use help?
2. How do you meet the needs of those who do?
3. What about the rest?

Harris’ observation doesn’t change questions, but it does lead to possibly different answers.

1. How do you get users to discover and use help?

The least you can do is to make it accessible from a standard place, which is in the top right corner and to make it easily recognizable. If everyone says it’s Help, you should too and don’t hide it with small font size (we might be guilty of this) or inappropriate colors.

We tried to go further than this by also offering various means of help in close proximity to where we think our members might appreciate it. It’s still too early for any conclusive remarks, but compared to general use of our help, I’d say it’s showing good promise.

2. How do you meet the needs of those who do?

If Harris is right and I believe he probably is, then this translates to what are the needs of experienced users and how to meet them?

What we have so far is simply a FAQ of real questions that have been asked previously. It’s amazing how many companies think FAQ is a place where they should put questions they’d like users to ask.

It’s not much and certainly not enough, but there’s been little need for more so far. What I’d like to add is tips and other ways to deepen the knowledge of those, who’d like to do so, but so far we’ve lacked the time.

I’ve certainly discovered that absence of tutorials teaching basic use of our service is not a problem. At least not so far.

3. What about the rest?

No matter how hard you work to make your product simple to use and how easy it is to get to help for it, there will be people who won’t know how to use it and either can’t or won’t use help. How do you help them?

One way is to make mistakes really cheap. Everything that delays a successful completion of intended task is a burden, a price payed not in money, but in satisfaction. We’re trying really hard to make it as cheap as possible with lightning fast pages and non-destructive interfaces where it’s easy to fix mistakes.

I think it’s already clear that this approach works very well. I believe it’s partially responsible why our help section is rarely used.

There are options like tooltips, that we haven’t used yet. There are probably options we haven’t thought of. We’ll try new stuff and when we do, I’ll let you know what we’ve learned.

Notes:

1. Before I go on I should point out that it would be nice to think that we got our interface right and most people don’t need to visit our help section. However, without data to back that up it could also mean help is just too difficult to find. It’s something we’ll have to investigate. ↑
2. I assume that all conscientious designers strive for a design that would remove the need for help. I also recognize that this is often not possible. ↑

Learning to read was really a big deal for me. One of the things I discovered was that people have a great difficulty writing my name correctly. I’ve experienced it so many times by now that I find it neither surprising nor annoying.

This week was a bit special with higher frequency of errors than usual on account of my talk. First I became Marko Semastur. Then a day or so later Makro Samastur was in vogue, which it’ll remain to be until the subtitles on footage are changed. I find the tech pimp connotation of Makro highly amusing, but not quite a T-shirt material.

I was talking to a friend yesterday who’d like to put up a website displaying his work and sadly discovered that domain with his name is already taken. I suggested a use of simple to remember name, but I can’t say I persuaded even myself.

What I’d like to know is how important do you think is your name or the name you choose for a company for your recognition and success?

I’ve been going back and forth over this and I can’t say I’m any wiser.