I agree with parts of this, and disagree with parts.
Doing what people expect is clearly the right place to
start. If you have
surprises,
make sure that they are pleasant ones.
Having documentation only results in being able to say that the
people who
make
mistakes should have known better. Quick question, Phil,
do you really think that if I had more documentation, either on the
form itself or a mere one click away, this problem would have been
avoided?
Now we get to the place where I outright disagree. Phil
points out that some comment systems eat the HTML as it displays
it. Because of this, Phil argues that preview should be
avoided. I disagree - preview should be fixed on those blogs
which have this problem.
I am pretty much unconvinced that there is a "what people expect", i.e., a standard way to approach comments from which divergences should be noted. For example, I don't generally know whether my email address is required or not, whether HTML will work, whether links will work, and so on. It seems to me that whatever your policy is, you have to document it (and note that that "whatever" is starred because I don't know whether HTML will work in this box!) Preview can go some way to solving this, I agree.
The other thing I'd like to see is the "remember me" box ticked by default if you are already remembered, i.e., there's already a cookie stored for your data here. This would be solved by some better way of identifying yourself (automatically), and that would also fix the non-authenticated comments problem, but I can't see any way of doing that.
And I'm a complete hypocrite, because kryogenix doesn't list its HTML-in-comments policy either...
Would it have been avoided? Probably not, because I tend to think I'm too bright for preview (and because I know your preview doesn't show me previous comments, including those that have arrived since I started, which is most of what I use preview for). But it's possible that if I had glanced down at a single line of links below the buttons and seen "Wiki formatting" as one of them, that I would have remembered.
I certainly didn't intend to argue that HTML-strippers shouldn't offer preview, just that they, more than anyone, should offer up a warning, because of the data-loss involved in their preview. Probably my complaint is more with the people who write HTML stripping routines that way: if you don't allow HTML but do allow Wiki formatting, then preview should change an em tag to underscores rather than just remove it, and, the one that annoys me the most, if you don't allow real links, just URLs, then the stripped link should be converted to something like "link text (theurl)". However, I'm not sure I've got what it takes to hack that into MT, though I think you can use separate textfilter plugins for yourself and for comments, so it could be done.
As to "people don't read", that's certainly true, and Mark's the poster boy for it, with mile-long URLs hanging off the side of the column here, unlinked ones in my comments, and the inability to add feeds to SharpReader because he couldn't be bothered to read through two-thirds of the bullet points. I can't argue that most people read.
However, in this and lots of other things I do, I want things to be right for the rare person who actually tries to do things right. If someone who's just getting into blogging is leaving his first awestruck comment here, I want him to be able to leave a perfect, flawless comment, without having to remember that the keywords which will pull up your "comment formatting" post are in fact "wiki comments", or maybe "html escaped", but not "html allowed". I do believe in doing things the way the careless expect them to be done, but only as a second priority, after doing them so that the careful can do them right.
I'd have a lot easier time arguing this somewhere that the comment system isn't nearly perfect, though. I'd like to see "Wiki formatting", maybe flush right above the textarea, linked to your post explaining the rules, but beyond that your comments don't really give me any problems. When I remember to preview.
The absolutely perfect Sam Ruby solution: you may do the right thing, if you do do the right thing, good things will happen to and for you. If you do the wrong thing, and choose not to preview, on your head be it. I love it.
Yes, Phil, let's absolutely be different. Let's be completely fcking different, just for the sake of being different. Who need those pesky keyboard shortcuts anyway? If all my other apps use command-left-arrow for "Back" but you want to use "command-[", well, I'll just have to learn your keyboard shortcuts, because your app is Just That Good. It's so obvious now. New applications should simply ignore years of user interface experience, and just make up their own rules. As long as they document them fully in the documentation that nobody reads, where's the harm? It's not like consistency is a virtue. In fact, let's defend difference for difference's sake, by bringing up counterexamples of fcked up power-user apps whose developers feel that consistency is only dragging them down and feel they are doing their users a favor by omitting vital menu items, prompts, dialogs, tooltips, and all the rest of the "cruft" that builds up in all those other well-designed, mature, "user-friendly" apps.
Consistency: WHO NEEDS IT?
PS - I tried to send you this via private email, but I'm testing out a new mail client and can't find the "send" button. Oops, I figured it out, turns out there isn't one, you just hit Control-Enter to send the message. So much wasted space on those toolbars, isn't there? This way is much more intuitive.
Sam, your wiki-like syntax should only apply bold formatting when asterisks are used around words, not within words. I believe adding "\b" (matches word boundary) at the appropriate point in your regular expression would fix this.
Also, could you add "wiki" to your custom dictionary?