Alex Bosworth wrote a great post about when to use AJAX and when not to.
Alex Bosworth wrote a great post about when to use AJAX and when not to.
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 1 .
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 2 :
Harris’ observation doesn’t change questions, but it does lead to possibly different answers.
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.
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.
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: