Thread Subject: Re: real-time text

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Thu, Jun 21 2007 1:00 PM

Line by line isn't real-time. Some people contend that it is but it is
near-real-time or pseudo real time at best.

Most IM for example does flow through a server and is stored and forwarded.
Did you ever notice that sometimes the message doesn't appear right away? I
was on Skype call just last week and it took 9 minutes for a message I sent
to someone when I was talking to them - to arrive (and for theirs to get
back to me). They did arrive but only later. Usually (but not always) it
isn't stored for more than a moment.

The fact that IM is stored on servers was also a surprise and embarrassment
to a certain senator who found all his IM on a server backup.

Real-time text by comparison is point to point and happens in real time as
it is generated. It is not a message (as IM is) and it is not stored
somewhere.

People do say that they converse by email, and by SMS and by IM. I even
have heard people talk about conversing by mail. So the word 'converse' is
quite loosely used.

The goal is to allow real-time conversation where the person can track what
you are saying it as you are saying it.

Do demonstrate the difference I think we should create a demo where you talk
back and forth but the person cannot begin to hear what you say until you
are done saying it. (Push to record and it gets sent when you get to the end
of what you are saying). It is faster than typing but you will quickly see
how much slower it is and how it breaks communication conventions.

To try this for yourself - try saying everything to yourself silently
before you say it aloud on a phone call. Do it for a day. It is MUCH
better than not being able to talk but - not the same as talking in
real-time.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Thursday, June 21, 2007 8:40 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The problem is using the phrase "real-time text" to mean only
> character by character. Line-by-line is also real-time, and
> both are distinct from store and forward technologies like
> email and SMS. That's the important
> distinction: whether the end-to-end system is making a good
> faith effort to send text as it is received, or whether the
> system assumes that the text will remain in a server until
> retrieved somehow by the recipient. The latter is not a
> conversation. The goal is to require a capability for text
> conversation, not require how many characters are processed at a time.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Wednesday, June 20, 2007 2:39 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > What you would receive is exactly the same as what you
> receive on TTYs
> > today.
> >
> > All corrections are in place. You can see people backspace
> > - that is true.
> > But only if person sending wants to. That person has the option of
> > holding text back if they wish. It wouldn't be real-time text in
> > that case. but
> > the requirement is only that devices be capable of
> real-time text. it
> > does not require people to use real-time text.
> >
> > As Jim pointed out - they may wish to operate in IM mode,
> in message
> > mode.
> > Or send email. Just as all of us with real-time voice also
> > use all of
> > these other modes sometimes and want real-time
> communication at other
> > times.
> >
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > Of Tom Brett
> > > Sent: Wednesday, June 20, 2007 1:08 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > The t140 includes this option but I what I receive is
> > >
> > > Ga ood morning, I s am wrting writing you....
> > >
> > >
> > >
> > > Tom Brett
> > >
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg
> > > Vanderheiden
> > > Sent: Wednesday, June 20, 2007 1:27 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > Hi Tom
> > >
> > > T140 includes backspaces so you still get a corrected
> > message at the
> > > far end.
> > >
> > > And you can always have an option to hold back text if you
> > > wish. That is,
> > > a system with real-time text could ALSO have a mode that
> > was message
> > > like.
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto:teitac-telecom-
> > > > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > > > Sent: Wednesday, June 20, 2007 7:38 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: Re: [teitac-telecom] real-time text
> > > >
> > > > >> 1. Although the characters are to be transmitted
> > > quickly, there is
> > > > >> no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissible
> end-to-end delay is.
> > > >
> > > > >From my understanding of the real time text definition I
> > > thought that
> > > > >it
> > > > applied only to the device that was doing the output.
> > > There can be
> > > > significant delay in the receipt of the characters
> depending upon
> > > > receiving device or traffic on the transmission lines. The
> > > end to end
> > > > delay is, I think, beyond the control of the subcommittee
> > > because the
> > > > transmission is either via the internet or telephone lines.
> > > >
> > > > >>3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > >>the
> > > > huge mainstream advantages of chat and IM. I have not
> > > heard anything
> > > > from the many deaf users of these systems that the "Enter"
> > > key imposes
> > > > a conversational barrier. Moreover, it is unlikely that
> > mainstream
> > > > chat/IM program vendors will modify their programs to transmit
> > > > character by character. This leaves deaf and other users
> > > still in a
> > > > communication ghetto, instead of being able to use the
> same tools
> > > > everyone else is
> > > using.
> > > >
> > > > As a user of text communication tools that include
> > chat/im I do not
> > > > find this to be a barrier. In many respects I find this to be
> > > > superior to character by character transmission....we all make
> > > > typos...imagine receiving a character by character message:
> > > >
> > > > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> > > >
> > > > This becomes very confusing. I find it better to receive a
> > > complete
> > > > message with fewer typos that I can then decipher easier.
> > > >
> > > > Tom Brett
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > > > Tobias
> > > > Sent: Wednesday, June 20, 2007 8:21 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: [teitac-telecom] real-time text
> > > >
> > > > Hi All,
> > > >
> > > > As drafted on our call monday, the definition of
> > real-time text is:
> > > >
> > > > "Communications that employ the transmission of text
> wherein the
> > > > characters are transmitted by a terminal w/in a maximum of
> > > 1 sec. of
> > > > character input."
> > > >
> > > > I think there are a few problems here:
> > > >
> > > > 1. Although the characters are to be transmitted quickly,
> > > there is no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissable
> end-to-end delay is.
> > > >
> > > > 2. If the intention in this definition was to distinguish
> > TTY-style
> > > > (characters are transmitted as soon as they are keyed in)
> > > from IM and
> > > chat,
> > > > where you type a bunch of characters and then press "Enter" to
> > > > transmit, we should say so explicitly, somewhere.
> > > >
> > > > 3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > the huge mainstream advantages of chat and IM. I have
> not heard
> > > > anything from the many deaf users of these systems that
> > the "Enter"
> > > > key imposes a conversational barrier. Moreover, it is
> > > unlikely that
> > > > mainstream chat/IM program vendors will modify their
> programs to
> > > > transmit character by character. This leaves deaf and
> > other users
> > > > still in a communication ghetto, instead of being able to
> > > use the same
> > > > tools everyone else is
> > > using.
> > > >
> > > > ******
> > > > Jim Tobias
> > > > Inclusive Technologies
> > > > = EMAIL ADDRESS REMOVED =
> > > > +1 732.441.0831 voice/tty
> > > > skype jimtobias
> > > > +1 908.907.2387 mobile
> > > >
> > > >

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University