GNOME Bugzilla – Bug 711542
Better handling of status messages
Last modified: 2016-06-16 06:47:17 UTC
Created attachment 259065 [details] Colored nicknames example of Cable IRC client In busy channels its hard to follow one specific person. It would help a lot if the nicknames would have colors, like the guys developing the Cable IRC Client did (see attachment) For non-busy channels, it would be helpful if there was an (optional?) timestamp somewhere. Also, it would be nice if there would be an option to hide Join/Part/Quit messages .
(In reply to comment #0) > It would help a lot if the nicknames would have colors See bug 710208. > For non-busy channels, it would be helpful if there was an (optional?) > timestamp somewhere. The plan is to not provide an option, but be smart about inserting timestamps, e.g. insert a timestamp after some time of inactivity[0] > Also, it would be nice if there would be an option to hide Join/Part/Quit > messages. Again, not very fond of options - I'd like to investigate ways to "compress" status messages (or figure out relevant ones and hide others) rather than require users to toggle an option. [0] https://bugzilla.gnome.org/show_bug.cgi?id=710176#c1
Also note that it is better to file one bug per issue. As there are (kind of) bugs for the first two issues, let's make this one about the third.
*** Bug 750682 has been marked as a duplicate of this bug. ***
I have created a branch which attempts to solve the issue. https://git.gnome.org/browse/polari/log/?h=wip/bastianilso/status-hiding This is the logic so far: - Status messages are displayed for any IRC user who has sent messages to the channel within the last X minutes. - On channels which hasn't seen activity in X minutes, all status messages are freely emitted. If more than 4 consecutive status messages are displayed, the status messages are compressed into one "X users left, X users joined". This compressed status message can be expanded at any time, should the user wish to know who have joined or left the channel. Additionally we could check corner cases such as the case where you are about to ping someone and then that person then disconnects. What do you think?
I’ve been testing that branch for a while and it is pretty serious usability improvement. Would land it in its current state and iterate on it from there.
*** Bug 755983 has been marked as a duplicate of this bug. ***
(In reply to Mystilleef from Bug 755983) > In large channels, status messages are noisy, distracting, and largely > irrelevant. They break the flow of discussion, and obscure the readability > of conversations. > > Showing __only the latest status message__ in a special buffer, perhaps > above the chat buffer, is likely to solve these problems. > > For users who need a history of the status messages, they can simply click > the special buffer to expand, or show a dedicated UI with , these messages. > My proposal decouples status messages from chat conversations leading to a > better user experience. I think this will work great in addition to the > solution in Bug 711542. > > Thoughts? I do not think that cluttering the user interface with another view is a good approach to solve the problem of noise. Could you elaborate why you think the solution proposed needs to be complimented by another one? From my own testing, the proposed solution pretty much solves the problem already on its own. If you can show some use cases that the proposed branch does not solve, I would love to know. Mockups are also very welcome and could help the discussion further.
(In reply to Bastian Ilsø from comment #7) > (In reply to Mystilleef from Bug 755983) > > In large channels, status messages are noisy, distracting, and largely > > irrelevant. They break the flow of discussion, and obscure the readability > > of conversations. > > > > Showing __only the latest status message__ in a special buffer, perhaps > > above the chat buffer, is likely to solve these problems. > > > > For users who need a history of the status messages, they can simply click > > the special buffer to expand, or show a dedicated UI with , these messages. > > My proposal decouples status messages from chat conversations leading to a > > better user experience. I think this will work great in addition to the > > solution in Bug 711542. > > > > Thoughts? > > I do not think that cluttering the user interface with another view is a > good approach to solve the problem of noise. > > Could you elaborate why you think the solution proposed needs to be > complimented by another one? From my own testing, the proposed solution > pretty much solves the problem already on its own. If you can show some use > cases that the proposed branch does not solve, I would love to know. > > Mockups are also very welcome and could help the discussion further. I'm testing the solution available in the "status-hiding" branch and it addresses most of my complaints in Bug 755983. I still strongly believe that status messages don't belong in the conversation view because, well, they are not conversations, and they add nothing to the discussion. I doubt anyone cares who disconnected, left, quit, joined, was kicked, was banned, or whatever, when they're reading an engaging conversation. Status messages belong in their own view because they're auxiliary to the primary tasks of reading conversations. As for the UI, I'd implement the status message area as a view buffer immediately above the conversation view and have it expandable like you currently do in the "status-hiding" branch. The text of the status messages should be light grey to signify their secondary importance. The view should only be updated with the latest messages. Older messages are hidden behind and expandable UI. Again like you've implemented in the "status-hiding" branch. I'd also use the same algorithm in the "status-hiding" branch to determine when to update the status view. The benefits of having status messages in their own dedicated view are two-fold: 1). The conversation view is dedicated ONLY to conversations, and thus significantly improves the readability experience. 2). For users interested in status messages, they can now access it from one place, as opposed to endlessly scrolling through the conversation buffer for a history of status messages. Either way, having use the "status-hiding" branch for over 24 hours, I've completely removed Xchat, a client I've used for over a decade, from my computer. Polari is the simplest, cleanest, most well designed IRC client I've ever used. You guys put a lot of thought to the design of Polari. Kudos to the team.
(In reply to Mystilleef from comment #8) > I'm testing the solution available in the "status-hiding" branch and it > addresses most of my complaints in Bug 755983. Thanks for testing, it's very appreciated. > I still strongly believe that status messages don't belong in the > conversation view because, well, they are not conversations, and they add > nothing to the discussion. [..] We have two different beliefs here then. I agree that displaying status messages for all users will result in a lot of noise when you are just trying to follow a conversation. Some users' status messages are interesting, however: 1) Status messages from users who is actively participating in the conversation. 2) Status messages from users whose presence or lack of presence you have an interest in (and want to keep track of mentally, Carlos have a WIP patch we can utilize in Bug 710274). > 1). The conversation view is dedicated ONLY to conversations, and thus > significantly improves the readability experience. IMO the goal of the chatview is bit more broad - to only display room activity which is interesting for you to see. > 2). For users interested in status messages, they can now access it from one > place, as opposed to endlessly scrolling through the conversation buffer for > a history of status messages. I had one other user commenting that there is a need to check who has entered the room even when there is an ongoing conversation. Even without the current branch this is hard because you have a lot of noise in the chatroom. https://blogs.gnome.org/bastian/2015/06/30/smarter-status-hiding/#comment-94 I experimented a bit with a design to meet this usecase, the playground can be found here: https://wiki.gnome.org/Design/Apps/Potential/Polari/UserList (so far its just a first revision) I think the best way to take this further is to do as Simonas suggests: Push the branch and iterate on it from there. For now I'll mark the bug for ui-review, more input on this discussion from other designers are welcome. > Either way, having use the "status-hiding" branch for over 24 hours, I've > completely removed Xchat, a client I've used for over a decade, from my > computer. > > Polari is the simplest, cleanest, most well designed IRC client I've ever > used. You guys put a lot of thought to the design of Polari. Kudos to the > team. Glad you you like it, thanks for the feedback!
(In reply to Bastian Ilsø from comment #9) > I think the best way to take this further is to do as Simonas suggests: Push > the branch and iterate on it from there. No. Until we branch for 3-18, master is supposed to be stable, and this clearly breaks both UI and string freeze. Plus, my main UI concern hasn't been addressed as far as I can see - the grouping just works one-way with no way to get back once it has been "exploded". IMHO this should work more like a revealer, not like a one-time option to show formerly-summarized messages.
(In reply to Florian Müllner from comment #10) > Until we branch for 3-18, master is supposed to be stable, and this > clearly breaks both UI and string freeze. Plus, my main UI concern hasn't > been addressed as far as I can see - the grouping just works one-way with no > way to get back once it has been "exploded". IMHO this should work more like > a revealer, not like a one-time option to show formerly-summarized messages. woops I forgot!
(In reply to Bastian Ilsø from comment #11) > (In reply to Florian Müllner from comment #10) > > IMHO this should work more like > > a revealer, not like a one-time option to show formerly-summarized messages. > > woops I forgot! A note on the implementation: Instead of fiddling with the buffer when showing/hiding status messages, you can use the GtkTextTag:invisible property. If you want to only show either summary or detailed status messages, you can use two different tags and set up a reverse binding; if you want to keep the summary always visible (like the GtkExpander widget), just make clicks toggle the property on the appropriate tag ...
Created attachment 316745 [details] [review] chatView: Emit status if nick has sent messages within 5 mins Only emit status messages if the member has sent a message to the channel within the last 5 minutes. Reduces the amount of visual noise in large chatrooms.
Created attachment 316746 [details] [review] chatView: Compress status messages on idle channels If a channel is idle (no activity in 5 minutes), then display compressed status messages. Clicking on the compressed status message will uncompress it (useful, should the user be waiting for someone specific to chat with).
Attachment 316745 [details] pushed as da0253c - chatView: Emit status if nick has sent messages within 5 mins Attachment 316746 [details] pushed as fc1ab2b - chatView: Compress status messages on idle channels We went over this at the hackfest, and got this into a state we're happy with - so pushing \o/
*** Bug 743951 has been marked as a duplicate of this bug. ***
*** Bug 767716 has been marked as a duplicate of this bug. ***