Style guide decision needed (was: [Kopete-devel] Bug#40938: behaviour change request)

[Antonio Larrosa Jiménez]

El Sunday 28 April 2002 17:16, Martijn Klingens escribió:
> On Sunday 28 April 2002 16:45, Antonio Larrosa Jiménez wrote:
> > > 1. Make it a proper KAction, so you have the 'customize key
> > > bindings' option 2. Tip of the day
> > >
> > > Both are fairly common practice in many other KDE apps as well,
> >
> > We're not talking about other applications, but about kopete.
>
> But if most of KDE uses those, why can't Kopete be made to use them?
>

Because other applications are not IM clients.

> > Yes, alt-f4 is nicely written at the right of the menu option "close"
> > which I have to click to close my window. Where will Ctrl-Enter be
> > written ?
>
> Tooltip? Configure Key Bindings? What's This? Tip of the day?
>

Ok, so you're admitting that reading a tooltip, a tip of the day or a 
"what's this" message is needed to use Kopete, aren't you?
That's not good ui design.

> > > My mom uses the mouse for stuff like this, not the keyboard.
> >
> > Many people will do the same. But come on, how many windows does
> > she/you close in a day ? Will you compare that to the key binding to
> > submit some text in a IM application ? (where you write at least 3 or
> > 4 lines each minute).
>
> I was talking about the send action in an instant messaging client,
> actually. Ok, she doesn't use IM, but I'm damn pretty sure she would use
> the mouse to send if she did.
>

And she will use the mouse because she won't know about Ctrl-Enter until 
she reads it somewhere (in a tooltip, tip of the day, etc.).

And even if she doesn't find that just pressing Enter submits, ask her, 
what would she prefer to use to submit the message? Enter or Ctrl-Enter?

> > > Which assumes you always (or at least mostly) send a single line of
> > > data, which is hardly the case for me.
> >
> > And? I'm not saying that multilineedit should be forbidden.
>
> No, it means that the most common action (newline) should get the most
> common keybinding (enter).
>

That's precisely what we're discussing. I think the most common action is 
"submit" becausemost people always submit after each new line . Just talk 
with any of your friends on ICQ/MSN who you consider "an average user" and 
see how many "messages" he writes with one line of content, or more than 
one line of contents. I did it with several (3) of my friends, MSN users 
who, btw, never used IRC (a student of mathematics, a student of 
telecommunications, and a waiter) and _nobody_ wrote multiple lines 
messages (and I even asked them to do so, but they simply don't know how 
and "never found a reason to do it" )

> > > And why do you think even MS' own client (which is the most dumbed
> > > down of MSN, Trillian, ICQ, Yahoo, Kopete, ... ) supports ONLY a
> > > multiline edit?
> >
> > Because their users don't care about multilineedits (which, believe it
> > or not, is a "power user" feature that the average user won't use) and
> > because they support both multilineedit _and_ Enter sends text. But
> > still they provide a multilineedit for you to use multi line messages.
>
> Yes, and you were talking about making this *configurable* and off by
> default??? Even in MS' client this is *not* configurable and *on*, and I

I said to make it configurable to be consistant with single-lineedits and 
multiplelineedits depending on the user needs.

> said that's the most dumbed down IM client of all. I don't think we
> should aim below even their level...
>

Please explain what you mean with that. Why do you think that asking the 
user if he wants to write multiline messages and suppose that they won't 
write them by default so that they can use Enter to submit instead of 
Ctrl-Enter is dumbing down an IM client ?

> > > Because everyone uses that feature. Difference is that MS uses
> > > shift-enter for newline, just like in MS Word, where shift-enter is
> > > a line break, as opposed to a paragraph break. That leaves enter
> > > available for send.
> >
> > My proposal involved both, being consistant _and_ easy to use by using
> > an option that explicitly says the kind of widget kopete would use.
>
> That's not easy, because as you know newbies and config options don't
> match. Newbies and multiline messages do.

That's your opinion. I think newbies and singleline messages match much 
more, just do some tests! I did them, do you want me to send you the 
complete logs?
They _never_ write multiline messages.

>
> > Ok, if you prefer consistency with LICQ over easy of use then do what
> > you want.
>
> I never used LICQ, I have no idea what keybindings it has. I used MS'

I never used it neither, but someone explained on this thread how it works.

> client, I use KMail, I am thinking of something that is (or can be)
> consistent with KHTML (which enter-to-submit) cannot ever be used for.

??

>
> > But MS (and IRC) choose easy of use (Enter submits) and that's for a
> > reason (ok, IRC doesn't support multiple line messages anyway, but,
> > come on, have you ever really needed them in IRC?
>
> Well, it would be damn handy if I could write longer messages in one
> burst, with proper paragraph endings and all, so people can read the
> message as whole with no people replying halfway already or people also
> on the channel chatting inbetween my lines... But oh well, that's not
> possible.

Just check the "use multiple line messages" box and there you are.

>
> > And most important, do you think more than 5% of our users will ever
> > need it? )
>
> If it were available, yes. But it is not.

You're talking about your opinions, I'm talking after doing some tests.

Why does everybody talks about things without doing tests ?!

Now, I'm feeling really bad, so this will be my last mail on this thread, 
if you prefer to ignore my tests and ignore the facts, ok. Do what you 
want. If you really want me to continue giving ideas to make kopete much 
easier to use, just send me a mail in private.

Greetings,

--
Antonio Larrosa Jimenez
KDE Core developer  - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
KDE - The development framework of the future, today.