Toast-related components are reusable. They follow React Aria recommendations.
The UI is heavily inspired by GMeet, we should iterate on it.
Why toast? It gives additional information and quick actions when an event
occurs in the room.
The ToastRegion design should be improved to be more extensible, to move away
from poor practices with conditional rendering.
Added initial toast display when users join, with room for further improvement.
Please read the fixme items.
Inspired by the props disableSpeakingIndicator, used the same
logic for all metadata displayed on hover on a participant's tile.
Why? I'll need to render the joining participant tile without any
metadata, so the participant see who is joining the room.
Absolutely needed some toasts to handle in app notifications,
or feedbacks. React Aria is working on it, and has released a
first beta. No component is available, only hooks.
Added user feedback for actions with explicit text indicating
URL will be copied to clipboard. Modeled after Jitsi's button
behavior for clarity and consistency in user experience.
Based on User's feedback.
Having the dialog position visually in the participant tile is
confusing for the user.
Position the dialog to be explicitly outside of a participant
tile container.
Users' feedbacks. Design is inspired from Whereby, a webinars
product. I am not a huge fan of having the indicator on the
left of the participant's name. It causes a shift of the name
when the participant unmute herself.
This should be discussed with the UX designer.
Users's feedbacks. Raised hands in participants' tiles were not
highlighted enough.
It was discussed adding a colorful border around the participant's
tile (idea inspired by Jitsi). Nonetheless, it conflicts with the
current blue border, indicating when a participant is speaking.
Until this blue border is present, it's not a great idea having a
second border indicating a new level of informations.
@sampacoud requested a yellow-ish/colorful indicator of when a
participant raised her hand, inspired by Jitsi. However, I think
yellow color should be reserved for warning or dangerous action.
I chose to use a white background around the participant's name,
to reinforce the visual indication a participant has her hand
raised, while still being discreet. It's inspired by Gmeet.
The Gmeet-inspired indicator was misleading for users,
at least those not used to GSuite products.
They didn't understand how to mute a participant.
Plus, having the button disabled for the local participant,
was creating confusion. To simplify the UX, have all
the buttons enabled is simpler to understand.
Empirical observations with a few number of users, should be
enhance and challenge in the long run.
'hash' built-in function is randomly seed by Python process.
In staging or production, our backend runs over 3 pods, thus 3
Python processes. For a given identity, it was not prompting
the same hash across all pods.
Why 'hash' is randomly seed? For security reasons, there was
a vulnerability disclosure exploiting key collision. Since Python 3.2,
'hash' is by default randomly seed.
Fixed it! Thx @jonathanperret for your help.
Height was varying when muting/unmuting the mic, so I added a minimum height to
avoid layout shift.
Proof of concept for the future UX: a raised hand would be placed on
the left side of the participant's name.
Having the mic indicator and raised hand side by side is temporary and totally
undesired (it feels super weird). I'll refactor the whole UX of the participant
tile in a dedicated PR.
Encapsulate code responsible for toggling hand,
and determining the hand state based on participant metadata.
This gonna be reused across the codebase.
Inspired from Gmeet. Add a button to lower all hands at once.
It should be quite useful for room moderator/admin.
The UX might feel strange, having this action button at the top of
the list, but I could not figure out a better layout. In terms of
UX I feel this is the best we can provide. However, the UI should
definitely be improved.
Show the raised hand waiting list, allow any participant to
lower other participants' hands.
Inspired from Gmeet. I found it quite clear to have a dedicated
waiting list for raised hands.
Will need it for lower hand action.
Actually, this piece of code should be enhanced. It'll act
as a corner stone of all actions dispatched in the interface.
I'll continue refactoring it later on.
Why? This layout is extensible. This menu will have two sections,
to separate in-room participants from the waiting room ones.
It's copied from Gmeet User Experience.
In-room participants will be divided in sub-lists based on their
states (ex: hand raised, …). This User Experience is extensible
if in the future with support subroom in a room or whatever.
Inspired by Magnify. Rely on participant metadata to determine,
if the local user has raised its hand.
There is a todo item in LiveKit code, useLocalParticipant is not
subscribed to metadata updates events.
The contrast of the toggled button in legacy Style is poor,
it needs to be urgently improved. User can barely distinguish if
their hands are raised.
These changes should be discussed. Needed for the audio selects,
that render super long text values.
By default, centered texts are sometime hard to read.
Removed annoying overlay that blocked the user. (feedback from @spaccoud)
Previous design required one click too many. As this dialog doesn't need
an overlay, I couldn't use the default primitive.
It's a hacky but functional, creating technical debt here.
Closer to the Gmeet design. Added a warning about permissions
since the rooms are public in beta.
Apologies @manuhabitela, this may impact accessibility for users unfamiliar
with the copy icon. Let's conduct user testing.
Messy code file organization, but functions are okay. Functional, but not
well-designed and likely hard to maintain. Shipping it, creating technical
debt here. Will be reused for interactions with LiveKit server API.
Participants need to be room admin to interact with LiveKit server
api. Until we offer private room, with moderation, all participants
will be considered as room admin.
note: room admin doesn't offer permission to record a room. please,
refer to LiveKit documentation to learn more.
This commit focuses on the UX more than the code quality. In facts,
we should design a centralized component/alert service, that we
can trigger anywhere in the codebase, when a user is prompted for
confirmation.
The alert modal with cancel/submit buttons and a description is generic.
Creating technical debt here.
Rapidly, a 'more option' button should be added to the row. Thus,
participants will have access to few more actions (ex: remove from
the room, pin camera, etc…).
This flex layout should be definitive, except the code which is dirty,
but not creating much technical debt here.
First raw iteration.
Tried replicating Gmeet UX and layout. However, in their ux, even if
action button are disabled, some tooltips explain to the user why they
cannot perform the action. With the default Trigger, it's not easily
feasible. As soon as the button is disabled, there is no way to trigger
the tooltip in an uncontrolled manner.
In upcoming commits I'll arrange layout, and call the remote LiveKit
ServerApi, to perform the mute action.
Main update: create a component, which has the responsability of
rendering a Participant in the list. I tried gettig closer to a
cleaner codebase, with small and well-scoped components. WIP.
Formatting participants before rendering the list was way to over
complicated, iterating twice on the list was kinda useless. Fixed!
Few updates:
- Removed capitalizing Participant's name to be consistent with the
avatar. This choices mimics GMeet UX.
- Duplicated isLocal utils function from LiveKit, which is not
exported by their package.
Avatar font size was way too small in the participant list context.
I tried improve it. Few font sizing are visually uncomfortable in
the participant list.
oupsy, heavily copied from Gmeet.
Thx Nathan Vasse for his css animation skills, he crushed it.
This component will be core in the app, and reused in many places.
It was necessary for the participants list.
Upgrading Django to 5.1 created a severe issue.
Migrate and create-superuser jobs were failing.
The issue originated from the third party easy_thumbnail.
Please refer to the issue #641 on their repo.
This is the suggested workaround by @Miketsukami.
It explains why participant initials doesn't update when a participant
changes its name.
Similar issue as the one faced while developing on the participant list.
It needs to be fixed at the root, in the LiveKit repo.
Duplicated source from LiveKit internal hooks (not ideal, but necessary)
to ensure the inner content of the participant placeholder consistently
fits its parent container. Unfortunately, I couldn't find
a simpler solution.
This might lead to some performances issues, as for each tile, some js
would be computing avatar's size, which is much more costly than pure
css…
Note: Gmeet achieves this by generating a temporary placeholder image
with a colored background and initials, allowing for a perfectly round,
responsive avatar without relying on JavaScript.
Default 'transparent' value avoid showing the avatar when
participant's info are not yet available. Might be a bad design
if we follow the single responsability pattern. Please feel free
to refactor it.
Color is stored in participant's metadata.
Using a hash of some participant's info allow to persist the color
for logged-in participant without storing the color in db.
Please feel free to tune the saturation and lightness range.
Code is inspired by a tutorial found online.
Inspired by Gmeet animation (mine is far from perfect).
Some details should be improved, especially to have a smooth
animation stop when the user stops speaking.
