I was chatting with my co-worker, who shall remain nameless, who is among us the least happy to use darcs and is eager to switch to a different revision control tool.
I said something like "They think that in darcs v2 they will have fixed the bug in which resolving conflicts is takes exponential time...". He excitedly interrupted "THAT's not the problem! If THAT were the problem I could deal with that by working around it! The problem is," and he gestured to his screen, which said: ------- begin snapshot of his screen $ darcs pull -v -v -v ------- end snapshot of his screen "The problem is that I can't tell what it is doing! Is it hung? Is it waiting for a response from the server?". So this is a good example of how the problems of user experience are sometimes different (and "simpler") than the problems of engineering the actual core algorithms of your program. "Responsiveness" is, I think, the most important single factor in user interaction design. As quickly as possible after making a request, a user needs to know that their request has been received by the program and the program is doing the correct operation. Whenever the user has to wait, they should know that (a) the program is doing something useful rather than hung, (b) that progress is continuing to be made, and ideally also (c) some estimate of how much longer the wait will probably be. I know that Eric Kow added some features for darcs to emit more verbose progress messages if there are three or more "-v"'s, and so I hope that when that patch becomes available in a darcs release that it will help my co-worker. Regards, Zooko _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
