Review Request: Enhance icon behaviour of text ui
Martin Klapetek
martin.klapetek at gmail.com
Mon Jan 30 16:49:29 UTC 2012
> On Jan. 28, 2012, 4:06 p.m., Martin Klapetek wrote:
> > 1) Main icon is always the same (telepathy-kde) and adds an overlay when a new messages is received
> >
> > The main window icon of text ui should imho be the presence icon. Two reasons: 1) Contact list has the same icon; this would become unclear on icon-only task managers or even the default one, when you have so many windows opened that you can barely see the text. You wouldn't know which window is which. 2) It's nice that you can see the presence right in the taskbar. Use-case: I want to write message to David, I look down at my tasbakr, I see he's busy/away so I won't disturb him now. When he comes online, I can see this right away by the icon change in the taskbar.
> >
> > In the light of the above - this point is 'no' from me.
> >
> > 2) Tab bar is always shown
> >
> > Not sure you actually need this. The typing notification is always shown in window title, so {c|s}ould the "you've got new message" icon. If you have only one chat opened, it takes vertical space for nothing and we shouldn't waste it (especially netbook users etc wouldn't like it).
> >
> > So this point is not as big 'no' as the first one, but still rather 'no'-ish.
> >
> > 3) The user icon has an overlay if the user is typing or if there is an unread message (unread takes precedence over typing because I tried with 2 overlays and it looks horrible)
> > 4) Give the precedence to new messages over typing for name colour
> >
> > So if I got this right - I get new message and the user is typing, I won't see him typing? That's not too nice. Use-case: The user sends me a message to a window I have on a second screen, but not focused (can be on the same screen obviously). The message ending is ambiguous and I'm not sure if that was really the message ending or if he's writing a follow-up message. Quickly looking at the icon/tab color would give me a clue right away, but with your proposed solution, I would see only the new message icon and I would have to give focus to the window to dismiss the new message icon and see if the user is typing.
> >
> > To sum it up - Improvements: yes. This proposal: sorry.
>
> David Edmundson wrote:
> " I see he's busy/away so I won't disturb him now. When he comes online, I can see this right away by the icon change in the taskbar."
> You can talk to me whenever :-D. I'm not sure that use case is great, but I agree we shouldn't clash with the contact list, what do any other clients do?
>
> I think we need some way of making sure you can see when someone is typing AND has an unread message. Not just one or the other..but how?
>
> Anyway, I'll try this branch for a week, then see what it's like. I like the idea of the unread message icon somewhere.
>
>
> Martin Klapetek wrote:
> "You can talk to me whenever :-D. I'm not sure that use case is great, but I agree we shouldn't clash with the contact list, what do any other clients do?"
>
> And I sure will. But consider also offline presence. Use-case v2: The user tells you "wait, I need to go away/restart computer/change my ram/I'm loosing net connection" and goes offline, you just switch to another window and wait for your friend to get online. You don't have to check anything because you can see that right away from the taskbar. So he comes online, you just switch back to the window and continue the chat. I personally consider this a very nice feature. And not only for stalking.
>
> "I think we need some way of making sure you can see when someone is typing AND has an unread message. Not just one or the other..but how?"
>
> One solution could be a good looking set of overlays. Such set, that actually works together. So you can have the presence icon, message overlay over that AND a typing icon over both of these. If we had three icons that work together when laid over themselves, it would be total win.
>
> Daniele Elmo Domenichelli wrote:
> I've never seen any client showing the status as main icon, and in my opinion, it doesn't make sense for a tabbed window. What Martin is talking about is in my opinion what the "stalker" plasmoid should do, not the chat window... Anyway let's try to consider everything and come to a solution
>
> We have several things to consider here
>
> a1) Main window icon
> a2) One or more possible overlays for main window icon. Normally having more than one overlay is quite ugly, but using the status as bottom-left overlay is not that bed (see http://wstaw.org/m/2012/01/30/snapshot43.png and http://wstaw.org/m/2012/01/30/snapshot44.png) so I think we can have 2 overlays
> b) Main window title (most tabbed applications show a list of the tabs + " - Application Name", so I suggest to do the same)
> c) Show/hide tab bar
> d1) Tab icon
> d2 One possible overlay for tab icon. If we keep the status icon as overlay, the overlay on the bottom right looks horrible.
> e1) Tab title
> e2) Colour for tab title
> f) (Skype adds a grey line to the text chat when someone is writing and removes it later but I don't know if this is possible for the text ui at the moment so let's forget about this option)
>
> We want to show:
>
> 1) Alias of the contact
> 2) When we have an unread message
> 3) When contact is typing
> 4) Status of the contact
>
>
> So my proposal is this:
>
> - For single tab windows:
>
> a1) Icon is always "telepathy-kde"
> a2) Overlays:
> - external top-left "unread messages"
> - bottom left "user status" or "user is typing" (typing takes precedence over status)
> b) To be honest I don't like the "Typing... " string in front, it takes a lot of space and I cannot see the name of the person I suggest to use a postponed "[typing]" after the name (like kate does for modified files, for example), so I suggest contact name + <"[typing]"> + " - KDE Telepathy" (or "Text UI" or some other string)
> c) Do not display the tab bar for single tab windows (d and e cannot be set)
>
> - For multiple tabs windows:
>
> a1) Icon is always "telepathy-kde"
> a2) Overlays
> - external top-left unread messages in _any_ tab
> - bottom left same as for single tab but for current tab only
> b) There are different behaviours here, some app show a list of tabs, some others just show the shown one. Since we are displaying informations about the status of the user I suggest to consider just current tab, i.e. same as for single tab windows
> c) obviously display tabs :)
> d1) Use the status as icon (we could use the telepathy-kde icon here as well to have 2 different overlays, but it doesn't look nice to me)
> d2) Overlays:
> - external top-left "unread messages" or "user is typing" (unread takes precedence over typing)
> e1) Title is always contact's name
> e2) - different colours for "unread messages" or "user is typing" (I'd say to be coherent with icon, so unread takes precedence over typing, and you get the info if user is typing from the main title and main icon, but we can do the opposite)
>
>
> - For group chats we have one extra icon per contact
>
> a1) Icon is always "telepathy-kde"
> a2) Overlays
> - external top-left unchanged
> - bottom left we probably don't want to know the status in this case, so just leave the typing icon here if any user is typing.
> b) Chat channel name + "[typing]" if any user is typing + " - KDE Telepathy"
> d1) (when shown) Status icon doesn't make sense here, we could have a "room" icon or use "telepathy-kde"
> d2) (when shown) Overlays:
> - external top-left just for "unread messages" (we display the "typing status" for single users)
> e1) (when shown) Title is always chat room name
> e2) (when shown) different colours just for "unread messages" (we display the "typing status" for single users)
> Then we have the icon for the single user that is the status and the external top-left overlay for "user is typing"
>
> I hope I didn't forget anything... :D
>
> What do you think?
>
> Martin Klapetek wrote:
> "I've never seen any client showing the status as main icon, and in my opinion, it doesn't make sense for a tabbed window. What Martin is talking about is in my opinion what the "stalker" plasmoid should do, not the chat window..."
>
> It's not a bug, it's a feature! Also, that's not really a reason to remove such feature ("because nobody else does it"). It does make sense for non-tabbed windows and it's not deprecated by the "stalker" plasmoid. At least not until it will have embedded chat window (besides I remember nwoki saying that the plasmoid is not meant to be in the panel). Furthermore it still clashes with the contact list. And last but not least is that it removes feature for no good/serious reason.
>
> The overlays should be imho situated on the right side - the new should be top-right and the typing should be bottom-right. This is more consistent with the rest of KDE. But they are soooo tiny that it kinda misses the purpose (I had to look hard and very closely at your screenshots to spot them). Given we actually have only two overlays, we can make them bigger and paint over themselves. I can create some mockups later, but assuming the icon is 16x16, just try to put the "typing" icon bottom-right with it being 10x10 or 12x12 and then put the "new message" icon in the top-right over the typing icon (it will be seen beneath it) with 4x4 or 8x8 size. I can see this working.
>
> Removing "Typing..." - the reason why it is prepended is so users can see it in the taskbar. The idea is based on the fact that you know the name from the taskbar entry and if it suddenly changes to "Typing...", it should be clear whose name was there before. Given the fact that it alternates, it's not really a problem. If we manage to indicate this somehow else (I want to look in the Dock Manager API), then it can sure be removed/appended at the end. Just please don't use things like "[typing]". We are trying to be as non-technical as possible and introducing string in square brackets just goes against it. Put there "is typing" or something similar and it will be awesome.
>
> As for typing & new message order - I think that "typing" always takes precedence. Simply because the new message occured in the past and the typing is happening right now. The other way around it makes text-ui stucked in the past and not reflecting the current (real) status.
>
> Daniele Elmo Domenichelli wrote:
> > "It's not a bug, it's a feature!"
> It's not a feature, it's a bug, that's a behaviour that you don't see anywhere else on the desktop and in my opinion it is an usability problem. When I look at the taskbar the first thing that I see is the icon and the first thing that I see about the icon is the colour, so if I'm looking for a certain window, my eye automatically searches for the window of that colour that I am expecting. If the user status changed, I don't find it at first and I have to do a more in-depth search for the window. Moreover I can't imagine what will happen for taskbars like mac osx one, what will the icon display if you have more than one window?
> Anyway we could ask this to the usability guys...
>
> > The overlays should be imho situated on the right side
> The overlay can for the small icon looks horrible on the right side, from what I can understand there are 5 positions 4 "internals" {top,bottom}-{right,left} and 1 "external" at top left. I'm using the external one, because the other ones don't look good (especially on the "status" icon"). The alternative is to "redraw" the icon by adding the overlays manually, but this is something that I don't want to do because in my opinion it's just a waste of time (unless you want to write the number of unread messages on the icon or something similar, but this is far beyond the aim of this patch)
>
> > Just please don't use things like "[typing]". We are trying to be as non-technical as possible and introducing string in square brackets just goes against it.
> I don't see how a square bracket can be considered "technical", would you consider a "(typing)" technical too? Anyway ok for the "is typing" appended... An alternative is to use an "*" in front like some other apps do when you have a modified tab, but I don't really like it.
>
> > I think that "typing" always takes precedence.
> I strongly disagree with this. As I already tried to explain in other occasions, the "typing" signal look nice and cool but is imho very dangerous. Just imagine that the user starts typing a new messages and doesn't send it or that the user hits enter and another key close to the enter (it happens quite often to me with "ù" with italian keyboard). You won't realize that the user sent a message and you will be expecting to get one soon, so you won't open the chat. The other user is not aware of this, so he will wait for you to reply, and you enter a deadlock! :D
>
>
> Martin Klapetek wrote:
> > "that's a behaviour that you don't see anywhere else on the desktop"
>
> For example Pidgin does exactly this. I'd be interested in what Empathy does. Using your use-case however fails when having non-tabbed interface. Imagine 4 windows + contact list. You'd have no idea which icon is actually what and you don't always find the contact at first. Using the presence icons, it's moreless the same except you have one feature on top - seeing immediately the presence of the user. Solution could be a special icon for text-ui with presence overlay.
>
> > "The overlay can for the small icon looks horrible on the right side"
>
> If your argument in other points is "no other apps does that", you should stick to it! :P Going through some KDE apps, all icons have overlays on the right (be it custom-painted or oxygen-theme). As for the redraw issue - well the icon has to be painted somehow anyway.
>
>
> > "Just imagine that the user starts typing a new messages and doesn't send it or that the user hits enter and another key close to the enter (it happens quite often to me with "ù" with italian keyboard)"
>
> But that's not really something we should be solving as it is clearly the user's fault. Same case could be with user typing very long message. To solve this we actually need to support one more state in text-ui the "text composed, not typing right now". There's fixme/bug on this. Then you can clearly see if the user is still typing or has typed a message and stopped. I also think that if one presses some letter by accident, the immediate reaction is to delete it.
>
>
> > "Just imagine that the user starts typing a new messages and doesn't send it"
> Depends on the form it takes. If it is symbolized by the overlay icons, there's no problem with it as both the overlays can be seen. If we're talking about text-only, that is tricky. If we have text+icon that can show both, it does not really matter as both states are visible.
>
> Daniele Elmo Domenichelli wrote:
> > For example Pidgin does exactly this. I'd be interested in what Empathy does.
>
> Those are not a KDE application... Kopete, when the status is not "online" shows an overlay to the icon on the bottom right over the _protocol_ icon, it doesn't show the status for "online" persons, so it is even another behaviour, and actually looks like a better choice to me, because at the moment we don't have any way to know which protocol we are using. Probably we should use the protocol icon instead of the status one in the tabbed view, and apply an overlay with the status.
>
>
> > Going through some KDE apps, all icons have overlays on the right
>
> Can you make me some examples? I couldn't find any example with icon on the top-right, just some on the bottom-right, some at the bottom left and some in the centre...
>
>
>
> > But that's not really something we should be solving as it is clearly the user's fault.
>
> It's not... If you don't show that someone sent him a new message is clearly an application fault, not his fault.
> "Probably we should use the protocol icon instead of the status one in the tabbed view, and apply an overlay with the status."
Fair enough. Though I'd like to point out that this not solve the original "problem" you had with the presence icons as window icons.
> "Can you make me some examples?"
Try opening Kate and see icons in the window main menu - File->New, File->Open Recent, View->New window and few others.
As for your last point - my response was to the user pressing a letter by accident. That is users fault, the application would imho behave correctly. It can't know if you pressed something by accident or if you are actually typing something.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103811/#review10175
-----------------------------------------------------------
On Jan. 28, 2012, 2:30 p.m., Daniele Elmo Domenichelli wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103811/
> -----------------------------------------------------------
>
> (Updated Jan. 28, 2012, 2:30 p.m.)
>
>
> Review request for Telepathy and David Edmundson.
>
>
> Description
> -------
>
> We spoke about this some time ago on irc...
> Currently the behaviour of the main icon is not really useful.
> With this patch the icon will change when you receive a message, and it will make it easier to understand that you have an unread message (at the moment if you don't notice the blinking app in the task manager it's not easy to spot)
>
> This set of patches do the following (you may agree or disagree with some of them, I'm not really convinced by all of them, so let's discuss it)
>
> 1) Main icon is always the same (telepathy-kde) and adds an overlay when a new messages is received
> 2) Tab bar is always shown
> 3) The user icon has an overlay if the user is typing or if there is an unread message (unread takes precedence over typing because I tried with 2 overlays and it looks horrible)
> 4) Give the precedence to new messages over typing for name colour
>
> branch is here: http://quickgit.kde.org/index.php?p=clones%2Fktp-text-ui%2Fddomenichelli%2Fktp-text-ui.git&a=shortlog&h=refs/heads/iconEnhancement
>
>
> Diffs
> -----
>
> app/chat-window.h 4afa8a1b8d6ee92f75197bf57895f3a57526c516
> app/chat-window.cpp 59db66db442dffbb3352ca1c66133f1c461d1b59
> lib/chat-widget.cpp 872de0299cd0eb11d61f9bab6ba12fe493336207
>
> Diff: http://git.reviewboard.kde.org/r/103811/diff/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Daniele Elmo Domenichelli
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20120130/5fceb53d/attachment-0001.html>
More information about the KDE-Telepathy
mailing list