Dear Aaron,

first of all I hope you are aware that your heading "a lesson to all" sounds like pure arrogance to everyone who took part in these discussions but is still not considered in any of your reasonings.

The discussions I was referring to before were started by Frans English in early-mid January this year on the usability list and kopete-devel list. Guess what he proposed? Yes, he wanted to remove Ctrl-Enter and Enter to stay as sole way to send messages in both single- and multiline text field, that what you just realized without even proposing it first. Now guess how the people on the mailing list generally reacted? Certainly less one-sided that you appear to think to be able to handle the issue now.

A couple of points you didn't care to consider or instead chose to outright dismiss so far:

Consistency in the use and handling of single- and multiline text fields. You dismiss all concerns here as purely "technical" and not related to the "use case". This approach is a great service at proving right all the people who claimed that "developer" and "usability expert" are "two kind of humans". And of course it doesn't add anything to the discussion (just look at your second last blog entry's title, " it's spelled "use case" ", usability is not about treating users as idiots, and neither should you with members in discussions, pretty please). Also putting the term "use case" above consistency without elaborating and backing this any further flies straight in the face of any usability effort, since after all, if it's that easy to break consistency, why even bother? Let's end all our discussions with our fitting favorite "use case", way to go indeed! But I digress, let me start what actual issues were ignored so far.

Firstly the most blatant one: you change the default in a bugfix release. Why is this wrong? Backported bugfixes and features are always welcome, with the big exception that they may not introduce new bugs and may not change behavior without the user's consent. The backport of the ability to set Enter for multiline send was a new feature which per se neither introduced a new bug nor changed the existing behavior. Backporting the Enter as default change however does just that, it changes he existing behavior without the user's consent. Everyone saying Boudewijn will be the only one dissatisfied about being patronized in this case is shamming.

Secondly the differentiation between singleline and multiline is there for a reason which is not at all technical. An editable text field with a single line, where content longer than the visible area are scrolled outside of the either end, communicates to the user that it can contain only one item at a time and that the string or message can be applied/executed/sent right away. This is what combo lists like the address bar and chat room systems (=short message talks) like IRC are about. An editable multiple line text field, where content is wrapped at the border, communicates to the user that it can contain longer text which can be tweaked to some degree, is usually review first and contains line breaks. This is what usual text fields are about, it applies to all multiline text areas on websites, it applies to all common editors, it applies to emails and it applies to instant messaging which was originally crafted as email alike system with the added feature of sending and receiving messages in real time if the contact in question is online at the same time as well.

In the mailing list discussion mentioned above a possible change from Ctrl-Enter to Enter was consequently criticized for following reasons:

* Keeping multiline with word wrap while having Enter for sending breaks consistency with the whole idea of differentiating between singleline and multiline at its core (same for Ctrl-Enter for singleline).

** This includes irritations about being unable to break lines while the multiline text field screams to the user that he can review and tweak it. Unlike the consistent case where the user can simply use the send button the inconsistent solution for clueless users completely takes away the ability to break lines.

** This includes irritations about accidentally sending a message, naturally at a point he wanted to add a line break, at which point the text is surely that long already that he'd ideally wanted to review it first before sending. All those are expected attributes by multiline text fields which are unfulfilled by breaking consistency.

Please keep in mind that I purposely left out the whole "familiarity" bias since the users familiarity with non-KDE platforms and applications is not even remotely related to how KDE has to be consistent with itself by default. KDE by default has to offer a system which doesn't surprise where it shouldn't (ideal usability), and that's exactly the reason for being consistent with itself. While already given familiarities with differing and contradicting preferences can give us a hint what optional features to offer, they shouldn't lead us to think that emulating an existing solution takes preference over staying consistent. You may ask why, here's the answer: Imagine we would take the approach of by default emulating other systems, this for fulfilling existing expectations built through existing familiarities with non-KDE systems, where would we be able to draw the line and not end up as a copycat with some additional/missing tweaks?

KDE can and does do better already. Many existing observations showed that KDE's focus on consistency makes the system easier to grasp for new computer users. For this and the above reasons I request that the change of default key for sending in multiline text fields in Kopete be reverted to the default suggested by KDE's style guide which all applications within KDE's CVS including Kopete should comply with.

Thank you for your attention.



if the points of logice went like this:

0. this is what is consistent
1. BUT here's a use case
2. let's choose the use case instead

i might agree with you. but the points flow like this:

0. what is the use case
1. what is consistent for that use case
2. let's choose what is consistent

i've already discussed the rest of the points you bring up, and i don't think we need a merry-go-round discussion where each of us just repeats ad-nauseum. =)

i agree that the backport of the behaviour is more controversial, due to the type of release it is. given the number of requests for this change, however, it's easy to view it as a bug. it is seriously the most commonly asked thing on IRC right now. at least whenever i'm around. Autostart and double-clicks are other common ones, but not nearly as common as kopete has been.

and yeah, i read that Ctrl+Enter thread back in January. unfortunately i was a bit busy with life to get involved.

oh, and btw, if you want to discuss the issues, great i'm all for it. if you want to take issue with how i write my blog, which is my personal little diary in the middle of my navel, spare me the verbage.

By Aaron J. Seigo at Sat, 09/18/2004 - 00:38

I think we are getting to the core where we can see where we have fundamental different approaches.

In my ideal use case of Joe KDE-User you can't get a circular loop, because the first question for me is not "how are use cases handled in other systems, and what of that is the lowest/most common denominator (thus usable by as many existing computer users as possible)" but rather "KDE is all he knows, how would he ideally handle this and that use case (thus usable by as many existing KDE users as possible)". This is exactly what I meant with "emulating", the change done in Kopete reflects more or less the current state of IM clients outside of KDE, saying in your order of points...

0. the use case is IM, let's see, many people use popular IM clients
1. many popular IM clients do it this way
2. Kopete should do it this way, too, since its consistent with those other clients

This means you make decision in favor of users who are already "spoiled", who already made an "experience" you want to carry over. The huge flaw I see in this approach is that KDE users, the very platform the whole use case should keep in mind, are completely left out as a result of that: None of KDE nor Kopete itself behaved that way before by default. (Conscious changes are imo a different matter unrelated to this all.) Ultimately I prefer the least surprise for users who never used anything else but KDE, everything else should imo be handled by KPersonalizer and the application's wizard where necessary. Never vice versa.

(edit: some clarifications, now leaving to bed ;) )

By Na at Sat, 09/18/2004 - 01:01

now, where did i say anything in my reply to you about "other systems"?

By Aaron J. Seigo at Sat, 09/18/2004 - 01:55

...but that's where I think you did not clarify your "use case" enough anyway. I can't imagine that anyone would get the "Enter for sending in multiline text fields" as ideal solution within KDE unless anyone involved with the use case already experience that somewhere outside KDE. You know, introducing an inconsistency just for the sake of it would make even less sense.

By Na at Sat, 09/18/2004 - 11:52

but rather “KDE is all he knows, how would he ideally handle this and that use case (thus usable by as many existing KDE users as possible)

By segedunum at Sun, 09/19/2004 - 20:01

how do you send emails? ow, enter, of course... (nope)
how do you save changes in for example a id3tag editor? enter?

nope. in KDE you save changes or send messages in multi-line boxes by ctrl-enter. always. just as it was in Kopete. and now it isnt, anymore. and imho, thats just plain stupid.

whats the logic in it? why send a message with enter, while you have to get to another line with ctrl-enter? in this messagebox, enter gets me another line. ctrl-enter should let me preview the comment (this isnt the case, and a wish has been sent:

there is NO SINGLE REASON to have enter send messages in kopete.

except one: MICROSOFT MESSENGER DOES IT. wooow... lets do it, too... btw, MICROSOFT MESSENGER is proprietary software, so lets change the licence for Kopete into a proprietary one, asap, cuz, well, MICROSOFT MESSENGER is very cool.


By superstoned at Mon, 12/06/2004 - 13:07