Re:CUSeeMe Mac 0.83b3 remarks

Bill Woodland (wcw@bga.com)
Mon, 26 Feb 1996 00:10:22 -0600


As always, anyone should feel free to correct me if I'm wrong, and I've been
wrong before...I'm sure I will be wrong again :-)

>Date: Sun, 25 Feb 1996 18:43:43 -0700
>Reply-To: strev@mobius.net
>Sender: owner-CU-SEEME-L@cornell.edu
>From: strev@mobius.net (Dennis J. Streveler)
>To: <CU-SEEME-L@cornell.edu>
>Subject: CUSeeMe Mac 0.83b3 remarks
>X-Sender: strev@mail.mobius.net
>X-PH: V4.1@cornell.edu (Cornell Modified)
>X-Listprocessor-Version: 7.2(a) -- ListProcessor by CREN
>
>SFO DJS 96/02/25 11.44
>
>
>Hello,
>
>As a "beta tester" of your product, I offer the following remarks:
>
>
>GENERAL REMARK
>-------------------------
>There are many inconsistencies in HCI design. So many that I can't tell
>whether some of my suggestions were oversights, bugs or features! :)
>
>
>SPECIFIC REMARKS
>-------------------------
>
>1) There should be an indicator of what (effective) SPEED the other
>participant(s) are transmitting and receiving at. I guess the little red
>thermometers are supposed to tell you, but I'll be darned if they seem to
>bear any relationship to being able to determine how long it will be before
>the other sides video will arrive, how good one could expect the audio
>connection to be, etc. To my mind, the most important new feature would be
>to add some sort of way of accurately displaying system/network performance
>in real-time. If the thruput is going to hell, I want to know it CLEARLY,
>then I can terminate the connection, avoid audio, close some windows,
>reschedule the videoconference, take some informed action. I'd know how to
>manage my expectations! I want to know if I open a video window, for
>example, that it will take 30 seconds to get the first (more or less)
>completed frame, and from that point (given current performance) I can
>expect 3.7fps from that sender.

The MAC version does have a way for you to tell what the other users'
settings are, as does the White Pines PC version . The Cornell PC version
does not. I'm no MAC user so I can't tell you HOW to do this on the MAC<
but on the WP PC version, click on the user's name in the participants list
with the RIGHT mouse button and you will get an "info" button, which, when
clicked, will tell you their settings.

Throughput from a reflector would depend on:
the number of transmitters
the total number of video windows open by all receivers
the connection speeds of everyone sending OR receiving
the type of connection that the reflector is using (some refs actually run
on ISDN lines, which is not enough for more than a few users). Most
RESPECTABLE reflectors run on a T1 line, which gives you ~1.5mbs (I think).

Example:
8 ethernet transmitters sending at 80kbps with all seven of the other users'
windows open would require a MAXIMUM transmission speed of
80k*7windows*8users. This is 4480kbps, or 4.480 megabits per second, much
more than a T1 can actually handle.

With compression algorithms this max should never be reached, but I think
you get the picture. For the reflector to be able to tell you second by
second how much b/w is in use would just add more to the b/w requirements.

Developers:Is this correct?

>2) Many times one opens a window just to find a "gray box". Surely CUSeeMe
>must know there are now no video packets to send. Why should this ever
>occur? If there are no video packets to be sent, the user should be a
>"lurker" and should be labeled as "No Video". (I have noticed that when I
>look at statistics, often there are NO sent packets from such a source.)

Good point, but even when someone IS transmitting real video, and they don't
move a significant amount, should the reflector knock them down to "lurker"
status? You and I are (hopefully) more intelligent than the reflector
software, and must tolerate some things like this and make our own decisions.

>3) As there is a way to send "private audio", there should be a way to send
>a private Talk message. By the way, is it "talk" or "chat"? Apparently
>different platforms use different terms here. I know "talk" is an add-on,
>but that should not absolve it from not following the core programs
>conventions!

Private chat is in the works (or so I've been told). Chat/Talk...it's all
the same thing. I did find it odd, however, when the PC version came out
with the "chat" window, but the MAC people had been saying "talk" all along.

>4) There should be a way to send "selective audio" to more than one, but
>less than ALL, participants by depressing their microphone buttonS.

Nice idea. Developers?

>5) There should be a way to block your video from being received by one or
>more participants. Look at it this way, now you can decide which
>participant(s) you will RECEIVE, but you cannot decide which participant(s)
>can RECEIVE you.

Another nice idea, but most reflectors are PUBLIC, so if you don't want some
people to see you, maybe you shouldn't be transmitting video in the first
place. If you're shy, turn the camera off.

>6) You should easily be able to tell (without looking at the Disconnect
>menu item!) to whom you are currently connected. This should be shown as
>both a symbolic name and actual IP address. (One kludgy quick way of doing
>this might be to change the menu bar of the "Participant list" to this
>information.)

The WP version does this.

>7) A user should be able to give some brief "finger" information -- email
>address, location, whatever-- to be displayed along with the IP address.

Try that thing called "the chat window".

>8) There are times when I open a video window and am greeted with a
>double-size box, yet the user is not transmitting high-res. A bug?

I couldn't say, since I haven't had this hapen to me yet.

>9) Color transmissions should be labeled as such. I should be able to know
>this BEFORE I open the video window.

INFO again tells you this in the WP version.

>10) High-res transmissions should be labeled as such. I should be able to
>know this BEFORE I open the video window.

INFO again

>11) When someone is "speaking" (gray bar in Participant List) it is not
>possible to tell whether that person is speaking to you or to the world. I
>must also say that the little black squares and little hollow squares in
>the Participant List are not very well thought out, and not at all
>intuitive. A kludge if ever I saw one. Let me say again that if you ever
>want to this product to get out of techies hands and into the boardroom
>you'd better rethink the HCI very carefully.

No comment, since I'm a PC user and haven't sen the MAC participants list yet.

>12) The "pause" capability is great. (I like to sneeze in private!) But I
>should be reminded how long I have been in pause mode.

SOME things you just have to do for yourself.

>13) There should be better coordination between the "pause" button and the
>"stop sending video" menu choice. One should be able to resume after having
>stopped OR paused, by clicking on the pause button.

Pause just means to freeze your picture. "Stop sending video" means that
you are now a lurker. Big difference.

>14) I haven't been able to figure out what the "caps" are which show in the
>local video window information bars. They do not seem to bear much
>relationship to reality, nor to the current transmission/reception
>settings.

This is calculated by the software based on packets actually received and
packets lost, and is constantly adjusted for best performance.

>15) There should be some aid in helping you set the controls on your
>camera. (I use the QuickCam.) Something like the "levels" display in
>Photoshop so you can see the distribution of gray levels in your video.

Try connecting to 127.0.0.1 to see how your video window will look to
others. Your local window is not displayed the same way that other users
will see it. This conserves some processing time on your computer.

>16) The most common problem with the Push to Talk button is that people
>leave up on it too quickly, thus truncating their message. Apparently tehre
>is some lag in digitization of your speech, and you must not leave up on
>the button until the digitization is completed. ??

This is something that people will have to learn on their own, similar to
talking on a CB radio.

>17) The "slide window" needs lots of work! It must evolve (quickly!) into
>some sort of whiteboard if it is to become a "real" VC capability.

Try the WP whiteboard.

>
>
>Well, I hope my report is useful.
>
>
>Regards,
>Dennis
>
>
>
>------------------------------------
>Dennis J. Streveler, Ph.D.
>Systems Consultant
>San Francisco, California, USA
>------------------------------------
>CIS: 71036,1645
>Internet: strev@mobius.net
>CUSeeMe: strev.mobius.net
>------------------------------------
>My job? To send the appropriate electrons hurtling around the globe.
>
>
>

Bill Woodland (wcw@bga.com)
Squeek on Undernet IRC
Channel Manager #CU-SeeMe
http://www.realtime.com/~wcw/