Explore visual improvements to displaying audio and video connections within the users list

[tylercopeland]

No description provided.

[tylercopeland]

@antobinary I've explored a variety of different options for improving the way we're displaying audio and video connections within the user's list. For the most part, I kept coming back to our original design with some small updates. I'm going to try my best up outline them below.

You can also access the mockup on InVision using the following URL -> https://invis.io/RDE52214E#/282151978_html5-Sidebar-3

1. Update the avatar colour range - We've received some early feedback on the user's list experience, and for the most part, individuals found it overwhelming seeing all the different colours at once. My recommendation is to dial back the colour range and focus on "blues" and "purples" from our accessible colour palette.

2. Update the avatar size - With bringing the HTML5 designs over to Sketch App, I started using an 8px grid, which has helped a lot with making a clean and consistent interface. In the latest design, the avatar is 40px by 40px.

3. Increase the size of the Audio ring around the current speaker - In the mockup found under #2, you'll see that I've increased the ring around the current speaker (Fred) and the space between the ring and the avatar. On top of the sizing of the indicator, when someone is actively talking, and the ring is enabled, one might find it hard to pick out who's currently talking from the list. Based on research I've done on audio indicators within products - when someone is speaking the indicator pulses instead of just being in an active state (like we see in the html5 client today). If needed, I can create an animation for this indicator.

4. Increase the size of the audio indicator - In the latest mockup, you'll see that I've made some slight adjustments to the audio indicator. These include:

• Sizing. I've outlined the CSS to use below.
  padding: 0.6rem;
  bottom: -10px;
  right: -10px;
  border: 3px solid #F3F6F9;

• Filled versus outlined icon. When displaying an icon at a small size, it's best to use a filled icon. The current outlined icon look blurry.

5. Update avatar style for individuals who haven't joined the audio bridge - We've also received feedback on it being hard to point out who hasn't joined the audio bridge. To make these individuals stand out, I'd like for us to use an outlined avatar. As seen in the mockup above, these individuals clearly standout from the list.

6. Reduce the side of the avatars used in the chat module - This might not be the appropriate place for this, but based on my latest designs I've also reduced the size of the avatar found in the chat messages. The new size is 24px by 24px.

With every iteration, we make great progress and I can't wait to see how these subtle updates impact the experience of the participant's list.

[tylercopeland]

I'd like to add one more item to the list above.

7. Display the presenter as the first person in the participants' list - This will allow the presenter to easily be visible at all times throughout the session.

[oswaldoacauan]

@tylercopeland the sorting of the user-list is something good to think about together with this changes. Currently is:
-> Moderator
-> Emoji (timestamp the user changed the emoji)
-> Phone Users
-> Name

My suggestion is:
-> Presenter
-> Moderator
-> Full Audio
-> Listen Only
-> Phone
-> Name

And if we want to warn the Presenter/Moderators when someone changed their emoji, we could add a Toast or some sort of animation on the user avatar.

[tylercopeland]

@oswaldoacauan some great points here. I like the updated ordering that you're purposing. Grouping participants types together will allow you to glance through the list and know exactly their state.

I also like the idea of leveraging the toast for emojis. But, I think we should be smart about how we're using it. For example, notifying the presenter that someone is happy doesn't hold the same amount of value as someone who is trying to raise their hand to ask a question.

What are your thoughts on this approach?

1 - When someone changes their emoji we provide them with something that's a little more apparent right in the participant's list. For example a pulse effect around the avatar (along with the emoji icon itself). https://codepen.io/search/pens?q=Pulse&limit=all&type=type-pens If we think this to close to the talking visual, then we can have the avatar quickly glow (go from 50% opacity back to 100%).

2 - When a participant changes their emoji to something that should follow with action from the presenter, that's when we can use the notification. For example, when someone is raising their hand to ask a question.

[OZhurbenko]

Currently is:
-> Moderator
-> Emoji (timestamp the user changed the emoji)
-> Phone Users
-> Name

My suggestion is:
-> Presenter
-> Moderator
-> Full Audio
-> Listen Only
-> Phone
-> Name

I don't see how this is better.
Moderator is needed for technical support. And Emoji is needed for classes, Raise Hand feature to be exact.
You shouldn't expect a professor to catch the toast notification while they are going through the study materials, entertaining the class at the same time.

Can you explain why your version is better, @oswaldoacauan ? Is it more important for the professor to see who's in audio, in your opinion?

[oswaldoacauan]

You shouldn't expect a professor to catch the toast notification while they are going through the study materials, entertaining the class at the same time.

And looking into users avatar middle class is expected? In Flash I can understand how someone changing emoji could catch the Presenter attention, but that's not the case for the current implementation on our client, the user-list are completely different experiences on Flash/HTML5.

That's why IMO we could use the user-list sorting to distinguish the user type and audio status (since those are problems reported by real users on the current user-list state) and find a better way to catch the presenter attention when someone change their emoji status.

cc @OZhurbenko

[capilkey]

We used to sort the presenter to the top in the original user list sorting and it was requested to be removed because when you make a viewer the presenter in a large class it caused that person to "disappear" because they were shot to the top. I would suggest not including presenter in the sort because you're just going to reintroduce that behaviour. It's also something that you'd never see in testing and only in a real class scenario.

[OZhurbenko]

And looking into users avatar middle class is expected?

That doesn't have to be in the middle of the class. The prof is lecturing, finishing the speech and looking if anybody has a question on that subject. Based on my experience they don't stop every second to answer the question.

