The reason for deleting it is not just because its a difficult to understand that there are multiple room types. Although this is of course an argument. The main reason to delete it is that its simple a "historical" component that was replaced by the room type "restricted" and by enabling the features of that room type in all room types. But instead of immediatelly replacing it we just maintained all room types. That was an error that we should try to correct now from my point of view.
The room type "audience" once was designed to have a room type where the teacher has more *control about audio/video* (1) and the* video is bigger by default* (2) and the *user list is displayed in squares instead of list view* (3). (1) *more control about audio/video*: Meanwhile we have separated right for audio+video and the moderator can mute unmute in any room type. No need to make an extra roomtype, you have this control in all room types. (2) *Video bigger by default*: You can now switch video size to any dimension in all room types. No need to have an extra room type for that (3) *Display user list as squares instead of list*: This list view has several disadvantages and it is not possible to have more then 40-50 users in this room type as the squares list view renders to slow and the client will hang up. That is why we created a new room type "restricted" that can handle 200++ users in the list and that buffers incoming events in the user list so that it does not re-render too often. So after all this room type is just legacy code that eats our time in maintaining it while the reasons why it does exist just are not given anymore. I would propose that we will disable the"audience" entry in the roomtypes table. Audience room type had roomTypeId 3. You would still be able to use that roomTypeId, however internally I will rewrite roomTypeId from 3 to 4. 4 is the restricted room type. That we are backwards compatible with the roomTypeIds. Sebastian 2012/2/26 Andre Bueno Lima <[email protected]>: > Hello Sebastian, > > Actually the room type "restricted" is more usual in most situations. > But do not believe it should be removed from the room type "audience" only > by users having difficulty understanding the application of each type of > room. > If we both understand the users, then we know that the average user > does not have the patience to test or read about the details at the time of > usuar a new feature, such as the creation of rooms in OM. > If you allow me, I would suggest a second proposal: In the rooms > created by default, allow only limited, and leave the others disabled. A > user with more expert or other needs, would enable them manually. > As a testimony, I would say that I am testing the OM in the company I > work in an environment of approval, and my team has demonstrated skillful > use of all types of rooms, as the dynamics of meetings in OM. Even more, I > learned about the OM through two federal universities, which also comes with > satisfaction using other types of rooms. > Another solution to mitigate the concerns of users, would help put a > link next to the types of rooms, and can clarify their utilities. > > André. > > 2012/2/25 [email protected] <[email protected]> > >> Hi, >> >> the number of room types makes it sometimes hard for people to get >> started with OpenMeetings. >> The restricted room type is actually the better audience room type. >> So shall we just remove the room type "audience" ? >> >> Is there any VETO to delete the room type "audience" ? Stand up now or >> .... :) >> >> Sebastian >> -- >> Sebastian Wagner >> http://www.openmeetings.de >> http://incubator.apache.org/openmeetings/ >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] -- Sebastian Wagner http://www.openmeetings.de http://incubator.apache.org/openmeetings/ http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
