[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: [kopete-devel] Re: Improving Kopete user interface and usability
From: Gustavo Barbieri <barbieri () gmail ! com>
Date: 2004-11-09 16:59:40
Message-ID: 9ef20ef30411090859595eaf1 () mail ! gmail ! com
[Download RAW message or body]
On Tue, 9 Nov 2004 09:37:40 -0600, Matt Rogers <mattr@kde.org> wrote:
> Hi,
>
> See http://mail.python.org/pipermail/python-dev/2000-March/002828.html to find
> out what the +1, -1, +0, -0 junk is. :)
>
>
>
> On Tuesday 09 November 2004 08:52 am, Richard Smith wrote:
> > Hi,
> >
> > Gustavo: I'm moving the discussion from bugzilla to kopete-devel. As Matt
> > said, bugzilla isn't a great place for complex, far-reaching discussions.
> >
> > I'm using ASF / python-dev voting notation:
> > http://mail.python.org/pipermail/python-dev/2000-March/002828.html
> >
> > On Tuesday 09 November 2004 12:34, Gustavo Sverzut Barbieri wrote:
> > > To start with icons used. My experience with users and kopete is that
> > > users misunderstand some icons, they are:
> > > - Settings/Configure Kopete/Accounts: People like to think they
> > > contacts go there, since there is a person pictogram. Possible solution:
> > > adopt another icon like the kaddressbook one.
> > > - Main Window/Add Contact: everyone I know that uses kopete
> > > misunderstand that icon the first time and take some time to get used to
> > > it. The problem is that the icon is the same as for bookmark and no one
> > > seems to understand what the relationship between bookmarks and friends.
> > > People using the Crystal iconset often clicks the "Status" icon instead.
> > > Possible solution: a user picture with a "+" (plus) sign over it. It
> > > could be the icon used in Accounts or even the KDM's default2.png icon or
> > > something like that with the "+" over it.
> > > - Main Window/Show Offline Users: the icon used now is the one used for
> > > searching things. Possible solution: use the same base icon as for "Add
> > > Contact", but without the "+" sign and grayed or sleepy face, maybe not
> > > gray totaly since it will look like it's disabled. Other solution: a
> > > sleeping smiley, but this may looks like the user will be away himself.
> >
> > +1. If you could provide a list of icons which we should replace, and
> > suggest replacements, I'll make the changes. If any icons aren't available,
> > we can email kde-artwork to request them.
> >
>
> +1. _I_ have problems with the Add Contact icon and remembering what it does
/me too
> > > Window Size: seems that the chat window doesn't define a size or define a
> > > wrong one. My chat window starts at 200x267 and it doesn't fit anything.
> >
> > Is this bug #84627?
> >
>
> Probably. The problem then becomes, "What is a good default size for the chat
> window?"
A minimum size to fit at least one input line + 1 one line message +
default toolbar + menubar and that should not be greater than 640x480.
> > > Chat Window Toolbar Bloat: after the "bad" icons, this is the biggest
> > > source of problems. Users are shocked with the amount of buttons, and the
> > > first thing they say (to me) is: "Wow, I'll never understand all these
> > > buttons." And they don't need to.
> >
> > Yes, our chat window toolbar has too many buttons.
> >
> > > - Format Toolbar: Bold, Italic, Text Color are okay.
> > > But underline, background, font chooser, font size, and 4
> > > buttons for alignment is too much! This is almost a KWord KPart!
> >
> > You're right. Bold, italic and foreground colour are probably the only
> > formatting options of those available that are frequently used.
> >
> > > The best solution IMHO is to split the Format Toolbar in 2:
> > > * "Format Toolbar": bold, italic, text color
> > > * "Advanced Format Toolbar": background color, font size and
> > > alignment (but please group those into just one button). This should be
> > > disabled by default, these items are all in menus.
> >
> > +1. If no-one objects, I'll make this change.
> >
>
> +0. I can see people griping because they don't have all the text options
> available. However, since only one of our protocols supports full RTF, I
> don't guess it matters now that the Format Toolbar stays hidden. Also, I
> think a kconf_update script would have to be written that will hide the
> Advanced Format Toolbar when the Format Toolbar is hidden.
Ok.
> > > - Main Toolbar:
> > > * Add Smiley and Animation are okay for sure. Although I don't use
> > > them, many people add smileys using the toolbar and the
> > > animation effect is desired while the network operation is running.
> >
> > Yep.
> >
> > > * Detach and Close are not that used and are available in Menu and
> > > in the Tabs, like in konqueror, so they may not go in chat win by
> > > default.
> >
> > Just a note: everything is (or at least should be) available in menus.
> > That's no argument for removing something from the toolbar.
> >
> > However, I *never* use these buttons. +1.
> >
>
> +1 here too.
:)
> > > * Cut, Copy and Paste: I question these here. There is the
> > > (in)famous argument that people are used to the Ctrl+C/Ctrl+V concept,
> > > but my argument is other: Instant Messages are used for quick
> > > communication and so short messages, probably not even multi
> > > line (send on Enter was _requested_ and accepted!), so if one doesn't
> > > know the Ctrl+C/V he may type the message again or use the menu.
> >
> > I use at least paste. -0.
>
> -0 as well. People who know that Ctrl+Enter allows you to enter a new will
> send longer messages.
Ok. I proposed a toolbar "Edit" with just these actions, but Richard
rejected and it's ok with me... Keep these buttons in main toolbar.
> >
> > > * Save, Print: I wonder how many save their chats or print them! If
> > > you're talking to a special girl or an important talk with your
> > > boss/employee, but that's not the common case and these items
> > > are in Menu, so no functionality is lost.
> >
> > +1 on removing Print. +0 on removing Save.
> >
>
> -1 on removing Save. +1 on removing Print. Save is the easiest way to store a
> conversation and possible take it with you. I've also used it on occasion.
> I've never used Print.
Some points:
- People that wants to save their conversation can use the history
plugin to do it automatically
- Occasionally saving a conversation is _occasional_ and doesn't hurt
going to menu for that. It'll not be used that much.
I agree with Paste since maybe you don't want to use keyboard to paste
something and generally we paste too much :) But we don't save that
much.
> > > Contact List Popup Menu: I think it is too big.
> > > - There should be no "Send single message" since it's in Edit menu
> > > (not that Edit menu should contain send message, but it's another story).
> >
> > "Because it's in the menu" is no argument, especially here. People don't
> > select a contact then hit the Edit menu. Partly because selecting contacts
> > is hard with single-click-to-activate on. -1.
> >
>
> Former ICQ users will still use 'Send Single Message' and it will soon become
> the only way to send a message to multiple recipients with ICQ. (Note that
> this is not the same as a group chat). -1.
Now I see the purpose of Send Single Message. -1 too :)
> > > - Move and Copy to should be more explicit: Move to Group and Copy to
> > > Group.
> >
> > +0.
> >
>
> -1. Longer text for the translators, and IMHO, adding the word 'Group' doesn't
> add any sort of distinction as to what they do, especially since the menu
> that pops out is a list of groups.
I like Richard's solution with the "Groups" menu.
> > > - Special groups like "Top Level" should be differentiated from user
> > > created groups.
> >
> > In the Move / Copy submenus? Differentiated how? I agree in principle.
> > I think Top-Level should be kept at the top of the menu, with a separator
> > between it and the other groups. And maybe it should be given an icon (used
> > in the menus and in the contact list). In fact, I think all the groups in
> > the Move / Copy submenus should use their own icons.
> >
> > > - Accounts should be under a label "Contacts" or something else,
> > > something that make clear you will act on just one contact.
> >
> > +1 on this. Was going to suggest it myself. I was thinking of maybe:
> >
> > Contacts>
> > Add Contact>
> > ---
> > Contact 1>
> > Contact 2>
> > ...
> > Contact n>
> >
> > I think that would reduce clutter quite a bit.
> >
>
> +0. Although i don't like having to move my mouse through to *another*
> submenu...
At least you have to read less things at once.
> > Maybe something similar could be done with the options Move, Copy, Remove
> > from Group, Add to Contact List? (put them in a Groups submenu) Not sure
> > about this.
> >
> > > - In usability list is well know that you shouldn't have same icons for
> > > different actions. The icon purpose is to find action quickly, but if you
> > > have the same icon for "Send Single Message", "Start Chat" and "Send
> > > Mail", the same for "Remove from Group" and "Remove Contact", you are
> > > just confusing users.
> >
> > Remove from group shouldn't have the same icon as Remove contact.
> > +1 on removing its icon.
> >
> > As for Send Single Message and Start Chat, +1 on getting non-email-related
> > icons for them.
> >
> > > There's no problem leaving an item without an icon, instead: users will
> > > know the less important actions.
> > >
> > > - Since many users don't understand the Meta Contact concept very well
> > > and don't even use it, maybe kopete should offer a customized popup menu
> > > for meta contacts with just one contact.
> >
> > +0. But I think that metacontacts with just one contact should not get too
> > much special treatment. They are not different, and users should not think
> > of them as being different.
> >
>
> -1. -1. -1. People bitch at me because I want to keep metacontacts with an ICQ
> contact we're waiting on authorization for from being moved out of the group
> it's in to make my contact list handling easier. We won't special case
> metacontacts or contacts.
Okay, Okay, Okay! I was too unfortunate with this idea.
> > > These special cases are not that good, since the popup will change, but
> > > the point is the popup is too big and doesn't make access to often used
> > > features fast.
> >
> > Right-click on the contact icon for fast access.
> >
> > > There are two many items at the top (Send File, Send Email, Single
> > > Message and Sync KABC) that makes users give up on using that menu since
> > > they don't find the action, that is in a specific account sub menu.
> > >
> > > I would like to propose:
> > >
> > > [ <META_CONTACT_NAME> (<STATUS>) ]
> > > Start Chat...
> > > Actions>
> > > -----------
> > > Rearrange>
> > > Remove Meta Contact
> > > Add Sub Contact... <--- "sub contact" is not a good name, I know.
> > > Rename Meta Contact
> > > [ Sub Contacts ] <--- "sub contacts" is not a good name, I
> > > know. gsbarbieri jabber org
> > > ...
> > > -----------
> > > Properties
> > >
> > > Where:
> > > Actions:
> > > Send Single Message...
> > > Send File...
> > > Send Mail...
> > > Sync Addressbook...
> > > Rearrange:
> > > Move to Group>
> > > Copy to Group>
> > > Remove from Group <GROUP_NAME>
> > > Add sub contact: Doesn't ask for protocol there, if there is more
> > > than one, ask for it in the add contact window.
> >
> > Counterproposal:
> >
> > [MC NAME (Status)]
> > Open chat window using default interface preference [1]
> > Actions>
> > Start Chat
> > Send Single Message
> > ---
> > Send File
> > Send Email
> > ---
> > Sync with Address Book
> > <plugin actions here>
> > ---
> > Groups>
> > Add to Group>
> > Move to Group>
> > Remove from Group <name>
> > Contacts> [2]
> > Add Contact>
> > ---
> > Contact 1>
> > Contact 2>
> > ...
> > Contact n>
> > Rename Meta Contact [3]
> > Remove Meta Contact [3]
> > ---
> > Properties
> >
> > Notes:
> > [1] Obviously, a better name than this would be needed.
> > [2] If only one contact is in the metacontact, maybe its menu should be
> > shown here instead. In this case, I'm not sure what to do with Add Contact.
> > [3] We had a provisional agreement that the term "Meta Contact" should not
> > appear in the UI since users don't understand it. I think the term
> > "contact" is appropriate, since it's what KAB uses. But then what do we
> > call what we now call "contacts"? Subcontacts may be "not a good name", but
> > I'm struggling to think of something better.
> >
>
> +1 for the counterproposal.
+1 I agree.
> > > KTip: Kopete should add some ktips with the first being the meta contact
> > > concept.
> >
> > +1.
>
> -0. An IM program needs a 'Tip of the Day'?!? Also, do you really expect users
> to get or care about the meta contact concept? IMHO, unless we word it very
> carefully, we'll just end up confusing the user more, at least with that
> specific tip.
IM program used to be really simple, but then many protocols appeared
and good All-in-One programs like kopete. But to easy users life you
had to add the "Meta Contact" concept.
The KTip could be just a image saying what you can drag the little
protocol icons to other contact and a brief explanation. Users tend to
look at images and not read things.
--
Gustavo Sverzut Barbieri
---------------------------------------
Computer Engineer 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsbarbieri@jabber.org
ICQ#: 17249123
GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic