Displaying the keystrokes rate as a solution to the issue of the ?hesitant? speaker in I.M. (Instant Messaging) systems MB 07/05
Original Publication Date: 2009-Jul-20
Included in the Prior Art Database: 2009-Jul-20
Disclosed is a new solution of the well-known problem of the "hesitant" I.M. (Instant Messaging) speaker. The proposed solution is the implementation of a meter for displaying the typing speed of speakers involved in an online conversation. The measured speed shall be displayed (and updated at every,e.g., 5 seconds) to all the partners in the conversation. When the speed is zero and possibly keeps staying at zero, the other speaker can be sure that the hesitant speaker has actually stopped typing. The proposed solution applies to a many-to-many conversation as well. Every speaker involved is displayed with an indicator of his typing speed.
Displaying the keystrokes rate as a solution to the issue of the "hesitant" speaker in
I.M. (Instant Messaging) systems MB 07/05
Disclosed is a new solution of the well-known problem of the 'hesitant' I.M. speaker. This issue happens when one speaker (in a two- or many-speakers conversation) has begun typing something but then for any reason she/he stops typing. In I.M. clients like Lotus Sametime, Microsoft Messenger and others, the other speaker may see something in the bottom of the I.M. client like 'speakerX is typing' . Until this notification is over, the speaker on this side of the conversation is basically stuck.
This concept applies to a multi-speakers conversation as well, where many partners may be waiting for the response of one.
Now when this message takes too long, the speaker(s) on the other side of the conversation may think that the "hesitant" speaker has stopped typing, but this could be true or false.
Other solutions have been proposed to this problem in the past, for example one can be found in [*], where the authors suggest that a I.M. speaker could be simply enabled to turn on/off the 'speakerX is typing message ' notification on the chat client application.
We think that the former solution is not enough because it simply hides the problem but does not solve it.
We think that our solution (described in the next section) is better in that it provides a better feedback to the other chat partners and doesn't require any specific action to be done by each user. Furthemore it actually "solves" the issue and doesn't hide it.
The chat client will be able to count the keystrokes of a speaker in a time frame of a few...