Yeah, the user list is definitely a problem for larger installations. My current thinking for the Users sidebar is that we need to make a few optimizations for larger installations:

(1) We should allow setting a list of "Buddies" that will always be sorted to the top so that it's easy to keep track of the small group of users you interact with the most.
(2) The filtering when narrowed to a stream that you describe could also have benefits, though it might be kinda annoying for smaller installations, so we'll need to think about the best way to do that.
(3) For very large installations, the buddy list is also the biggest frontend performance issue we have (because it has an inefficient implementation; I don't think fixing this requires any changes to the model).

I know of someone who is working on a similar approach to (1) for the left sidebar streams list (namely, sorting "favorite" streams at the top).

(The sorted-first "buddies" piece would require some new data models but overall should I think be doable for someone new to the codebase).

Just noticed that when you click on a topic, it does add the .faded class to users not in that stream. If it did this at stream level, my enhancement would be pretty straightforward.

The mechanism for fading is that it is triggered when you have the compose box open. It fades the users who won't receive the message you're sending (note that you can be sending to a different stream than you're looking at)

Ahh, that makes more sense.

Another suggestion might be to make the list on the right the list of all users (as it is now) but display a little icon next to each user with whom you are currently engaged in a stream or private message. Moreover, it would really help to see the list of individual users with whom you are having private messages on the left under private messages (similar to how you can expand a stream to see all topics now). In my use case, I am communicating with a large number of users via private message, so being only able to click on the Private Message header makes this cumbersome and difficult find conversations. There could be an X next to each user, so for someone whose private message conversation has ended, you can dismiss them from the list.

@timabbott , I really like the pinned Buddies idea for keeping track of users who you frequently interact with. As an extension of that, what about displaying badges for new private messages with each user in the user list, that way you know that you have 2 new private messages from User A, 5 new private messages from User B, etc. Just clicking on the global Private Messages link is confusing when you have a lot of concurrent conversations.

Cool #285 has an implementation of pinned streams on the left sidebar, which one can look at to get a feel for how this sort of thing might work.

One thing that's being discussed on another issue (I think? Or maybe an email thread) is having "Private Messages" expand to show recent conversations like the invidual streams do -- how do you feel about that concept?

I like the implementation in #285; the only thing that would make it better is to having the ability to "pin" starred streams open (rather than collapsing when they lose focus), so that you can quickly get back to your most active topics without needing to re-expand the stream header (see #292).

Regarding the "Private Messages" expanding to show recent conversations - I think that is a great idea! Again it would be nice if you could "pin" it open so that it does not collapse and hide the individual names. This way, you can easily see all of the users with whom you have private messages, and navigate directly to specific users as desired. Also having an "x" next to each username so you could dismiss conversations that have ended (and that you don't want to wait to be hidden over time) would be useful. This "Private Messages" enhancement is especially if you have a lot of different private messages going on (which is my use case).

In both of these cases, this brings up a good question about notifications. Right now, if I get several notifications in various topics under the same stream, I see a the total number of new messages displayed next to the stream. This is great. However, if I click on the stream to expand it and see which topics have new messages, this number is decremented and thus one of the notifications is lost. Ideally, clicking on a stream header while the stream is collapsed would not decrement this number, so you don't "lose" any notifications. Does this make sense?

Overall I think these ideas are important to ease the transition for people who are used to traditional chat programs (Pidgin, Digsby, Google Talk, etc). If you look at the full-screen version of Zulip on the Zulip Homepage, ideally you could think of the following parts as analogous to traditional chat programs:

• left pane: this is like the tabs or open IM windows to individuals (under Private Messages) and groups (under Streams)
• right pane: this is the "buddy list", showing all possible people you could chat with and their current status (active, away, offline, etc)
• middle pane: this shows the contents of your active chat windows

I think that making the aforementioned enhancements would go a long way to making this transition easier for users coming from these kinds of older chat programs.

Cool, OK, I think we have a concept for what to do here. I'm happy to provide advice on implementation if someone has time to work on this.

My company in China started piloting today with ~20 users, with ~20 more in queue, several different departments and roles involved here (purchasing, research, quotation, manufacturing, R&D, etc).

We needed a more granular control policy, so for now, we've set all the streams private, admin invite only, and asking users to request new streams be made by admin. With this, we noted this users sidebar issue today, and also it is hard to confirm which users are subscribed to the stream, on a quick glance.

Further problem for us with user sidebar:

Ideally we'd have "customer" streams for external users, like [XYZ_customer_Finance stream] and [XYZ_customer_Engineering stream] where only authorized department internal users (like Program Manger, Accounts Receivable Admin) are invited to participate in the relevant customer stream, communicating with customer, exchanging CAD files, quotations, invoices, and such, in the customer streams.

Key barrier now for us is the external customer user could see and private message every internal employee user by clicking on the users sidebar, and vice versa, which risks unauthorized communications. We'd need additional roles on the user and/or user bar settings to eliminate this risk.

Anywhow, I'm searching for some staff talent to hire to drive this and a few other webapp intiatives this year. We'll certainly contribute back as can.

Intresting, thanks for all the info @Smewp. Your external users concept is an interesting use case; would you mind making a separate GitHub issue for making that use case work? While it would touch the same code/UX area, I think likely a solution for that would probably be quite separate from solving the problem of large teams needing to be able to filter for the people they care about the status of, which I think is the main thrust of this ticket.

As a start to this enhancement, what about first just allowing users to pin favorite users in the "Users" list on the right to the top?

@asmartin yep that was what I was thinking as an initial implementation here as well. There's code for doing something similar for the streams list in #285, and I think this feature could work similarly to that.

@timabbott For each user, his favorite users can be stored in his user profile, as a string of comma separated user-ids. For adding new users to the list, the string can be appended and for removing, the string can searched and reduced. Would this implementation work efficiently?

Sorry for the slow reply; I would store these in a separate table that has pairs of users.

The performance issue for large teams is at this point resolved; we still probably want to build a buddy list feature for UX improvement purposes. I'm crossing this off as a completed roadmap project at this time, but not closing this issue until we have time to rewrite the description.

Just noting that #850 and its updated version #3317 are things one should look at before working on this.

@timabbott Can we show only Subscribed Stream Users in the Right Pane?
We do not want to show all the Organization list to a member.

Is there any Way?

Our current plan is #21285; we can consider what to do with this issue once it is completed.

#20870 should help address some of the problems described here as well.

#21285 and #20870 have been completed, and I think they cover the use cases described here.