You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@openmeetings.apache.org by Conrad Beckert <co...@gmx.de> on 2012/01/08 14:54:48 UTC
Some iconsiderations about the user interface
Hi,
at the moment I evaluate Openmeetings if it fits my use cases for communications systems - which are somewhere between Tele-Teaching and holding meetings with rather non technical people.
Until now we've had some drama with NAT gateways or the unwillingness to install software at the far end or we had to rely on proprietary software. So - Openmeetings is a great piece of software - an solution to many problems:
- no NAT drama - no NICE, no STUN to configure at the far end.
- easy to install on our own server
- no discussion about installing anything other than Skype on the other side. (OK, ipad followers excluded - I don't care, my Wetab works like a charme :-) )
Openmeetings has a lot of interesting features around conferencing the downside of which is an user interface which might be confusing to new users. So - in my humble opinion - my ideas for improving the user experiments:
1. On the login screen - why not just show the rooms available to that particular user - without distinguishing between public, group or private. I doubt, an average user would have access to more than, say 5 rooms at a time. So we wouldn't have to say: "click on group rooms, then enter ..."
2. I have different clients which I'd like to put into different rooms. Groups look great for that purpose. Why not have an option to send the user to this preferred room right after logging in? That would relief me of directing the user to enter the room by clicking here and there. OK, there is a workaround with invitations, but I'd like to give everybody his/her login. (probably the REST interface can help here)
3. Have a way to "store" the video windows somewhere while having the possibility to drag someone out to watch closely while the others stay in line. (as BigBlueButton does)
4. Overall, a bit more flexibility in the screen layout would be nice. The user list in the "conference" style consumes a lot of screen real estate - especially when watching a shared desktop. Chat is rather unusable as an incoming chat message would not display when the section is minimized. When not minimized, expensive vertical space is lost. Why not maximize when a message comes in? <dream>Integration with XMPP</dream>
5. Is there a (documented) way to configure the screen layout? It would be nice to create different layouts for different needs. (I miss e.g. a simple one2one video conference with the remote screen maximized and maybe a chat window below - no more) I wouldn't mind to dig into XML to get this. :-)
6. Have some measurement to estimate delays and bandwidth jams. I have the strange situation that somehow delays go up to 10sec - with no reasonable cause (512kbit upload - not even close to the 1024kbit available here). If this is probably something outside of our reach (as it is TCP) - is it possible to detect delayed signals and warn? This delay issue is severely affecting acceptance. (for some strange reason I've never heard anybody complaining about drop outs and delays on Skype)
7. Is there a way e.g. to subscribe the calendar to a CalDav server for synchronizing it with my egroupware calendar. (or any other supporting this) Planning conferences requires checking my appointments first - if I or the other persons, maybe, is/are available.
8. have that great mindmap feature soon. :-)
OK, enough wishes for today. Christmas is over for two weeks. Hope that helps.
Greetings
Conrad
PS: Dreaming of a WebRTC version some day. :-)
RE: RE: Some iconsiderations about the user interface
Posted by Joseph Karwat <jk...@jellnet.com>.
Conrad:
I was merely suggesting that the developers consider adding a feature to the whiteboard (I.e. the ability to act as a browser window, controlled by the presenter(s)). The feature does not currently exist in OpenMeetings. As I use OpenMeetings extensively for a number of business type of meetings this feature would eliminate 90% or the reasons anyone would need to share their screen during a vchat. And therefore eliminate all the issues with endpoint bandwidth to the server.
Joseph Karwat | CEO | 415-462-0263 |www.jellnet.com |
JELL NETWORKS, INC.
Enterprise Video Collaboration Solutions
-----Original Message-----
From: Conrad Beckert [mailto:conrad_videokonferenz@gmx.de]
Sent: Thursday, January 26, 2012 2:36 AM
To: openmeetings-user@incubator.apache.org; openmeetings-user@incubator.apache.org
Subject: Re: RE: Some iconsiderations about the user interface
Hi Joseph
>> I believe you can reduce the need to share one's screen by enabling the whiteboard to go to a url. In other words make the whiteboard a browser at the server side controlled by the presenter(s).<<
OK - that could be a way - even if I'd need to VNC to another machine to show the client some changes made to his software. But: How can I do that? I still have version 1.9.1. Is there a new one?
>> As Sebastion indicated, there are always issues in allowing an individual to share their screen or app. Eliminating the need for it greatly enhances the user experience.<<
Sorry, I must contradict. Improving it removes the urgent need for many other things: It is nice to put efforts into cool features such as brain storming, mind mapping etc. But sharing the screen we could work together on *any* subject with *any* programm. We're not very far from that in the current version. I use it quite often. It is better than many other systems as it is easier to use and offers a decent experience. But:
- bandwidth can be an issue which could be mitigated by lowering the image quality (less color, maybe jpeg compression)
- messed up diacritical characters when typing to the other side on Linux
There are FLOSS technologies such as VNC which provide a quite good scalable experience even on narrow lines. Why not build upon that?
Conrad
Re: RE: Some iconsiderations about the user interface
Posted by Conrad Beckert <co...@gmx.de>.
Hi Joseph
>> I believe you can reduce the need to share one's screen by enabling the whiteboard to go to a url. In other words make the whiteboard a browser at the server side controlled by the presenter(s).<<
OK - that could be a way - even if I'd need to VNC to another machine to show the client some changes made to his software. But: How can I do that? I still have version 1.9.1. Is there a new one?
>> As Sebastion indicated, there are always issues in allowing an individual to share their screen or app. Eliminating the need for it greatly enhances the user experience.<<
Sorry, I must contradict. Improving it removes the urgent need for many other things: It is nice to put efforts into cool features such as brain storming, mind mapping etc. But sharing the screen we could work together on *any* subject with *any* programm. We're not very far from that in the current version. I use it quite often. It is better than many other systems as it is easier to use and offers a decent experience. But:
- bandwidth can be an issue which could be mitigated by lowering the image quality (less color, maybe jpeg compression)
- messed up diacritical characters when typing to the other side on Linux
There are FLOSS technologies such as VNC which provide a quite good scalable experience even on narrow lines. Why not build upon that?
Conrad
RE: Some iconsiderations about the user interface
Posted by Joseph Karwat <jk...@jellnet.com>.
I believe you can reduce the need to share one's screen by enabling the whiteboard to go to a url. In other words make the whiteboard a browser at the server side controlled by the presenter(s). As Sebastion indicated, there are always issues in allowing an individual to share their screen or app. Eliminating the need for it greatly enhances the user experience.
Joseph Karwat | CEO | 415-462-0263 | JellVideo | www.jellnet.com |
JELL NETWORKS, INC.
Enterprise Video Collaboration Solutions
Click Here to Register for your JellVideo Collaboration Account
-----Original Message-----
From: Conrad Beckert [mailto:conrad_videokonferenz@gmx.de]
Sent: Tuesday, January 24, 2012 8:28 AM
To: openmeetings-user@incubator.apache.org
Subject: Re: Some iconsiderations about the user interface
Hi Sebastian,
> thanks for providing feedback.
cool to hear from you.
> Point No 5. see
> http://incubator.apache.org/openmeetings/ConferenceRoomLayoutOptions.html
Looking forward to check out version 2.x :-)
> Point No 6. Delay is always bandwith, maybe one of the participant is the
> bottleneck, not you.
Indeed - problem is: how to detect that in a production environment. In my practical cases delays always occur when I share my screen to others. Standard DSL is OK for a single audio video upload (and if the server is outside "in the clouds" there is only one isn't it) A shared screen eats up bandwidth - especially if it is large. Wouldn't it be possible to reduce color depth as VNC can do?
> Point No 8. this might take some time as its not that high prio at the moment
When Screen Sharing works fine, there is no need for it as we can share Freemind etc.
> For the other points modifications are needed. I am afraid that the
> community version will never 100% look like perfect for every use-case but
... it comes close yet :-)
> we hope that the configuration already contains a wide range of different
> customization possibilities.
it does and as promised, version 2. will be even better.
Thank you for providing such a cool system. Great work!
Greetings
Conrad
>
> Sebastian
>
> 2012/1/8 Conrad Beckert <co...@gmx.de>
>
> > Hi,
> >
> > at the moment I evaluate Openmeetings if it fits my use cases for
> > communications systems - which are somewhere between Tele-Teaching and
> > holding meetings with rather non technical people.
> >
> > Until now we've had some drama with NAT gateways or the unwillingness to
> > install software at the far end or we had to rely on proprietary
> software.
> > So - Openmeetings is a great piece of software - an solution to many
> > problems:
> > - no NAT drama - no NICE, no STUN to configure at the far end.
> > - easy to install on our own server
> > - no discussion about installing anything other than Skype on the other
> > side. (OK, ipad followers excluded - I don't care, my Wetab works like a
> > charme :-) )
> >
> > Openmeetings has a lot of interesting features around conferencing the
> > downside of which is an user interface which might be confusing to new
> > users. So - in my humble opinion - my ideas for improving the user
> > experiments:
> >
> > 1. On the login screen - why not just show the rooms available to that
> > particular user - without distinguishing between public, group or
> private.
> > I doubt, an average user would have access to more than, say 5 rooms at
> a
> > time. So we wouldn't have to say: "click on group rooms, then enter ..."
> >
> > 2. I have different clients which I'd like to put into different rooms.
> > Groups look great for that purpose. Why not have an option to send the
> user
> > to this preferred room right after logging in? That would relief me of
> > directing the user to enter the room by clicking here and there. OK,
> there
> > is a workaround with invitations, but I'd like to give everybody his/her
> > login. (probably the REST interface can help here)
> >
> > 3. Have a way to "store" the video windows somewhere while having the
> > possibility to drag someone out to watch closely while the others stay
> in
> > line. (as BigBlueButton does)
> >
> > 4. Overall, a bit more flexibility in the screen layout would be nice.
> The
> > user list in the "conference" style consumes a lot of screen real estate
> -
> > especially when watching a shared desktop. Chat is rather unusable as an
> > incoming chat message would not display when the section is minimized.
> When
> > not minimized, expensive vertical space is lost. Why not maximize when a
> > message comes in? <dream>Integration with XMPP</dream>
> >
> > 5. Is there a (documented) way to configure the screen layout? It would
> be
> > nice to create different layouts for different needs. (I miss e.g. a
> simple
> > one2one video conference with the remote screen maximized and maybe a
> chat
> > window below - no more) I wouldn't mind to dig into XML to get this. :-)
> >
> > 6. Have some measurement to estimate delays and bandwidth jams. I have
> the
> > strange situation that somehow delays go up to 10sec - with no
> reasonable
> > cause (512kbit upload - not even close to the 1024kbit available here).
> If
> > this is probably something outside of our reach (as it is TCP) - is it
> > possible to detect delayed signals and warn? This delay issue is
> severely
> > affecting acceptance. (for some strange reason I've never heard anybody
> > complaining about drop outs and delays on Skype)
> >
> > 7. Is there a way e.g. to subscribe the calendar to a CalDav server for
> > synchronizing it with my egroupware calendar. (or any other supporting
> > this) Planning conferences requires checking my appointments first - if
> I
> > or the other persons, maybe, is/are available.
> >
> > 8. have that great mindmap feature soon. :-)
> >
> > OK, enough wishes for today. Christmas is over for two weeks. Hope that
> > helps.
> >
> > Greetings
> > Conrad
> >
> > PS: Dreaming of a WebRTC version some day. :-)
> >
>
>
>
> --
> Sebastian Wagner
> http://www.openmeetings.de
> http://incubator.apache.org/openmeetings/
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
Re: Some iconsiderations about the user interface
Posted by Conrad Beckert <co...@gmx.de>.
Hi Sebastian,
> thanks for providing feedback.
cool to hear from you.
> Point No 5. see
> http://incubator.apache.org/openmeetings/ConferenceRoomLayoutOptions.html
Looking forward to check out version 2.x :-)
> Point No 6. Delay is always bandwith, maybe one of the participant is the
> bottleneck, not you.
Indeed - problem is: how to detect that in a production environment. In my practical cases delays always occur when I share my screen to others. Standard DSL is OK for a single audio video upload (and if the server is outside "in the clouds" there is only one isn't it) A shared screen eats up bandwidth - especially if it is large. Wouldn't it be possible to reduce color depth as VNC can do?
> Point No 8. this might take some time as its not that high prio at the moment
When Screen Sharing works fine, there is no need for it as we can share Freemind etc.
> For the other points modifications are needed. I am afraid that the
> community version will never 100% look like perfect for every use-case but
... it comes close yet :-)
> we hope that the configuration already contains a wide range of different
> customization possibilities.
it does and as promised, version 2. will be even better.
Thank you for providing such a cool system. Great work!
Greetings
Conrad
>
> Sebastian
>
> 2012/1/8 Conrad Beckert <co...@gmx.de>
>
> > Hi,
> >
> > at the moment I evaluate Openmeetings if it fits my use cases for
> > communications systems - which are somewhere between Tele-Teaching and
> > holding meetings with rather non technical people.
> >
> > Until now we've had some drama with NAT gateways or the unwillingness to
> > install software at the far end or we had to rely on proprietary
> software.
> > So - Openmeetings is a great piece of software - an solution to many
> > problems:
> > - no NAT drama - no NICE, no STUN to configure at the far end.
> > - easy to install on our own server
> > - no discussion about installing anything other than Skype on the other
> > side. (OK, ipad followers excluded - I don't care, my Wetab works like a
> > charme :-) )
> >
> > Openmeetings has a lot of interesting features around conferencing the
> > downside of which is an user interface which might be confusing to new
> > users. So - in my humble opinion - my ideas for improving the user
> > experiments:
> >
> > 1. On the login screen - why not just show the rooms available to that
> > particular user - without distinguishing between public, group or
> private.
> > I doubt, an average user would have access to more than, say 5 rooms at
> a
> > time. So we wouldn't have to say: "click on group rooms, then enter ..."
> >
> > 2. I have different clients which I'd like to put into different rooms.
> > Groups look great for that purpose. Why not have an option to send the
> user
> > to this preferred room right after logging in? That would relief me of
> > directing the user to enter the room by clicking here and there. OK,
> there
> > is a workaround with invitations, but I'd like to give everybody his/her
> > login. (probably the REST interface can help here)
> >
> > 3. Have a way to "store" the video windows somewhere while having the
> > possibility to drag someone out to watch closely while the others stay
> in
> > line. (as BigBlueButton does)
> >
> > 4. Overall, a bit more flexibility in the screen layout would be nice.
> The
> > user list in the "conference" style consumes a lot of screen real estate
> -
> > especially when watching a shared desktop. Chat is rather unusable as an
> > incoming chat message would not display when the section is minimized.
> When
> > not minimized, expensive vertical space is lost. Why not maximize when a
> > message comes in? <dream>Integration with XMPP</dream>
> >
> > 5. Is there a (documented) way to configure the screen layout? It would
> be
> > nice to create different layouts for different needs. (I miss e.g. a
> simple
> > one2one video conference with the remote screen maximized and maybe a
> chat
> > window below - no more) I wouldn't mind to dig into XML to get this. :-)
> >
> > 6. Have some measurement to estimate delays and bandwidth jams. I have
> the
> > strange situation that somehow delays go up to 10sec - with no
> reasonable
> > cause (512kbit upload - not even close to the 1024kbit available here).
> If
> > this is probably something outside of our reach (as it is TCP) - is it
> > possible to detect delayed signals and warn? This delay issue is
> severely
> > affecting acceptance. (for some strange reason I've never heard anybody
> > complaining about drop outs and delays on Skype)
> >
> > 7. Is there a way e.g. to subscribe the calendar to a CalDav server for
> > synchronizing it with my egroupware calendar. (or any other supporting
> > this) Planning conferences requires checking my appointments first - if
> I
> > or the other persons, maybe, is/are available.
> >
> > 8. have that great mindmap feature soon. :-)
> >
> > OK, enough wishes for today. Christmas is over for two weeks. Hope that
> > helps.
> >
> > Greetings
> > Conrad
> >
> > PS: Dreaming of a WebRTC version some day. :-)
> >
>
>
>
> --
> Sebastian Wagner
> http://www.openmeetings.de
> http://incubator.apache.org/openmeetings/
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
Re: Some iconsiderations about the user interface
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Conrad,
thanks for providing feedback.
Point No 5. see
http://incubator.apache.org/openmeetings/ConferenceRoomLayoutOptions.html
Point No 6. Delay is always bandwith, maybe one of the participant is the
bottleneck, not you.
Point No 8. this might take some time as its not that high prio at the
moment
For the other points modifications are needed. I am afraid that the
community version will never 100% look like perfect for every use-case but
we hope that the configuration already contains a wide range of different
customization possibilities.
Sebastian
2012/1/8 Conrad Beckert <co...@gmx.de>
> Hi,
>
> at the moment I evaluate Openmeetings if it fits my use cases for
> communications systems - which are somewhere between Tele-Teaching and
> holding meetings with rather non technical people.
>
> Until now we've had some drama with NAT gateways or the unwillingness to
> install software at the far end or we had to rely on proprietary software.
> So - Openmeetings is a great piece of software - an solution to many
> problems:
> - no NAT drama - no NICE, no STUN to configure at the far end.
> - easy to install on our own server
> - no discussion about installing anything other than Skype on the other
> side. (OK, ipad followers excluded - I don't care, my Wetab works like a
> charme :-) )
>
> Openmeetings has a lot of interesting features around conferencing the
> downside of which is an user interface which might be confusing to new
> users. So - in my humble opinion - my ideas for improving the user
> experiments:
>
> 1. On the login screen - why not just show the rooms available to that
> particular user - without distinguishing between public, group or private.
> I doubt, an average user would have access to more than, say 5 rooms at a
> time. So we wouldn't have to say: "click on group rooms, then enter ..."
>
> 2. I have different clients which I'd like to put into different rooms.
> Groups look great for that purpose. Why not have an option to send the user
> to this preferred room right after logging in? That would relief me of
> directing the user to enter the room by clicking here and there. OK, there
> is a workaround with invitations, but I'd like to give everybody his/her
> login. (probably the REST interface can help here)
>
> 3. Have a way to "store" the video windows somewhere while having the
> possibility to drag someone out to watch closely while the others stay in
> line. (as BigBlueButton does)
>
> 4. Overall, a bit more flexibility in the screen layout would be nice. The
> user list in the "conference" style consumes a lot of screen real estate -
> especially when watching a shared desktop. Chat is rather unusable as an
> incoming chat message would not display when the section is minimized. When
> not minimized, expensive vertical space is lost. Why not maximize when a
> message comes in? <dream>Integration with XMPP</dream>
>
> 5. Is there a (documented) way to configure the screen layout? It would be
> nice to create different layouts for different needs. (I miss e.g. a simple
> one2one video conference with the remote screen maximized and maybe a chat
> window below - no more) I wouldn't mind to dig into XML to get this. :-)
>
> 6. Have some measurement to estimate delays and bandwidth jams. I have the
> strange situation that somehow delays go up to 10sec - with no reasonable
> cause (512kbit upload - not even close to the 1024kbit available here). If
> this is probably something outside of our reach (as it is TCP) - is it
> possible to detect delayed signals and warn? This delay issue is severely
> affecting acceptance. (for some strange reason I've never heard anybody
> complaining about drop outs and delays on Skype)
>
> 7. Is there a way e.g. to subscribe the calendar to a CalDav server for
> synchronizing it with my egroupware calendar. (or any other supporting
> this) Planning conferences requires checking my appointments first - if I
> or the other persons, maybe, is/are available.
>
> 8. have that great mindmap feature soon. :-)
>
> OK, enough wishes for today. Christmas is over for two weeks. Hope that
> helps.
>
> Greetings
> Conrad
>
> PS: Dreaming of a WebRTC version some day. :-)
>
--
Sebastian Wagner
http://www.openmeetings.de
http://incubator.apache.org/openmeetings/
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com