Improved Threads in Chat

[Adam-Draayer]

Threads in WebEx chats is....lackluster.

There are a few core problems:

1. them being 'in line' with the rest of the chat makes the threads get in the way of the rest of the chat. I'd prefer some kind of 'sidebar' to dock the thread in so it's accessible but not in the way. Similar to the expansion option currently there but instead of expanding vertically add a new side pane with the thread content.

2. Notifications in threads should be based on participants in the thread

3. Updates to threads should be in the left hand nav and differentiated from the rest of the notifications so if there is a response to a thread from hours ago there's a quick 'jump to' the thread with activity on it.

[Jonathan Schulenberg]

You’re welcome to submit feature requests for these but I suggest including a stronger justification than your personal preference. There are a thousand things to do. You need to present a strong argument for why your complete rework of a feature that has been in place for years should preempt other work. Also consider the impact those changes would have on all existing users already accustomed to it.

TBH, it sounds like some of these threads you’re having should just be their own space.

PS- I too believe there are opportunities for improvement in Webex messaging. I’m not claiming it’s perfect, only that I wouldn’t choose to prioritize these requests if I were the product manager. That’s what the Aha portal is for though: Cisco can see how popular a request is and act accordingly.

[Adam-Draayer]

The threads are inside of a development space. I'm the PO for a team of 4 developers. on any given project (the space) we may be discussing a number of work items or features. it doesn't make sense for the to have their own spaces as they are short lived. However, these discussions can include a number of screenshots, and back and forth discussion. By treating threads as a docked right hand pane menu these discussions can happen on the side while other discussions are happening the main thread.

So, for instance, a developer finishes a story, details it in the space, and then asks for feedback. That feedback should be 'threaded' to keep it tied to the initial story completion including the screenshots and work item link. From there making it easier to interact with that thread will make it easier to reply to that specific sub-topic.

As far as the 'aha' portal I'll look into that. I was just trying to get attention to a portion of chat I think could be much better and this was the spot I found.

[Jonathan Schulenberg]

Generally speaking, this is a peer-to-peer support community. The product management teams at Cisco rarely monitor this site - but they do watch the Aha ideas.

Threads are anchored in place chronologically by the message that started the thread. Ongoing general conversation shouldn't be interrupted; the replies will appear farther "back", tied to the original message that started the thread. You have to scroll up (or click on the New Replies button) to see them.

The second of your original three points touches on a very early design decision that, in my personal opinion, is now technical debt limiting other progress: read/unread state is tracked per-space as of a given timestamp. The read state of individual messages are not tracked. If you scroll back to yesterday and mark a message unread, the 'most recent read' timestamp for you in that space is just moved backward to the second prior to the timestamp of that message. Investing the development effort needed to address that is amongst my top wish list items for the messaging workload.

Your third bullet in the original post sounds similar to the Slack Activity tab. You're not the first to ask but it would need individual message read/unread state granularity to be offer a comparable functionality.