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: Jim Tobias
Date: Fri, Jun 22 2007 7:40 AM

Hi Gunnar,

Thanks again for your contribution here.

Please understand that my position is not based on any
technological issues. I only note the following,
which you may also agree with:

1. Deaf users have adopted line-by-line text conversation
and SMS with great enthusiasm because the options open
to them are mobile, easy to use, and accepted by many
non-deaf people. This last point allows for direct
communication rather than relay.

2. It is likely that if we require character-by-character
conversation in 255/508 that vendors will either not
provide it or support it as well as they do line-by-line,
and non-deaf users may not adopt it either. This would
perpetuate the communication ghetto we had with wireline
TTY.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Gunnar Hellström [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, June 21, 2007 10:23 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The goal is to get a good conversational flow without
> stressfull waiting.
> Stressful and confusion-creating waitng appears if you do not
> send regularly with a good conversational flow.
>
> Regularly means originally not more than a half second
> between transmissions, but in our discussion here it is
> stretched to one second, that takes us into the border area
> of risk for conversational collissions.
>
> Line-by-line is not good conversational flow, even if the
> line is transmitted rapidly once sent.
> Have you not noticed how you get a desire to shorten off
> sentences in IM, so that you keep the other party informed on
> your thoughts. That forces change in behaviour for you that
> is not needed if text was sent regularly without any specific
> action from you.
>
> Gunnar
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> = EMAIL ADDRESS REMOVED =
> Tel: +46708204288
> www.omnitor.se
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Thursday, June 21, 2007 3:40 PM
> 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