Mockup to unify the users and listeners window: feedback welcome

397 views
Skip to first unread message

Fred Dixon

unread,
Oct 11, 2012, 1:52:12 PM10/11/12
to BigBlueButton-dev
One of the items on our road map is to unify the users and listeners window


We've been doing a lot of work on the BigBlueButton client this release with adding the text tool to the whiteboard, layout manager, and lots of other small UI updates.  

We expect that +95% of the use cases in BigBlueButton are not using the dial-in numbers, which means the separate of users and listeners is duplicating the list of users.  We're been experimenting with a UI design that unifys them.  See


Inline image 1

If a user does dial in, the phone number would appear at the bottom of the list. We wouldn't make any attempt to unify the incoming phone number with the user (i.e. dynamically assign pins).

We're interested in your feedback on the above UI mockup for unifying the users and listeners.

Regards,... Fred


--
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton

image.png

Chad Pilkey

unread,
Oct 11, 2012, 2:05:53 PM10/11/12
to bigblueb...@googlegroups.com
Is there no more button to mute and unmute yourself? Or do you have to select yourself and then click the settings and then the option to mute selected user.

Calvin Walton

unread,
Oct 11, 2012, 6:49:50 PM10/11/12
to bigblueb...@googlegroups.com
On Thu, 2012-10-11 at 11:05 -0700, Chad Pilkey wrote:
> On Thursday, October 11, 2012 1:52:49 PM UTC-4, Fred Dixon wrote:
> >
> > One of the items on our road map is to unify the users and listeners window
> >
> >
> > http://code.google.com/p/bigbluebutton/wiki/RoadMap1dot0#Unify_the_Users_and_Listeners_window
> Is there no more button to mute and unmute yourself? Or do you have to
> select yourself and then click the settings and then the option to mute
> selected user.

The intention is that you can simply click the "speaker" icon beside
your own name to mute/unmute yourself. This does make it a bit more
complicated than it is now, because it means you must first find
yourself in the user list. If this turns out to be a problem, it might
be possible to put back a mute/unmute control for your own audio.

--
Calvin Walton <calvin...@kepstin.ca>
BigBlueButton Developer

Dave Arnold

unread,
Oct 11, 2012, 8:20:39 PM10/11/12
to bigblueb...@googlegroups.com
I must be in that 5%-  that uses the dial in number. I think this looks great. I'd like to see what it looks like with a mix of dial-in and microphone users. I'd be happy to test.

Stéphane Lux

unread,
Oct 12, 2012, 1:27:41 AM10/12/12
to bigblueb...@googlegroups.com
Hi Fred,

I would love to have this feature and like the mockup. 

Have you already started implementing it?

Regards,
Stéphane

HostBBB.com

unread,
Oct 12, 2012, 6:24:29 AM10/12/12
to BigBlueButton-dev
Fred, like the new design.

Could you allow the join api call to have optional calleridmatch=
param, the business app when joining user could add this to user map
so incoming sip/skype calls can be linked.

Then anytime a sip call makes it into conference, you could map the
user to dialin.

for i.e. calleridmatch =2072341234 would map to a user, so if this
number call in it links to right user.

Also when i setup skype to call in to freeswitch i get
callerid=stephen_dame, so this will map a skype call to the user
window.

If no match is found, just add to end of list as unknown user.

This way, anyone wanting to do enterprise integration with BBB has the
tools, provided they add business logic. I have one customer that has
integrated cisco call manager across a 600 person organization. In
this case they would map calleridmatch=(ciscoextension)

Think this would make seemless and allow for unification of listener/
user, and extend system for the 5%. Really need to preserve the
freeswitch integration.

If you need help testing this let me know, i can configure freeswitch
for all the use cases and provide dids.

Regards,
Stephen
hostbbb.com

On Oct 12, 1:27 am, Stéphane Lux <steph...@lux.io> wrote:
> Hi Fred,
>
> I would love to have this feature and like the mockup.
>
> Have you already started implementing it?
>
> Regards,
> Stéphane
>
> Am Donnerstag, 11. Oktober 2012 19:52:49 UTC+2 schrieb Fred Dixon:
>
>
>
>
>
> > One of the items on our road map is to unify the users and listeners window
>
> >http://code.google.com/p/bigbluebutton/wiki/RoadMap1dot0#Unify_the_Us...

Séverin TERRIER

unread,
Oct 12, 2012, 9:41:04 AM10/12/12
to bigblueb...@googlegroups.com
Yes, it seems very cool :-)

Hope to see this soon in BigBlueButton.
... and will then just have to redo our screen copy and documentations ;-)

Séverin

Chad Pilkey

unread,
Oct 12, 2012, 10:59:33 AM10/12/12
to bigblueb...@googlegroups.com
Calvin,

Thanks for clarifying that it's still easily accessible. I didn't realize when just looking at it that you can click on the speaker icon.

