Display a Google Doc alongside a Riff Video Chat

[jaedoucette]

Describe the ideal solution or feature request

As a user, I want to be able to view and anonymously edit a Google doc positioned alongside a Riff video chat instance, so that I can talk about the contents of the document with my colleagues while still being able to look at them.

This story assumes that the card "Dense Video Layout in Riff Video Chat Meetings" (Zenhub #130) has been completed. That card frees up approximately half the screen real-estate for display of this document.

As with other stories in this epic, it is more important to produce a stable and working version of this feature quickly than it is to make a highly maintainable and extensible version. The exception to this is that a future feature will require the ability to load and display a specifically named document, rather than a hard-coded document, likely with a dynamically computed name.

A Google doc should be loaded alongside the regular Riff video chat. It should be arranged to fill all screen real estate to the right of the grid layout of video streams, separated from the streams with a strip of the same width as the strips separating the video streams from each other. The top and bottom of the doc should be square with the top and bottom of the video stream area. This mockup shows the desired layout: https://docs.google.com/drawings/d/1PgxS7uexQEDXf5TMzoKJTcC4fDx-6iuRb7jkLu7gLZY/edit?usp=sharing

It is fine to load the doc within an iFrame.

It is fine, for the purposes of this story, to load the doc based on a hard-coded document URL.

The loaded doc should be stored within Riff's GDrive. The doc should be created by a user or tester beforehand. It should not require authentication to access (i.e. the user should make it world-editable by anyone who has the link).

All users have views into the same Google Doc, but can autonomously navigate within the doc. That is, two different users can freely look at different parts of the same document at the same time.

Ideally, the doc window is scaled so that there is never a horizontal scroll bar on screens larger than 13'' in size. If this cannot be accomplished, a useful fallback would be to be able to set the margins on the doc programmatically so that the text of the document fits within screen of the participating user with the smallest screen.

Acceptance Criteria:

• [ ] When a meeting is started from a Riffplatform website, a Google doc is displayed. The doc should be created in advance by the tester within Riff's GDrive and set to be editable by anyone with the link.
• [ ] In meetings with 2,3,4, or 5 users, the grid layout of users from Zenhub #130 continues to display correctly. The displayed document is displayed in the same way as participants join and leave. It's size never changes.
• [ ] Up to 5 users are able to simultaneously edit the same document.
• [ ] Users can scroll around the entire document, and view every part of it, exactly as if they were using the Google doc within a small window.
• [ ] If a user leaves a meeting and then returns while the meeting is still going on, they can see and edit the same document that the other participants are still working in.
• [ ] After a meeting has concluded, anyone with the link to the document can visit the document again (note: the document's link does not need to be displayed to users, just that the tester can view the document again by manually opening the document's hard-coded URL). The contents of the document that were edited during the meeting persist when the tester opens the document later.
• [ ] After the meeting has concluded, the shared document is still stored in Riff's GDrive, with a name that we can look up. We can inspect the document by searching for this name and opening the document.

How does this tie into our current product?

This feature will allow the grant experiment to take place. It may or may not be useful for use in our main product in future.

Who asked for this?

John, as part of the grant experiment.

[jaedoucette]

@adonahue @ebporter feedback welcome on this feature.

[adonahue]

@jaedoucette - a couple of thoughts / comments. Happy to chat if you have questions.

• Why is the document name hard-coded? What is the document name based on? I don't understand the thinking behind that, v.s the URL, and why it would be different in this version than as a feature in the product.
• If an (anonymous) user leaves and comes back, will they have a different anonymous animal? Does that matter for the experiment data?
• If users revisit the Doc after the meeting, is it possible for them to delete it? Is that something they can do some other way, and do we need to address (restrict) that?
• I think it's worth specifying in the Acceptance Criteria the user needs to be able to vertically scroll the doc, and have all the functionality they would in a regular Google doc.
• I think it's worth thinking through the steps around document creation, access, location etc. for the purposes of having testable steps that things got created the way we expect, in the place we expect it. For instance, if the code is looking for an existing doc, what name is it looking for? Where? If it doesn't find it, what name and location should it use? Have we decided if that is programmatic or manual?
• I think a little context about the workflow of how a user gets to this point, would be useful in terms of framing what we want to accomplish and why, which can be useful for understanding the goal and intention of the work.

[jaedoucette]

@adonahue

• Why is the document name hard-coded? What is the document name based on? I don't understand the thinking behind that, v.s the URL, and why it would be different in this version than as a feature in the product. -- For this feature, the plan was to hard-code the document name to simplify things. A subsequent feature would address making the document name a function of the Riff room name. If we can't get that second feature, we could probably work with a hard-coded name and still do the experiment.

• If an (anonymous) user leaves and comes back, will they have a different anonymous animal? Does that matter for the experiment data? -- They will. It's not ideal, but from the perspective of the experiment's core objectives, we don't lose anything if this happens.

• If users revisit the Doc after the meeting, is it possible for them to delete it? Is that something they can do some other way, and do we need to address (restrict) that? -- That's a concern, but I think that the users will not be able to delete the doc, just the text that is contained within the doc. Only the owner of the doc can delete it. If users delete the text in the doc, then the doc's versioning feature will make it easy to restore the doc to its previous state.

• I think it's worth specifying in the Acceptance Criteria the user needs to be able to vertically scroll the doc, and have all the functionality they would in a regular Google doc.

• Good point. +1

• I think it's worth thinking through the steps around document creation, access, location etc. for the purposes of having testable steps that things got created the way we expect, in the place we expect it. For instance, if the code is looking for an existing doc, what name is it looking for? Where? If it doesn't find it, what name and location should it use? Have we decided if that is programmatic or manual? -- +1.

• I think a little context about the workflow of how a user gets to this point, would be useful in terms of framing what we want to accomplish and why, which can be useful for understanding the goal and intention of the work. -- Hmm. You mean like a user story for why the user would see a google doc?