We could make the hand animated potentially in the user list to attract more attention or / and add a hand appear for a presenter somewhere in the nav bar for when the user list is closed and the hand is raised.

we could use the user-list sorting to distinguish the user type and audio status (since those are problems reported by real users on the current user-list state)

What problems?
You still hasn't said a word about the problems you are trying to solve with this changed sorting and why it is better.

[oswaldoacauan]

@OZhurbenko did you actually read what @tylercopeland wrote above?

We've also received feedback on it being hard to point out who hasn't joined the audio bridge. To make these individuals stand out, I'd like for us to use an outlined avatar. As seen in the mockup above, these individuals clearly standout from the list.

People are having a hard time to distinguish users audio state. Having their sort related with current audio status, could help to distinguish and see in a glance who joined and in which state.

That doesn't have to be in the middle of the class. The prof is lecturing, finishing the speech and looking if anybody has a question on that subject. Based on my experience they don't stop every second to answer the question.

In that use case, having the users with raised hand on top changes absolutely nothing, since the presenter will be looking at chat/user-list looking for questions

[OZhurbenko]

Super small icons for audio statuses are definitely an issue.
Are you saying that presenters will have to scroll the user list / check the chat (potentially locked) to find if anybody has a question? That's the solution, @oswaldoacauan ?

[oswaldoacauan]

@OZhurbenko Not really, that's why I suggested the toasts in the first place, but after the point you made above their clearly dont cover that case, unless we disable autoHide for those toasts.

[tylercopeland]

@OZhurbenko I don't see there being any harm in grouping participants by types. I'm not sure how complex this would be, but if it's relatively easy, I think it would be a fun experiment. I can design a whole bunch of screens, but it's until we're able to use it where we can see if it's the right approach.

You shouldn't expect a professor to catch the toast notification while they are going through the study materials, entertaining the class at the same time.

The thinking for this would be to provide awareness to the presenter sooner rather than later. I've personally done presentations where I didn't catch the hand being raised in the user's list or the question in the public chat. I was engaged in presenting to the group. If I were notified in a way that was more visible like a notification, I would have stopped and addressed the questions before I went too far along. I'll be conducting usability tests with teachers soon, and I'll make sure to gather some further insights on whether or not this feature would improve the experience.

In addition to this, having the "raise hand" emoji appear as a notification will improve the experience of presenting on mobile devices. Right now, there is no possible way a presenter would know if there are questions unless that individual asked the question through audio, or the presenter knew to toggle between the chat group and presentation.

@OZhurbenko what are your thoughts on the best approach moving forward?

We used to sort the presenter to the top in the original user list sorting, and it was requested to be removed because when you make a viewer the presenter in a large class, it caused that person to "disappear" because they were shot to the top.

@capilkey do you remember where this feedback came from? I thought the original idea was great and made a lot of sense, even if a participant was visually moving up. It meant that at all times we could look at a specific area of the screen and know who's currently presenting. In the current implementation, if we were in a classroom for 25+ participants and we assigned someone who's "under the fold" presenter status, some might not know who's currently presenting. They would have to scroll down the participant's list to know who that person was. I'm thinking out loud as I'm typing this message, so maybe we could find another place in the interface to display who's currently presenting, perhaps somewhere near the presentation? Anyways, looking forward to hearing further thoughts.

[capilkey]

I was asked to change it by Fred. I think it was because he was sitting in meetings and he saw people getting confused. It was a few years ago. On Mar 19, 2018 4:15 PM, "Tyler Copeland" <notifications@github.com> wrote: @OZhurbenko <https://github.com/ozhurbenko> I don't see there being any harm in grouping participants by types. I'm not sure how complex this would be, but if it's relatively easy, I think it would be a fun experiment. I can design a whole bunch of screens, but it's until we're able to use it where we can see if it's the right approach. You shouldn't expect a professor to catch the toast notification while they are going through the study materials, entertaining the class at the same time. The thinking for this would be to provide awareness to the presenter sooner rather than later. I've personally done presentations where I didn't catch the hand being raised in the user's list or the question in the public chat. I was engaged in presenting to the group. If I were notified in a way that was more visible like a notification, I would have stopped and addressed the questions before I went too far along. I'll be conducting usability tests with teachers soon, and I'll make sure to gather some further insights on whether or not this feature would improve the experience. In addition to this, having the "raise hand" emoji appear as a notification will improve the experience of presenting on mobile devices. Right now, there is no possible way a presenter would know if there are questions unless that individual asked the question through audio, or the presenter knew to toggle between the chat group and presentation. @OZhurbenko <https://github.com/ozhurbenko> what are your thoughts on the best approach moving forward? We used to sort the presenter to the top in the original user list sorting, and it was requested to be removed because when you make a viewer the presenter in a large class, it caused that person to "disappear" because they were shot to the top. @capilkey <https://github.com/capilkey> do you remember where this feedback came from? I thought the original idea was great and made a lot of sense, even if a participant was visually moving up. It meant that at all times we could look at a specific area of the screen and know who's currently presenting. In the current implementation, if we were in a classroom for 25+ participants and we assigned someone who's "under the fold" presenter status, some might not know who's currently presenting. They would have to scroll down the participant's list to know who that person was. I'm thinking out loud as I'm typing this message, so maybe we could find another place in the interface to display who's currently presenting, perhaps somewhere near the presentation? Anyways, looking forward to hearing further thoughts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5035 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVJkl9s3b_WXP2S3DatGdxVzm_WMISqks5tgBHJgaJpZM4Rtde6> .