Chad

Fred Dixon

unread,
Oct 12, 2012, 9:49:23 PM10/12/12
to bigblueb...@googlegroups.com
Hi Stephen,

Good suggestion.  We'll add this property to the joinURL, calling it simply callerid, as in

   &callerid=6133423434

and implement the logic you described.  Updated the issue


with the details.

There is an edge case: a user might already be joined through the build-in VoIP *and* dial in as well with a matching caller ID.  In that scenario, we'd have to mute *both* streams if the user clicks the mute button, but that circumstance will be very rare.

Regards,... Fred
-- 
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton



--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To post to this group, send email to bigblueb...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.






Fred Dixon

unread,
Oct 12, 2012, 10:09:56 PM10/12/12
to bigblueb...@googlegroups.com
We've been working on more refinements of the user interface for the participant's window.  Attached are two more UI mockups: one for the view by moderator, the other for viewer.

First off, the list is sorted by moderators at the top.  The icon next to a user's name indicated whether they are moderator, presenter, or raising their hand.  Only viewers (non-moderators) can raise their hand.

For the media, a speaker icon appears next to each user's name as they are talking.  If a user shares a webcam, a webcam icon appears next to their name.  All speakers have a microphone icon that will have a slash through it if they are muted.


This first mockup shows viewer's controls.

Inline image 1

For the viewer, they would have the ability to raise their hand and mute/unmute themselves. 


This mockup shows the moderator's controls:

Inline image 2


For a moderator, they would have the ability to
  - make use presenter
  - Lower all hands

They could eject a user from the session (disconnect both on-line and audio), by clicking the 'x' icon next to their name, which appears when they hover over their name in the window.

They would have the ability to mute/unmute themselves, but that button would also have a drop-down menu with additional capabilities:
  - Mute all 
  - Mute all (except selected)

Scenario 1: Start of class
A moderator could select themselves (and perhaps the presenter) and then click the 'Mute all (excepted selected)' and start the lecture.

Scenario 2: Break during lecture
So a clicking the 'Mute all' button would mute everyone (including themselves) -- good for those breaks during a lecture. When returning from break, the moderator could click their mute/unmute button to active their audio again.


You'll note two aspects of this new design.

1.  We've removed the lock icons, which was a mechanism in 0.80 to
  (a) mute all (except locked)
  (b) prevent a viewer from unmuting themselves

In almost all classes we've participated in, we've never seen a moderator lock a viewer so they couldn't umute themselves.  We suspect that while people may like this feature (it's there in case I needed it), the presence and functions of the lock icons are not self-evident, most never use them because they either (a) don't understand their purpose or (b) have no need for them.  

We feel removing them will simplify the user experience, and anytime we can simply the user experience in BigBlueButton, we're headed in the right direction.
 

2.  There is no way to set new users as being muted by default

This is a feature to ensure that latecomers to the session don't disrupt the audio.  We could resolve this by adding a third control to the to the moderator's drop-down menu for audio 

  - [  ]  Automatically mute new users

This one would have state, so the moderator could enable/disable this mode.


Feedback welcome.

image.png
image.png

HostBBB.com

unread,
Oct 14, 2012, 1:00:52 PM10/14/12
to BigBlueButton-dev
Fred, looks good... The moderator image, has the word "expect",
think it should be except in case you didnt see that yet.

stephen
> BigBlueButton Developerhttp://bigbluebutton.org/http://code.google.com/p/bigbluebutton
> BigBlueButton on twitter: @bigbluebutton
>
>  image.png
> 44KViewDownload
>
>  image.png
> 89KViewDownload

Séverin TERRIER

unread,
Oct 17, 2012, 10:04:12 AM10/17/12
to bigblueb...@googlegroups.com
Fred, it looks very nice :-)

Don't hesitate, when it will be more advanced, to tell me where and how to translate strings (still Gengo.com ?), to have it all well translated in french.

Séverin

Andrew Ensley

unread,
Oct 19, 2012, 6:11:06 PM10/19/12
to bigblueb...@googlegroups.com
Fantastic. I love it.

Stéphane Lux

unread,
Nov 1, 2012, 5:08:39 PM11/1/12
to bigblueb...@googlegroups.com
Hi,

have you already stated coding this?

Best regards,
Stéphane

Fred Dixon

unread,
Nov 1, 2012, 5:15:35 PM11/1/12
to BigBlueButton-dev
Hi Stéphane,

Not yet, but we're getting close ... we expect to start the unification work within a week.

Regards,... Fred


--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/-NZkJI5p8OkJ.

To post to this group, send email to bigblueb...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.

webdev

unread,
Nov 12, 2012, 12:26:11 PM11/12/12
to bigblueb...@googlegroups.com

hi fred,

when we can get this update sir

Richard Alam

