Skip to content

Page: Participate In A Mob #2

@dysbulic

Description

@dysbulic

Mockup

Sections

Screenshare

The bulk of the interface is occupied by a screen share of the current Driver's monitor. Currently I am leaning toward a GitHub Codespace because it would let me use secrets in development without having to expose them to all the developers.

The Driver would connect to Live Share running on the Codespace using a local copy of VS Code to do their typing.

Statuses

Mockup

Along the bottom of the screen share would be small windows giving an overview of each coder's status including whether they're typing, what latches they have set, whether they're on break, and any reactions they make.

In addition to the four active coders, there is a window for everyone else, be they watchers, would-be Drivers, or coders cycling in.

Chat

Beside the statuses, there's a chat window to allow asynchronous and silent communication. In addition to being visible to everyone in the room, it should also be possible to message only select members. For example, when sharing the Live Server URL, it needs to go only to the coders and possibly an external Driver.

Similarly, a developer may wish to comment privately on some matter outside of the public record because the chat transcript during the session is to be recorded with future viewers able to evaluate & add to what's there.

Subsequent Pair

Mockup

Above the chat window there is a small element that displays how much of the current percentage hour (“ʜ͋”) remains, who the user thinks should be the next pair to work, & what issue they think they should work on.

There are two lines with the top line being "continue with the current pair", and the bottom being the selection of a new pair & possibly issue.

It should be possible for all the coders to see their compatriots preference as to how the next ʜ͋ should be spent, but ultimately it is up to the manager at that point in time to decide what happens next.

Actions

Mockup

Above the scheduling bit, there are a set of fixed actions which the user can perform. They are:

  • "Raise their hand" to be recognized as wanting to speak without interrupting the current pair.
  • Demark that there is currently a formatting error in the Driver's code. Because of a couple small, but important differences in how Prettier & I think code should be formatted, I don't use it. Coders will have access to a style guide that should cover the vast majority of situations.
  • Mark the private information was just displayed on the screen, and this footage should not be released without some editing. Using Codespaces should mitigate most of these issues, but anything's possible.
  • Recognize that an insight was just had or that a particularly artful piece of code was written.
  • Recognize that an inefficient or buggy piece of code was just entered into the code base.
  • Bring up help describing the use of the interface.

Reactions

Mockup

Coders should be able to silently display their thoughts on the current work through the application of emojis and other icons that briefly display over the video.

Notes

There should be extensive tooltips describing all the functionality.

The initial target is a desktop environment. It will always be difficult for watchers and Navigators to evaluate code displayed on a mobile screen.

Access to bid on positions & to watch the proceedings is token gated.

Metadata

Metadata

Assignees

No one assigned

    Labels

    pagePages on the site

    Type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions