Distinguishing between users [from question in RFC-001]

[IbisLiven]

Some ways I can think of to distinguish between people are size and saturation.
You could add a grey overlay to contributors outside of portal.
You could make all contributors outside the current file smaller and in a fourth row.
like this (I also included my enchancement for tab icons #275 ):

(I didn't wan't to clutter #268 so I made my own issue with advice)

[simurai]

You could add a grey overlay to contributors outside of portal.

👍 That's a great suggestion. That could also be used in the tooltip. So in the case below, you can see that I joined the portal, but am not actively viewing any of the portal's buffers/files.

Also, the active avatars could be clickable. So as a fallback, I can always go to the tooltip to follow somebody.

For the avatars in the buffer, I wonder if they should be more compact to minimize jumping. I'll try mock up something.

[simurai]

Here a version where the avatars are together. There is a filled background to show who is in view and who is above or below:

A	B

So as long as people don't join or leave a buffer, the box doesn't move or resize, just the in-view selection. And the avatars swap places. This might be less distracting than having avatars jump to the top/bottom?

Not sure where to show E + F from #268 (comment). Maybe they could just be at the bottom, separated and not part of the buffer group:

Is that enough clear? Or do people working on other files or projects even need to be shown here? They could only be shown in the tooltip? Like once you stop following somebody and drift off for a while and then wonder what they are doing, you could open the tooltip and click on the avatar to start following again.

The tooltip could also show more information. Like the file names that currently people have open and the avatars next to it. I can mock that up next week.

[IbisLiven]

I think this sidebar is a good idea: everything is in one place and there's less guesswork as to why the icons are moving around all over the place. the grey bar is also reminiscent of how a minimap works which might be a more familiar way to communicate who is above/with/below you in the file.

I agree that the sidebar looks cleaner when you're not showing a group of people outside the file (and it reinforces the meaning of it: that these are the people in this file and where they are). the little line works nicely here to separate them, but I'm concerned with what happens when there is more than one line of avatars.

maybe if we aren't showing them in the file, there could be a number badge on the teletype icon to show the number of participants in the portal. (and if you like my tabs icon enhancement: there could be badges on each tab too to show the number of people in each file)

they're a bit small as badges, so maybe beside the icon?

[nathansobo]

After mulling this over, I want to clarify the role that these avatars need to play in the UI:

• They indicate who else is present in the shared workspace.
• They give users an affordance to jump to the location of other users.
• They could provide a legend that ties visible cursors to individuals.

What do people think about the following proposal?

• Always display avatars stacked in the lower right corner of the screen.
• For any avatar corresponding to a visible cursor, give the avatar a colored border matching the color of the cursor. Avatars that don't correspond to a visible cursor won't get a border.
• When hovering over an avatar, indicate the user name, file, and line number, and maybe a call to action... Follow @as-cii to foobar.cpp:34.

If a collaborator's cursor isn't visible, I'm not sure how much it matters where they are. I just want to click them to go to their location, but I don't need to see avatars positioned in any particular way.

I'm also not sure we need the extra chrome around the avatars. What about just stacking them up and using the colored borders to indicate visibility? I can see the chrome adding some visual cohesion, but I think if we consistently stack avatars in a specific location and keep things fairly stable, we could be ok.

I think it's more important to provide a reliable affordance of jumping to the location of other collaborators than it is to accurately depict the location of collaborators in the current file. So I think all collaborators should always be listed in a stable order, up to some reasonable limit.

[simurai]

@IbisLiven maybe if we aren't showing them in the file, there could be a number badge on the teletype icon to show the number of participants in the portal.

💯 Totally. Could be current file/total like 🗼 5/8. So you know there must be 3 more swirling around.

@IbisLiven and if you like my tabs icon enhancement

Tabs are a bit tricky, because every theme styles them differently. Like some have the close icon on the left which then would clash with the Teletype icon. Hmm.. Maybe if we can add it part of the file name? 🤔

@nathansobo Always display avatars stacked in the lower right corner of the screen.
@nathansobo For any avatar corresponding to a visible cursor, give the avatar a colored border matching the color of the cursor. Avatars that don't correspond to a visible cursor won't get a border.

👍 I like the simplification and added legend.

Something that came to mind. Could it be annoying if the avatars cover code you want to read/edit? You would have to first scroll down to reveal the code underneath. There is also a chance you can't scroll if there is not enough code and "scroll past end" isn't enabled. Might not happen that often, but if it happens, could be quite frustrating. So with that in mind, an alternative would be to show the avatars in a top or bottom "bar"?

[simurai]

Here a top bar. It could also have other stuff, like the "Leave" button.

I think this would be great if there are always many people, but a bit overkill when only doing pair programming and only showing a single avatar. So back to the bottom right, but laid out horizontally:

Then to not cover the last few lines when "scroll past end" is disabled, there would be a fixed padding so you can always "scroll past the avatars".

[nathansobo]

I still like them stacked vertically, but a horizontal layout may be better with respect to obscuring code. We could apply the same "scroll past avatars" concept in the horizontal direction, but it would be weird with soft-wrapped files, which should never scroll horizontally.

My vote is for the horizontal layout you pictured above with the colored borders and stable locations, plus tooltips on hover.

[jasonrudolph]

Could it be annoying if the avatars cover code you want to read/edit?

@simurai: Yes. We're tracking that as the lone remaining task in #155. I'm intrigued by the idea you shared in #286 (comment):

Then to not cover the last few lines when "scroll past end" is disabled, there would be a fixed padding so you can always "scroll past the avatars".

[simurai]

Should we already think about scaling? Like what if there are dozens of people in the same buffer?

A simple option would be to just start filling up from right to left with an overlflow: hidden on the container. So you would see the first 10-15 depending on your pane size.

---

Then if we wanna add a way to see all, we could do it similarly to Google Docs. There it's capped at 7 avatars and then shows a dropdown that you can click to see a list of all users.

In the Teletype package it could be like:

Or clicking the +17 button, could open the status-bar tooltip where the other avatars are shown too.

[simurai]

Another thought about "stable locations". Maybe the order of the avatars should be based on activity? Since you use the avatars to start following people, you're only interested in the ones that are actively typing and not the ones that are watching or went to lunch break. The order doesn't have to update in real-time, maybe just once a minute should be fine.

[jasonrudolph]

Should we already think about scaling? Like what if there are dozens of people in the same buffer?

So far, we chosen to optimize for Teletype's primary use case: Developers collaborating closely with each other to edit code together in real time. Given that effectively editing code together in real time requires everyone to have a shared understanding of the goal, social constraints and communication constraints are likely going to limit the number of developers that you want to collaborate with simultaneously. Real world Teletype usage seems to support this theory:

With that in mind, I recommend that we continue to optimize the UI for portals that have just a few participants. I recommend that we limit the amount of effort that we invest in designing/developing/maintaining UI for portals that have a large number of participants.

... if we wanna add a way to see all, we could do it similarly to Google Docs. There it's capped at 7 avatars and then shows a dropdown that you can click to see a list of all users.

I've often wondered why Google Docs chooses to display large lists of participants. If there are 1,000 participants in a document, what use case is served by showing the user a list of all 1,000 participants? 🤔

I wonder the same thing for Teletype. A list of avatars and usernames is a solution, but I'm not sure what problem problem it's attempting to solve. What do y'all think?

[simurai]

@jasonrudolph Thanks for digging up the numbers. ❤️

I wonder the same thing for Teletype. A list of avatars and usernames is a solution, but I'm not sure what problem problem it's attempting to solve.

Hmmm.. yeah, I can't think of a practical reason with 1000s of participants. At that point it's like pushing to a public repo where anyone could see the code. For under a few dozens it might satisfies your curiosity, knowing who joined? And it gives you a sense of privacy. Like "ohh.. great, the boss finally left". 😂

Anyways, based on the numbers, we can keep the scaling question low priority and come back to once it's a problem.

[jasonrudolph]

#332 incorporates the results of this discussion.

Thanks @IbisLiven and @simurai! 🙇