unread,
Nov 12, 2012, 12:37:40 PM11/12/12
to BigBlueButton-dev
On Mon, Nov 12, 2012 at 12:26 PM, webdev <gvenkat...@gmail.com> wrote:

hi fred,

when we can get this update sir

I'm working on it as part of a bigger change. Look for an update in the next couple of weeks.
 
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/je4o6IuhN_oJ.

To post to this group, send email to bigblueb...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.

Andy

unread,
Jan 24, 2013, 4:51:53 PM1/24/13
to bigblueb...@googlegroups.com

Hi Fred,


The mockups look excellent - great design. I love the unified users and listeners.


I have one suggestion about the icons in the top bar (the buttons used to turn on audio and webcam). Currently in BBB (0.8) turning on the audio causes the headset icon to gain a "red cross icon". This is because the "cross" indicates that clicking the button will turn audio "off".


However, we're finding that a lot of users (particularly younger users) are confused by this, as they assume that the icon represents the "current state" of the audio - i.e. a "red cross" would indicate that "audio is off". The other issue is that a red cross icon is synonymous with an error, which causes new users to "click the cross" to investigate the error, thus turning off their audio.


In your new UI mockup you've used a green tick to represent "click here to turn audio on", and red cross to represent "click here to turn audio off". However, this is going to be misinterpreted as "green tick means audio is on, red cross means audio is off".


Therefore, I have a suggestion which I think will work for both points of view and make things clear for all users (see below).


This change would work well coming from the 0.8, which also uses a blank symbol to represent the "off" state. The proposed new system would simply toggle a green tick to represent on/off. This also avoids users believing the "red cross" to be an error.

Obviously, the exact same situation also applies to buttons to turn on the webcam and screen sharing.
It would be great to know everyone's thoughts on this issue.

Very much looking forward to the 0.81 release, thanks, Andy

Fred Dixon

unread,
Jan 24, 2013, 5:49:50 PM1/24/13
to BigBlueButton-dev
Hi Andy,

Thanks very much for your detailed feedback. I can assure you that the audio and webcam buttons will be working as you described in 0.81.  See earlier discussion in this thread


BigBlueButton 0.81 is still in development; you'll get to try them out when we reach beta.


Regards,... Fred
-- 
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To post to this group, send email to bigblueb...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.

Yi Qiao

unread,
Mar 14, 2013, 3:00:48 PM3/14/13
to bigblueb...@googlegroups.com
On Friday, October 12, 2012 10:10:22 PM UTC-4, Fred Dixon wrote:
You'll note two aspects of this new design.

1.  We've removed the lock icons, which was a mechanism in 0.80 to
  (a) mute all (except locked)
  (b) prevent a viewer from unmuting themselves

In almost all classes we've participated in, we've never seen a moderator lock a viewer so they couldn't umute themselves.  We suspect that while people may like this feature (it's there in case I needed it), the presence and functions of the lock icons are not self-evident, most never use them because they either (a) don't understand their purpose or (b) have no need for them.  

We feel removing them will simplify the user experience, and anytime we can simply the user experience in BigBlueButton, we're headed in the right direction.


Hi Fred

  As a first post on this group, I'd like to say thanks for the great work. BBB 0.8 has been a fantastic experience in my current project and I'm loving all aspects of it ;)

  However I was a bit concerned about this decision. I agree that this is a user experience improvement for a small group of people in a controlled environment. But for more openly accessed conference, webinar with open registration for example, having the ability to lock participants so that they cannot interrupt the speaker's talk is in my own opinion very crucial. I found this open issue 1182 and just want to vocalize my support to include auto-lock feature.

From an end-user's perspective, a simplified yet powerful user interface is indeed very important, and I support your decision on this wholeheartedly. However I don't believe for anyone, who has the skill to provision an ubuntu 10.04 server and install BBB on it and have it properly configured, will be afraid to mess with a few lines in config.xml. So I guess a way to resolve not only this, but any further conflicts between UI and functionality could be, imho, making the system more configurable at least from the config file. I could imagine a property in the unified module, say "autoLock", that when set to true, newly joined user will be muted and locked. They could still raise their hands to request 'talk privilege', and moderator can then selectively unmute the requester, or not, at the moderator's discretion.

Thanks

Fred Dixon

unread,
Mar 14, 2013, 3:27:38 PM3/14/13
to BigBlueButton-dev
Hi Yi,

Thanks for your feedback.  We've been working on the unified users and listeners module and, as described in the previous post, we are trying to make it as simple as possible for the upcoming beta release.

We'll definitely take a second look at how we can accommodate the means to restrict new users from unmuting themselves, without going back to the per-user lock capability.  A global setting for autoLock is one approach.

We're still thinking about the best way to implement this without complicating the user interface.  We look forward to your feedback when we release the beta .

Regards,... Fred

-- 
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.

To post to this group, send email to bigblueb...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages