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: Sat, Jun 23 2007 10:00 AM

Hi Gunnar,

Thanks for all the background you provided.

I agree that there are two categories of text communication, and we might
call them "messaging" and "conversation". For me, the distinction is
whether or not there is an intervening server used for temporary or
permanent storage of the content. Such a server typically controls the
delay in transmission for reasons of network management. These delays can
be quite long, and completely unacceptable for conversation purposes,
especially in an emergency.

I want to consider both line and character mode media as conversational, not
messaging. They are usually serverless for the purpose we are discussing,
using peer-to-peer protocols for actual content and servers, if there are
any, for management purposes unconnected with transmission. The reason I
think of these as conversational is that the boundaries are under the total
control of the users. That is, a "line" can be a word, phrase, sentence or
paragraph. And my conversation partner knows the game as well, and can ask
me to send more frequently if he/she wants reassurance that I'm still there.
Having total user control of the conversational pacing makes the important
distinction here, not whether it is character or line mode. That's why I
think it's comparable enough to voice conversations, because the users are
determining the pacing.

I am also concerned by the implications of requiring character mode. As I
see it, we will need to have either separate character mode devices/software
or devices/software that can perform either character or line mode. (I rule
out the possibility of a complete migration to character mode with no line
mode devices/software.)

Both separate devices/software or devices/software requiring a user
selection of line or character mode are complicating factors that may reduce
overall usability and compatibility. We already have a problem with
proprietary IM platforms; although there are technical solutions, users are
not adopting them broadly enough to make them go away. What will users do
when they have to choose between line and character mode for each
conversation? Will we also require a hybrid mode in which one user is in
character mode and the other is in line mode?

As usual, I'm much more concerned with the implementation issues than with
the raw technology. At a moment when we are so close to having an effective
migration path from TTY to fully mainstream text conversational media,
imposing an additional requirement not currently found in mainstream
products runs a considerable risk.

******
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: Saturday, June 23, 2007 2:16 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Jim,
> This thread was originally about finding a good definition
> for "real-time text" so that the reader understands that it
> is a form of communcation that is experienced as transmitted
> character by character in the same pace as characters are
> entered and with a delay from single character input to
> display at the remote terminal that is short enough for an
> efficient problem free conversation.
>
> That form of communication requires its term and definition.
> We have tried to use and define "real-time text" for it.
>
> Other forms also need their definition, where text is
> collected in some logical collection; phrase, sentence,
> message, document etc, and transmitted when this whole
> collection is available. Shall we call them "messaging" for
> now, so that we can discuss the definitions?
>
> Other topics that we slanted into were the usability of these
> communication forms and if both needs support by 508.
> That needs of course also be settled, and will be easier once
> we have agreed on the terms and definitions.
> There are remarkable differences in usability, so there is
> definitely a need to have separate terms for the communication forms.
>
> We have had problems before in the work with international
> standards when assigning a good term for what we now call
> "real-time text". We have tried "real-time text
> conversation", "text", "text conversation",
> "character-by-character text", "interactive text", and now
> finally "real-time text" since a couple of years. Now we try
> to use "real-time text"
> consistently and hope that it will settle as a term with a
> commonly understood definition. I do not mind if someone
> creates an even more catching term for real-time text, but I
> hope we can avoid diffusing the meaning of the term.
>
> It is quite common that terms are created like this. You
> eventually get so used to the agreed conceptual meaning of
> the term that you accept that the words in the term itself
> cannot carry the whole definintion.
>
> Your proposal to also use the term "real-time text" for
> sentence-wise text makes me wonder if the currently proposed
> definition needs further sharpening. Or maybe keep the short
> definition as it is now and add a further explanatory description.
>
> 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: Friday, June 22, 2007 11:41 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Hi Jim,
>
> Not sure I understand your points. Some questions for
> clarification and
> some comments.
>
>
>
> > 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.
>
> a) IM is indeed used by people who are deaf and people who
> aren't. People who aren't deaf also have real-time methods
> (where people can 'hear' what people are saying as they are
> saying it) but people who are deaf do not.
> Is your point that everyone enjoys IM or that people who are
> deaf do not need and would not benefit from having the option
> of real-time (read as they
> write) communication.
>
> b) On your last sentence - you bring in relay. Not sure what
> you meant here. All of the proposed methods could be used
> with our without relay. Did I miss something?
>
>
>
> >
> > 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.
>
> Is your assumption that non-deaf users would not adopt it based on any
> research? All of our work has shown that many non-deaf
> people would love
> to have the ability to view text as it is written when in two
> way conversation in IM. They are frustrated by just seeing
> "the other person is typing" but not being able to see
> anything until it ends.
>
> And I'm not sure I understand the 'ghetto' comment. The new
> proposals move us away from TTY and to international
> standards for text on a call. The protocols proposed would
> allow both real-time and (see below) line by line
> conversation at the user's option.
>
> (I think implementing an option to allow users to hold their
> text until return is a good idea. There are times (and some
> people) where it is more
> desirable to finish a corrected utterance before sending.
> (In fact there
> are times when we should have that feature work for people
> when they are talking). )
>
> Thanks
>
> Gregg
>
>
>
> > ******
> > Jim Tobias
> > Inclusive Technologies
> > = EMAIL ADDRESS REMOVED =
> > +1 732.441.0831 voice/tty
> > skype jimtobias
>
>
>

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