search

zinc-collective / convene

An Operating System for the Solidarity Economy
https://convene.zinc.coop
Other
56 stars 19 forks source link

Room Occupant may take a Seat at a Breakout Table #155

Closed zspencer closed 3 years ago

zspencer commented 3 years ago

https://github.com/zinc-collective/convene/issues/154

anaulin commented 3 years ago

The direction this is going in makes sense to me, but it feels like it needs more to flesh out the fine detail of the interactions / data flow.

Quick thoughts after looking through the diff:

zspencer commented 3 years ago

Re: What's the connection between BreakoutRoom and Furniture? I don't see any connections between the models in this PR, but I would expect BreakoutRoom to be a type of Furniture in some way?

I'm not sure yet; my gut agrees with you that a BreakoutRoom is likely a kind of furniture; and whether we go with Furniture as a Mixin type inheritance or Parent Child will depend on what makes sense when we have several types of furniture.

Re: Related to the point above, I don't see changes to schema.rb -- seems like that is missing from the PR.

Yep, I'm "coding by wishful thinking" here and sketching very lightly and not including some of the details that would make this code "work"; more trying to play with how the different objects interact.

Re: Having a different partial for each type of Furniture to render it in the UI makes sense to me at first glance.

:+1:

Re: How will we handle e.g. creating a BreakoutRoom? Is that a different furniture-type-specific partial to create/edit?

Hmmm, my preference would be for the piece of furniture to fully encapsulate it's data-model. I.e. the BreakoutRooms furniture would hold responsibility for deciding who is allowed to perform what CRUD operations on it's internal state based upon the rights the person has within the room. I need to noodle a bit more on how the interface for that would work; and a 0.1 version of BreakoutRooms may not have that degree of control.

zspencer commented 3 years ago

@anaulin / @user512 - Made a bit more progress on this, some of which probably wants to be it's own PR to reduce noise (Grouping the scopes with the fields they're querying in the room model; for instance...)

There's also some work still to be done before I feel confident that it's worth trying to build a second kind of furniture with; but it feels like it's getting into a bit better shape...

Thoughts?

anaulin commented 3 years ago

@zspencer this direction makes sense to me, and it is nice to see it start to take shape!

To me it makes sense to get something like this checked in, and use it to get ourselves to play with "Tables" and iterating on them as needed. Later we can refine things to support more than one type of architecture, incorporating whatever we learn from "Tables".

(From a product standpoint, users are used to "Breakout Rooms" as terminology, so maybe we can call ours "Breakout Tables" or something like that? Otherwise I fear that if we call them externally "Tables" that would just be confusing to folks.)

zspencer commented 3 years ago

I'm a bit torn. I feel like "Breakout Tables" breaks the skeuomorphic mental model of the "Rent a Space, Lay it out with Rooms, add Furniture" framing that I'm using in the customer/contributor-development cycle. People don't Breakout to a Table, we "Find a Seat." Maybe it works with "Find a Seat at a Breakout Table."

Are there things you think it "wants" before we merge? I am kind of hesitant to merge it as-is; but maybe it's OK since there aren't any Spaces with Rooms that have Tables yet?

user512 commented 3 years ago

I think table is fine and potentially is a good term if we foresee other furniture will be added in the future and I like the idea of getting this checked in and change if we have stronger feeling to change later.

Realtime! When someone creates a breakout room; we want Guests to see that become available right away.

We can look into using Turbo, where someone created a table, the app would stream partial page updates over websocket. I haven't try using this library but by watching this demo, it seems promising.

How do we kick people out of the breakout room when they expire?

Implement some JS to check if the room is expired every few minutes and redirect people if room is expired.

anaulin commented 3 years ago

I don't have super strong feelings on naming, but to clarify that above I was proposing something like "Breakout Tables", kinda splitting the difference (not "Breakout Rooms", as "Rooms" would be confusing in various ways in our model).

zspencer commented 3 years ago

That makes sense, had a bit of a brain-fart! Updated to BreakoutTables and added in specs for the FurniturePlacement class; as well as fixed the breakages in the feature tests.