Re: [rtcweb] RTT (was Re: No Plan)

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Sat, 01 June 2013 07:34 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173D21F84CD for <rtcweb@ietfa.amsl.com>; Sat, 1 Jun 2013 00:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsdWznQmEFGQ for <rtcweb@ietfa.amsl.com>; Sat, 1 Jun 2013 00:34:16 -0700 (PDT)
Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 41A2221F848E for <rtcweb@ietf.org>; Sat, 1 Jun 2013 00:34:14 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for <rtcweb@ietf.org>; Sat, 1 Jun 2013 09:34:05 +0200 (CEST)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 956CB3A080 for <rtcweb@ietf.org>; Sat, 1 Jun 2013 09:34:05 +0200 (CEST)
Message-ID: <51A9A3F2.3090106@omnitor.se>
Date: Sat, 01 Jun 2013 09:34:10 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <51A907C2.6040801@matthew.at> <51A912DB.5010104@alum.mit.edu>
In-Reply-To: <51A912DB.5010104@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] RTT (was Re: No Plan)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jun 2013 07:34:21 -0000

On 2013-05-31 23:15, Paul Kyzivat wrote:
> I've been through this conversation before.
> There are no winners. Different strokes for different folks.
Agreed, or different strokes for different situations.

There is voice calls, video calls and real-time text for the active 
intensive conversational situations.
There is voice mail, video mail and text messaging for more loosely 
coupled exchange of information.

> IMO the texting UI should be as independent as possible of this 
> stylistic difference, and the actual protocol. The session 
> establishment should sort out the "best" compromise between the 
> desires and capabilities of the two ends.
>
>     Thanks,
>     Paul
>
Agreed.

> On 5/31/13 4:27 PM, Matthew Kaufman wrote:
>> On 5/30/2013 10:32 PM, Gunnar Hellstrom wrote:
>>>  I do not understand why modern communication users accept to see a
>>> chat state indication of "composing" instead of really seeing what
>>> text is composed.
>>
>> Perhaps because you haven't done user studies of SMS-style
>> compose-and-send vs. real-time text.
>>
>> I suggest you do that, and then you'll understand the several reasons
>> why most users (perhaps interestingly, excluding those users who are
>> hearing-impaired) prefer the former.
Tests are done and indicate the opposite.
>>
>>> With real-time text you get rid of the frustration that "composing"
>>> creates.
>>
>> And you add the sender's frustration of not being able to edit and
>> rethink their message before sending it, and the expectation on both the
>> sender and the receiver that they remain present for the duration of the
>> conversation rather than using it as a completely asynchronous messaging
>> modality, to reply when convenient. [this is just a subset of what the
>> user studies show, but touches a couple of the most common points]
Yes, that are commonly used arguments.  There are benefits of both. 
Different strokes and usability in different situations.

So I agree with Paul's conclusion above.

/Gunnar


>>
>> Matthew Kaufman
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb