CUSeeMe Mac 0.83b3 remarks

Dennis J. Streveler (strev@mobius.net)
Sun, 25 Feb 1996 18:43:43 -0700


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.

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.)

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!

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

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.

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.)

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

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?

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

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

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.

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.

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.

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.

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.

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. ??

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.

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.