rlucas.net: The Next Generation Rotating Header Image

July 11th, 2006:

Feedback Rant Disclaimer: I’m Trying to Be Constructive

Jul 11th, 2006
by rlucas.
No comments yet

In the past several weeks I have had the opportunity to alpha-test, or beta-test, or other-Greek-letter test an abnormally large number of sofware products and web sites.

Not coincidentally, I have also had occasion to write a number of “user experience horror story” rants directed into various types of feedback forms, support@whatever.cxm addresses, and the like.

If you are the recipient of one such rants, I am writing this disclaimer for you to let you know a bit of where I’m coming from, in the hopes that you will take my feedback in the constructive spirit in which it was intended.

I love technology and I want to love your software.

I work for a software VC, and I’m an occasional contributor to various open-source (and proprietary) software projects. I install new software all the time, and only in a tiny fraction of a minority do I have any direct or indirect financial interest. So, I wrote my feedback rant mostly to try and be helpful; it’s part of my personal ethic of fighting entropy.

I managed a web app company for a few years, and I know some pitfalls to avoid.

I am by no means a guru, but if I rant at you about something specific to your technology, you might want to listen up. There’s a chance it’s a problem I’ve already fixed, or paid people to fix (or both, repeatedly, in some sad cases), and I want to save you that pain.

Other users will not be as nice.

Sometimes I state my case forcefully to get your attention. Other users will typically not be so nice — they will silently leave, or worse, save their vitriol for public fora (or worst yet, for private ones that you cannot see).

The frustrated user is the one to whom you owe your attentions.

Consider that if a user gets to the point where he is frustrated with your software and actively sending you feedback about that frustration, he has already demonstrated that he is patient (he was not frustrated at first) and persistent (if he were not, he would not have become frustrated but would merely have left). Do not turn a deaf ear! That same motivation for continuing past the point of frustration may be a motivation to spend lots of money with you, to contribute to your project, or otherwise to reach a mutual benefit — but only if you listen and act!

In closing, let me say that I’ve read a lot of user feedback, and not all constructive. My feedback rant is intended in a spirit of constructive criticism, and I ask that you receive it thus.

Plan Less, Write More

Jul 11th, 2006
by rlucas.
No comments yet

As a backlash to the overwhelming crappiness of most blogs (and, frankly, out of embarassment at the fairly poor initial quality of my naive early blog efforts), I have been overthinking blogging. As a result, my $HOME has ten outlines and half-written articles and over-written blog entires that have musroomed into manuscripts. My resolution: plan less, write more. This is the blog version of the agile software mantra: release early, release often. The paradox, of course, is learning to be disciplined about being /less disciplined/. Part of what brings this on is the experience of reading blogs regularly for the first time over the last few weeks, and discovering that the novelty and turnover of content is /not/, in fact, a strict tradeoff with quality. For example, there are some VC blogs that are infrequent and crappy (I am in too good a mood this morning to name names, although, gentle reader, it does not escape your correspondent that this very blog may hew closer than is comfortable to that description). Then, there are [http://avc.blogs.com/a_vc/ VC blogs] that are prolific /and/ good. Doubtless, the best bloggers could refine and revise for some marginal gain in quality. But the decreasing marginal returns of extra structure and revision would be outweighted by having them put out yet another quality — though not perfect — piece of writing. My other resolution: dispense with a surfeit of caution. Or, to paraphrase “Uncle Joe” Stalin, you can’t make an omelet without breaking some eggs. If making a point involves a deserved harangue of one rogue or another, I will deliver it. And building on the first resolution, if exposing a bit of passion or intensity means a typo ecsapes the editor’s pencil, so be it. For example, David Cowan [http://whohastimeforthis.blogspot.com/2006/04/created-by-school-teacher.html lays the smack down on a charlatan] in a blog entry so clearly motivated by passionate interest that the reader cannot help but be capitivated and delighted, despite the fact that the entire entry is a typographical and structural monstrosity. Final resolution: no more than one “gentle reader” comment per posting.

Vim 7 is Incompatible with the Vimspell Plugin

Jul 11th, 2006
by rlucas.
No comments yet

On my Cygwin environment on Win XP, Vim 7 appears to run fine with one exception: the vimspell.vim plugin. It apepars that Vimspell conflicts with the new built-in spell check functionality in Vim 7. The symptom of this is that one starts to type and a massive amount of doubled or missed letters start to appear (and, no, I was not drunk when I noticed this). Removing the vimspell.vim plugin works fine.

However, I like to use a consistent ~/.vim directory across all my shells, so that I can store it in CVS and enjoy the same settings on every system. To do this across a heterogeneous environment of Vim 6 and Vim 7 boxen, I have made the following change to vimspell.vim: 

61c61 < if exists("loaded_vimspell") || &compatible --- > if exists("loaded_vimspell") || &compatible || v:version >= 700

This will short-circuit out of vimspell before it gets loading if the version is Vim 7.0 or above.