GNOME Bugzilla – Bug 710176
Timestamp, nickname handler, chat dialogs
Last modified: 2021-06-10 11:03:52 UTC
Created attachment 257336 [details] mockup See attached mockup. I propose: 1. Timestamp can be hidden/shown in the same way as userlist. 2. User can click any nickname (from list or chat) to add it to message she is typing. 3. User can remove the nickname by single click on "x" (pretty similar to gmail web interface of composing). 4. No need to show nicname one more time when someone sent two or more messages. 5. Show user nickname not as bolt but highlighted by colour. 6. When someone joins or leaves the room we can show "+" and "-" instead of text. Icons may be changed to more relevant ones, but it's better to represent those events in visual way, reason - too much iterative text user must read. 7. Scrolling unread messages are not always cool because you can lost where the last message you read, so we may fade them. Any ++,--, // are welcome. :)
(In reply to comment #0) > I propose: > 1. Timestamp can be hidden/shown in the same way as userlist. I'd like to try to do without another UI element, and only add timestamps after some time of inactivity - I don't see any use in "this message was send 2 seconds after the last one", but when reading through the backlog, "this message was send two hours ago" is useful. > [...] > 4. No need to show nickname one more time when someone sent two or more > messages. This has been the behavior of the chat log from the beginning ... > [...] > 7. Scrolling unread messages are not always cool because you can lost where the > last message you read, so we may fade them. The designers have asked for a xchat-style left-off-line, see bug 709850.
Let's turn these suggestions into use cases: - When somebody directly asks a question, a good chunk of time can pass. It would be desirable to have a timestamp for direct messages along with indicating if the person asking is still online. - Make it easier to mention names. Because this is a chat program and you are in the middle of typing a message, it is desirable to do it using a keyboard. - Avoid visual cruft by repeating things like timestamps or nicknames for each line. - User leaving or entering isn't useful per se and generates a lot of noise. The major use case is to know when a person has legft purposefully or has been disconnected when in conversation. Find a way to communicate availability better. - Do a better job scrolling (possibly bug #709843) Any of these could be a separate bug.
(In reply to comment #2) > Let's turn these suggestions into use cases: > > - When somebody directly asks a question, a good chunk of time can pass. It > would be desirable to have a timestamp for direct messages along with > indicating if the person asking is still online. I think we may add coloured nickname for better representing, so we can fade to grey if he is offline. But I'm not sure if coloured nickaname is a good idea for you. > - Make it easier to mention names. Because this is a chat program and you are > in the middle of typing a message, it is desirable to do it using a keyboard. You can click some button (Tab, for example) to list all nicknames and while you typing list becomes shorter. You can navigate with arrows and select by Enter. Is it good to you? > - Avoid visual cruft by repeating things like timestamps or nicknames for each > line. My mockup works well with this use case. Timestamps is hideable. Nicknames aren't repeatable. > - User leaving or entering isn't useful per se and generates a lot of noise. > The major use case is to know when a person has legft purposefully or has been > disconnected when in conversation. Find a way to communicate availability > better. Should we hide this information by default? Should we make it customizable? > - Do a better job scrolling (possibly bug #709843) > > Any of these could be a separate bug. I just proposed new mockup here. Do you want me to open separate bugs for each UI element according to this mockup? I'll do, just say.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Polari, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/polari/-/issues/ Thank you for your understanding and your help.