Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Tracking] RFC-001: Allow guests to collaborate on multiple remote buffers #268
We intend to implement RFC-001 via a series of pull requests. This will allow developers to start benefiting from the completed RFC-001 functionality without having to wait for all of RFC-001 to be completed. We'll use this issue to track progress.
Refs: #231 (which introduced RFC-001)
I'd like to explore our handling of the host closing a buffer. Currently, I think we're planning on warning hosts when they close buffers while guests are editing. Another option could be to go ahead and remove the editor from the host's workspace, but maintain a reference to the buffer in the host's pool (keep it's ref count above zero). This would allow guests to continue to edit and save the buffer.
One downside of this is that the host might not be aware of continued changes to particular buffers, although as we improve visibility of participant buffers this could be mitigated. I think it could be worth it though, because it prevents the need to prompt the host when closing buffers and could make it easier to bridge to a world where guests can open any file from the host's file system via the fuzzy finder.
Teletype v0.3.0 is now available. It adds support for the first set of enhancements noted in the issue body:
This was referenced
Dec 11, 2017
@simurai: Because other collaborators in the portal might be viewing a different part of the editor than you're viewing, or they might be viewing a completely different editor, we're looking for a way to visually represent where other collaborators are working, and we'd love to hear what you think.
Here's what we have so far:
A. Top-right: Collaborators in the same editor but in a row above your viewport. Clicking on avatar will take you to that collaborator's location and start following them.
B. Middle-right: The collaborator you're currently following (if any). This collaborator is working inside the current viewport. If they move elsewhere in the editor, your editor scrolls accordingly. If they move to a different editor, you follow them to their new editor.
C. Middle-right: Other collaborators in the same editor and inside your viewport. Clicking on avatar start following that collaborator.
D. Bottom-right: Collaborators in the same editor but in a row below your viewport or a column outside of your viewport. Clicking on avatar will take you to that collaborator's location and start following them.
E. Bottom-right: Collaborators in a different editor in the portal. Clicking on avatar will take you to the editor that the collaborator is working in, scroll to their location in that editor, and start following them.
F. (Not Yet Implemented) Bottom-right: Collaborators in a different pane item not associated with the portal. Since the collaborator is working on something that's not part of the portal, you can't click on them to go to their location.
We'd like a way to visually distinguish D, E, and F. Can you share any thoughts you might have on ways to visually represent this distinction?
referenced this issue
Dec 15, 2017
Dec 18, 2017
I have a couple questions re
Because it might be easier to discover what everyone is currently working on by showing all the remote files in the tooltip. Together with the avatars. So you can open files or follow somebody from there.
Read somewhere that the plan is to share the whole project (in the tree-view?). So this might only be a stop-gap.
FWIW, I found the behavior to add all open files to the portal a bit surprising. It may be because my particular workflow is more focused on note taking than on pair programming.
I tend to have a lot of buffers open in Atom. Sometimes I want to pair with someone on a single file and don't want them to see all the others I have open. It's not immediately clear to me when I share a workspace what exactly is being shared. Previous behavior of Teletype lead me to believe it's just the file I'm working on.
And after sharing the file, I might need to work on something unrelated to the pairing session in private. I don't want to accidentally share that file by simply opening it. I think it needs to be crystal clear what's being shared, what's not being shared.
Not to prescribe solutions, but here's one idea in the interest of generating better ideas.
Even that was a bit risky. For example when closing a buffer, the buffer to the left will become active (and shared). Which might show something you didn't intend to share.
And with the fuzzy-finder integration and maybe later the tree-view too, you have to assume that people can find anything in your workspace.
Yeah, that could be an option. As a host, after sharing your workspace, but before telling other people your Portal ID, you could look through your tabs and projects/folders to see if there is anything you want to hide from collaborators.
Although that could be a bit of a chore and anxiety inducing having to think what to exclude every time you want to share your workspace. What about the opposite?
Opt-in (new window)
For people with a lot of secrets, it might be easier to opt-in what to share. I guess you could right-click your current file and then choose "Open In New Window" (although currently it opens all files, which I think is a bug). Then start to share that workspace. Now you're free to add new files and folders as needed.
Or it could be part of the tree-view. Similar to those packages that show opened files:
Then you can add/remove files/folders and have more control what exactly people can see.
Show what gets shared
Could be a list of folders/files, or a warning like:
More prominent "is sharing" mode
Currently only the colored status-bar icon is a reminder that you're currently sharing your workspace. There could be stronger indication, like a border (like when screen sharing in Zoom):
A setting to exclude certain patterns
Matching files/folders will get greyed-out in the tree-view.
Responding to questions from #268 (comment)
The fuzzy-finder shows a maximum of 10 items at a time.
We're using the fuzzy-finder's buffer view (command+b on macOS), which currently shows all your local buffers. With that in mind, if a guest has no local buffers open, and they're collaborating in a single portal, and that portal has 10 or fewer remote files in the portal, then the guest will see a list of all 10 remote files. However, if the guest has several local buffers open, and/or if they're participating in a portal with more than 10 total remote files, and/or if they're participating in multiple portals, there may be more than 10 total buffers available, and the fuzzy finder will only show 10 items at a time.
I don't have any hard data available, but from using Teletype to build Teletype, I can say that we commonly collaborate on 5-20 files in a single collaboration session. Sometimes more.
I think the design in #268 (comment) would struggle to scale to this many files, so I'd love to explore other options. We're currently thinking that the fuzzy-finder would be a good fit, but we're open to other ideas.
UI/UX goals for finding and opening remote files
We think that the UI should satisfy the following goals:
@simurai: Would you be willing to put together some fuzzy-finder mockups that attempt to satisfy those goals? (Note: If you think that something other than the fuzzy-finder would be a better fit for satisfying these goals, definitely let us know.)
Here some ideas:
1. Teletype fuzzy-finder keybinding
Currently the fuzzy-finder has these keybindings:
Teletype could introduce a new modifier key to find remote files, e.g.
Concerns: Yet another keybinding to remember. Could be mitigated by adding some hints/links in the Teletype popup.
2. It's just a (remote) project
Currently Atom allows to add multiple root projects. When joining a portal, it could be treated just like adding another root project. Then if you open the fuzzy-finder it shows local and remote files with a different path. Like
A new root project will appear in the tree-view that can be used to discover files. Remote projects and files get an
Open question: What happens if the host has multiple root projects. Would a guest get all of them added to the tree-view?
2B. with avatars
To make remote projects visually even more distinct, the host's avatar could be used instead of the
3. custom panel
Teletype could have its own panel in a dock. With a buddy list. After joining a portal, you can drill down and open a file filter/browser:
Personal opinion: Option 3 could be slick because everything is custom made and optimized for this use-case. At the same time it feels less integrated and more like "tacked on". Therefore I would give option 2 a try first by reusing existing ways (fuzzy-finder, tree-view).
Some people probably don't like having local and remote projects mixed. In that case they can open a new (empty) window before joining a portal. Then everything is separated and the local project stays untouched.
This was referenced
Feb 7, 2018
Thank you, @simurai!
With #323, we're pursuing the option you described in 2B:
Regarding the tree-view integration:
We're focused on the fuzzy-finder integration for this initial implementation, but I like the idea of also integrating with the tree-view. We'll keep that in mind as a future enhancement.