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: Gunnar Hellström
Date: Wed, Jun 20 2007 10:35 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Paul E. Jones: "Re: RFC 4103 reference for real-time text."
- Previous message in thread: Gunnar Hellström: "Re: real-time text"
- Messages sorted by: Author | Thread | Date
Tere was a formatting mistake in the list of situations in my posting. Here
it is again, corrected, Sorry about the repetition.
----------------------------------------------------------------------------
---------------------------------
The existing IM services are just as available and good as before. No one
will block anyone from using them.
The goal is to have a proper real-time text medium that can be used in
telecommunications services on equal terms as the other real time
conversational media voice and video.
Why should text users be forced to wait for sentences to be completed when
voice users and sign users get a chance to keep synchronised in their minds
while the thoughts get expressed in spoken words or signing? It is logical
to provide all three media in all timing relations: Real time conversation
with all three media, Instant messaging with all three media, and email and
stored and retrieved contents in all three media.
This question was of course up for discussion also in the European TCAM eWGD
effort working on very similiar topics as Teitac-telecom. During that work,
we at Omnitor made a very brief comparison study with real users in an
intensive co-operation task over distance using modern real-time text versus
IM-style communication.
We tried it with hearing, deaf and hearing impaired users. There was a
preference towards using real-time text. There was no specific difference in
opinion between the different user groups. It was a very brief study that
can only be used as an indication.
There are a number of situations when it is especially valuable to have
real-time transmission of text.
-With text relay services
-With emergency services
-With IP captioned telephony
-In voice or video conferences with deaf or hard-of-hearing participants.
-In detailed explanations when you are in a hurry.
-In communication with people who have a TTY. If they do not see text
flowing they think something is wrong and hang up.
But in fact good for all situations when you want to have an efficient
communication.
The IM style is from a time when bandwidth and computer power were scarse
resources. We live now in the real-time era. In IP multimedia, audio is
transmitted 50 times per second, video is transmitted 30 times per second,
so we can afford to transmit text three times per second, giving the users a
good user experience in all media.
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 Gregg
Vanderheiden
Sent: Wednesday, June 20, 2007 8: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
> >
> >
- Next message in Thread: Paul E. Jones: "Re: RFC 4103 reference for real-time text."
- Previous message in Thread: Gunnar Hellström: "Re: real-time text"