I assume it's not a reference to responsive ("self-resizing") HTML, but rather things like user input lag (a common problem in apps.) Better to have a zero-lag async calculation than a nominally faster but UI-blocking synchronous calculation or request.

I think it's actually meant to encourage putting up things like spinners, page transitions, etc. Make the user feel that something is happening, and they won't feel slowed down.

But that doesn't mean it is better than fast. I would say "if not fast, be responsive"

I think the message is this: fast is an impossible standard to meet since there will always be inconsistent user experiences, so aim to be responsive before being fast.

I agree with it very much. When I'm zipping files on Linux and my system grinds to a halt due to hard drive contention, I don't want faster zip times, I just want the damn thing to be responsive while it zips in the background.

If you're running zip from the command line, try setting the priority with 'nice' when you run it. That should allow you to continue using your system while zip crunches away in the background. If you forget to set the priority level at runtime, use 'renice' to set the priority level of a running process.

ionice[1] is even better for this use-case.

  [1]: http://manpages.ubuntu.com/manpages/raring/man1/ionice.1.html

Not that there is any right answer here (that's the whole point), but my interpretation is less a technical one than the ones suggested so far.

Being fast gets you to far away places, but being responsive gets you places where you want to be.

When you think about it, it doesn't even make sense.

I don't.