šŸ†• Multiplayer Mode in Public Preview

Announcements
22

Itā€™s very important, as if we are using the same user, it means we both write to the same user-specific columns and could override each other. Itā€™s especially important for QA sessions

2 Likes
23

Thank you for this feature!!! Itā€™s made a world of difference for our daily operations and development efforts.

1 Like
24

My favorite hack is having the data editor open at the same time as the builder:

  1. Copy the builder URL (usually ends in /layout)
  2. Open a new window and paste the URL
  3. Change the end path of the url to /data
7 Likes
25

It took a reply on LinkedIn from David (CEO) for me to realize that multiplayer mode offers the hidden benefit of allowing 2 windows, one for layout and one for data editing.

This is an important feature in a world where most people have multiple screens at work. I want to make the point that I think it is completely lost in the feature name: Multiplayer. After all, using multiple screens has nothing to do with multiple users. Even Robert calls it a hack. I ignored the multiple player announcement because it didnā€™t seem relevant. Iā€™m convinced this applies to most users (as ever Jeff was smart enough to spot the utility).

@Glide perhaps you need to be more deliberate about communicating the user has the option to open the editor view in a new tab. This would drive awareness of a very useful feature.

26

Hey Simon :waving_hand: Your post got me thinking.

I know of the new feature and yet I never use it, it got me wondering why.

I think there are two main use cases for the feature:

  1. one person with multiple tabs/windows open (for example for the data and layout editor respectively,
  2. and two people working independently on different parts of the application (for instance in the data editor and in the layout editor)

The naming of the feature suggests to me collaboration is the main object of the feature. One question Iā€™ve had and which I donā€™t have an answer to is what happens if the same space (layout editor for instance, or data editor for instance) end up open in different tabs/windows at the same time and they get worked on? Which version ends up being saved? This scenario can easily happen whether we are in use case 1 or 2.

(Nota bene: I feel that ā€œmultibuilder" might have been more descriptive naming than "multiplayerā€ if indeed the main purpose of this feature is collaboration.)

Another question: use case 1 is useful mainly because when switching between the layout editor and the data editor, the data editor ā€œresets" every time we switch back to it, that is the developer needs to select the table and scroll to the column he was working on. To me, the multiplayer feature in this specific instance addresses the problem but doesnā€™t solve it, which is the data editor resetting.

So in the end, though I like the multiplayer feature in theory, I feel like it doesnā€™t solve the right problems adequately. And no matter the scenario, I donā€™t understand how versions are handle, which has made me shy away from using the feature.

Or perhaps it functions differently than what I assume?

1 Like
27
  1. Having the same App open in a second window to use as a reference. I do this a lot, it saves me making throwaway copies of Apps.

My expectation would be that last one in wins, in a similar way to what happens if multiple App users change the same data at the same time.

1 Like
28

This 3rd edit-view use case makes sense to me: one window is actively worked on (edit), the other is referenced perhaps as an example (view only). Then we donā€™t have any version conflicts. My user cases 1 and 2 were edit-edit scenarios where I see potentiel for version conflicts.

Thanks for this, mental bookmark :memo:

(If your use case 3 really is the only viable one, then I would call the feature Reference Builder or Building Reference, even though these names donā€™t sound exciting.)

1 Like