CRT's are only zero input lag at the top edge of the screen. CRT's even have input lag for the bottom edge of the screen, because they have a finite frame transmission time (scanning from top to bottom). Some gaming LCD's (certain BENQ and ASUS gaming LCD's) are the same way; they scan the pixels top to bottom in real time too (as seen in high speed video).
We're talking about input lag from game engine to human eyeballs, so it WILL also include frame transmission time (From computer to display), including any display mechanisms (scanout). nVidia G-Sync solves the problem by using ultrafast frame transmission times (1/144sec, even when running at 60Hz, since G-Sync uses a dotclock for frame transmission/scanout times of 1/144sec) -- they clearly explained it in their video.
Now, strobing does add a minor input lag, but an average of less than one frame. (For LCD's with less motion blur than CRT"s, google "lightboost" -- John Carmack said he uses a LightBoost monitor)
This includes regular LCD refreshing modes, as well as motion-blur-eliminating LightBoost strobe backlight modes (that allows LCD to have less motion blur than some CRT's).
Interesting vision sensitivities. I have the same sensitivity to PWM trails --
Out of curiousity, do you prefer CRT or LCD? What about 120 Hz LCD's with motion-optimized-strobe-backlights (google "LightBoost") which simulate a 120Hz CRT and perfect zero motion blur?
For those people who don't mind CRT's, but get eyestrain from motion blur instead, there's a new technology called LightBoost (google "LightBoost") which is essentially PWM at one strobe per refresh, with 92% less motion blur than regular 60Hz LCD (full order of magnitude less motion blur).
Competition gamers have been purchasing 120Hz computer monitors as of late, and enabling the LightBoost strobe backlight, to regain CRT like clarity; covered at the Blur Busters Blog - http://www.blurbusters.com/ -- which also has 60Hz versus 120Hz versus LightBoost comparisions available.
The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).
The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).
The best implementation is called LightBoost -- PWM at one strobe flash per refresh, for the CRT effect http://www.blurbusters.com/faq/60vs120vslb (60Hz versus 120Hz versus LightBoost).
It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf: http://xmpp.org/extensions/xep-0301.html [xmpp.org] "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
Oh -- and Google does not capture all messages. There's lots of hidden XMPP message transmissions that goes on for other things, and Google does not log those.
XEP-0301 is intentionally designed to be backwards compatible, so you can safely transmit real-time text to any XMPP chat software, and it just ignores the real-time text part. It just displays only the finished (completed) messages. Though section 5 of the XEP-0301 spec recommends that you detect whether the remote end supports the real-time text, and to avoid transmitting real-time text, in order to save network bandwidth.
So existing software without real-time would work fine, even when connected to a real-time capable client that's intentionally transmitting real-time messages. (they're ignored since it's an additional XML element that's ignored, and only the finished full line of messages are displayed)
It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...
It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.
An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com)... Google was able to handle up to more than 10 XMPP messages per second very easily, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)
I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).
In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)
P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY..)
Actually, the spec does a compromise to transmit only 1 packet per second, even if there's 10 key presses per second. It buffers the key presses for a full second, even including the original intervals between the key presses. Then it transmits XML for the whole sequence, all at once.
This avoids overloading the network with too many messages per second, while keeping it sufficiently real-time, in a balanced compromise. (Yes, I know, it's "inefficient" XML, but XMPP.org encourages ease of programming over bandwidth efficiency. I'm fine with that. Besides, it doesn't really use much total bandwidth, anyway, especially since XMPP now permits base64 transmissions of avatar images and file transfers, etc -- all of which use more bandwidth than real time text. And the capped message rate is very reasonable.)
As this spec is partly designed for use by deaf people (including me; the specification's introduction specifically mentions this assistive use, too.), it is very desirable to see the original delays between the key presses. There is an animation of the key press interval encoding: http://www.marky.com/realjabber/real_time_text_demo.html As you notice in the animated GIF in the above link, there is a slight 'emotion' in the keypresses (calm typing versus panicked/emphatic typing) that deaf people like to pick up on, when supplemented with other contextual cues (text content, emoticons, etc).
Note -- For everyone else, the real-time feature can be turned on/off like audio/video is already an on/off feature in chats.
Some interesting notes to add, for this technology: -- It's also allowed to use a different transmission interval (i.e. 300ms) to reduce the lag, especially if you're using your own XMPP network where you can control the servers, etc. If using your own LAN XMPP server, you could even turn off transmission buffering and transmit all changes/keypresses immediately, but that's not a good idea for the public XMPP network, since that means 30 XMPP messages a second for a key being held down (auto-repeat) -- Generally, instead of capturing keypresses, an even better method is to monitor for text changes instead. This is because of the need to capture copy/pastes, automatic text replacements (auto spell checkers), voice recognition systems, special keyboards, that might not output one keypress at a time. Everytime the text in the sender's message changes, scan for the change (which is done in EncodeRawRTT( ) line 315 in RealTimeText.cs in realjabber.googlecoe.com...) and generate the action elements that way. That way you capture all possible changes to the text, as generally recommended in Implementor's Notes in section 6.2.1 of the specification. Although keypress events are OK, if you can strictly control all other possible changes to text (i.e. alternative text entry methods, copy/pastes, etc)
The spec is actually more targetted towards deaf-friendliness. The spec mentions: "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1].
That said, it's useful in the enterprise in certain contexts like an assistive-friendly workplace that does not involve boss chats, and also between two different engineers who intentionally turn on the feature (which is an on/off feature, like audio can be turned on/off and video can be turned on/off). In your use case, you definitely want to turn this feature off.
Yep, that worked, and it works well. In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.
However, because this standard is designed to benefit deaf people like me: Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).
Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.
The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
I do need to correct that last sentence. As shown in the animation, "you can transmit a multiple keypresses in only one packet per second. And yet keep the typing smooth."
There's an excellent reason for the XML (in)elegance. - We first tried a compact binary protocol, base64 encodings, and other alternate encodings. - But, XMPP prefers XML-based protocols. - We wanted ease of software development, so ease outweighed a lot of factors. - Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off - We chose delibrately short XML tags to reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise. - We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.
As you can watch in the animation, <t> is insert text, to support transmission of key presses, text block inserts, and text being pasted. <e> is backspace. <d> is delete key (forward delete), or cutting / deleting blocks of text <c> is cursor positioning (optional) <w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth. <g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.
So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off. http://www.marky.com/realjabber/real_time_text_demo.html
And what on earth would you use a "beep" command for?
Darn near everybody else has it:
Yahoo Buzz BlackBerry Ping Windows Live Nudge XMPP.org's XEP-0224 "Attention" (for Jabber / XMPP / Google Talk / etc)
This is a protocol optimized for assistive use for the deaf, too; and it can be turned on/off. (i.e. real time text is optional) This really, is an unobtrusive add-on that can be off by default (much like AIM's existing real time text feature is off by default)
It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf, and is potentially a replacement for TDD/TTY over the long term.
Some general comments that addresses common comments:
(1) This is an optional feature that can be turned on/off. You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to. Just like audio can be turned on/off and video can be turned on/off.
(2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf: http://xmpp.org/extensions/xep-0301.html "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
(3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.
(5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.
I know.:-) One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements: http://xmpp.org/extensions/xep-0301.html#key_press_intervals
It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document. http://xmpp.org/extensions/xep-0301.html "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too: http://xmpp.org/extensions/xep-0301.html "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
- It's an optional feature, that can be turned on/off as usage warrants - Just like audio can be turned on/off, and video can be turned on/off, real-time text can be turned on/off - It utilizes traditional instant messaging UI, too.
So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.
Understandable, but real-time text can be turned on/off. Some users like, it and some don't. AIM has an enable/disable feature for Real-Time IM. It can be an optional feature, like optional audio or video in their IM chats. I'm a deafie, and it's beneficial to use from time to time.
Slashdot Mirror
High speed video of an LCD refresh occuring in real-time:
http://www.youtube.com/watch?v=hD5gjAs1A2s
Also, input lag is the whole chain, INCLUDING how long it takes to display.
See AnandTech's article:
http://www.anandtech.com/show/2803/7
CRT's are only zero input lag at the top edge of the screen.
CRT's even have input lag for the bottom edge of the screen, because they have a finite frame transmission time (scanning from top to bottom).
Some gaming LCD's (certain BENQ and ASUS gaming LCD's) are the same way; they scan the pixels top to bottom in real time too (as seen in high speed video).
We're talking about input lag from game engine to human eyeballs, so it WILL also include frame transmission time (From computer to display), including any display mechanisms (scanout). nVidia G-Sync solves the problem by using ultrafast frame transmission times (1/144sec, even when running at 60Hz, since G-Sync uses a dotclock for frame transmission/scanout times of 1/144sec) -- they clearly explained it in their video.
Now, strobing does add a minor input lag, but an average of less than one frame. (For LCD's with less motion blur than CRT"s, google "lightboost" -- John Carmack said he uses a LightBoost monitor)
Hello,
Here's a high speed video of an LCD refreshing:
http://www.youtube.com/watch?v=hD5gjAs1A2s
This includes regular LCD refreshing modes, as well as motion-blur-eliminating LightBoost strobe backlight modes (that allows LCD to have less motion blur than some CRT's).
Mark Rejhon
Chief Blur Buster
Interesting vision sensitivities. I have the same sensitivity to PWM trails --
Out of curiousity, do you prefer CRT or LCD?
What about 120 Hz LCD's with motion-optimized-strobe-backlights (google "LightBoost") which simulate a 120Hz CRT and perfect zero motion blur?
For those people who don't mind CRT's, but get eyestrain from motion blur instead, there's a new technology called LightBoost (google "LightBoost") which is essentially PWM at one strobe per refresh, with 92% less motion blur than regular 60Hz LCD (full order of magnitude less motion blur).
Competition gamers have been purchasing 120Hz computer monitors as of late, and enabling the LightBoost strobe backlight, to regain CRT like clarity; covered at the Blur Busters Blog - http://www.blurbusters.com/ -- which also has 60Hz versus 120Hz versus LightBoost comparisions available.
And TFTCentral's "Motion Blur Reduction Backlights Including LightBoost":
http://www.tftcentral.co.uk/articles/motion_blur.htm
They found that LightBoost greatly outperformed scanning backlights.
Obviously, this technology is not for flicker sensitive people, but it can be turned on/off, and it's another option on the market.
This is true, 10Khz is detectabable, agreed by this paper
- http://www.lrc.rpi.edu/programs/solidstate/assist/pdf/AR-Flicker.pdf (10,000 Hz detected)
The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).
You ideally need PWM >10000 Hz.
- http://opensiuc.lib.siu.edu/cgi/viewcontent.cgi?article=1538&context=tpr (500 Hz detected)
- http://www.lrc.rpi.edu/programs/solidstate/assist/flicker.asp (300 Hz detected)
- http://www.lrc.rpi.edu/programs/solidstate/assist/pdf/AR-Flicker.pdf (10,000 Hz detected)
The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).
The best implementation is called LightBoost -- PWM at one strobe flash per refresh, for the CRT effect
http://www.blurbusters.com/faq/60vs120vslb (60Hz versus 120Hz versus LightBoost).
Also TFTCentral's "Motion Blur Reduction Backlights Including LightBoost" article:
http://www.tftcentral.co.uk/articles/motion_blur.htm
No, it has to be the same as refresh rate, or you get PWM artifacts:
http://www.blurbusters.com/faq/lcd-motion-artifacts
It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html [xmpp.org]
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
Oh -- and Google does not capture all messages.
There's lots of hidden XMPP message transmissions that goes on for other things, and Google does not log those.
XEP-0301 is intentionally designed to be backwards compatible, so you can safely transmit real-time text to any XMPP chat software, and it just ignores the real-time text part. It just displays only the finished (completed) messages. Though section 5 of the XEP-0301 spec recommends that you detect whether the remote end supports the real-time text, and to avoid transmitting real-time text, in order to save network bandwidth.
So existing software without real-time would work fine, even when connected to a real-time capable client that's intentionally transmitting real-time messages. (they're ignored since it's an additional XML element that's ignored, and only the finished full line of messages are displayed)
It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...
It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.
An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/ ... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com) ... Google was able to handle up to more than 10 XMPP messages per second very easily, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)
I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).
In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)
P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY ..)
Actually, the spec does a compromise to transmit only 1 packet per second, even if there's 10 key presses per second.
It buffers the key presses for a full second, even including the original intervals between the key presses.
Then it transmits XML for the whole sequence, all at once.
This avoids overloading the network with too many messages per second, while keeping it sufficiently real-time, in a balanced compromise. (Yes, I know, it's "inefficient" XML, but XMPP.org encourages ease of programming over bandwidth efficiency. I'm fine with that. Besides, it doesn't really use much total bandwidth, anyway, especially since XMPP now permits base64 transmissions of avatar images and file transfers, etc -- all of which use more bandwidth than real time text. And the capped message rate is very reasonable.)
As this spec is partly designed for use by deaf people (including me; the specification's introduction specifically mentions this assistive use, too.), it is very desirable to see the original delays between the key presses. There is an animation of the key press interval encoding:
http://www.marky.com/realjabber/real_time_text_demo.html
As you notice in the animated GIF in the above link, there is a slight 'emotion' in the keypresses (calm typing versus panicked/emphatic typing) that deaf people like to pick up on, when supplemented with other contextual cues (text content, emoticons, etc).
Note -- For everyone else, the real-time feature can be turned on/off like audio/video is already an on/off feature in chats.
Good answer.
Some interesting notes to add, for this technology: ...) and generate the action elements that way. That way you capture all possible changes to the text, as generally recommended in Implementor's Notes in section 6.2.1 of the specification. Although keypress events are OK, if you can strictly control all other possible changes to text (i.e. alternative text entry methods, copy/pastes, etc)
-- It's also allowed to use a different transmission interval (i.e. 300ms) to reduce the lag, especially if you're using your own XMPP network where you can control the servers, etc. If using your own LAN XMPP server, you could even turn off transmission buffering and transmit all changes/keypresses immediately, but that's not a good idea for the public XMPP network, since that means 30 XMPP messages a second for a key being held down (auto-repeat)
-- Generally, instead of capturing keypresses, an even better method is to monitor for text changes instead.
This is because of the need to capture copy/pastes, automatic text replacements (auto spell checkers), voice recognition systems, special keyboards, that might not output one keypress at a time. Everytime the text in the sender's message changes, scan for the change (which is done in EncodeRawRTT( ) line 315 in RealTimeText.cs in realjabber.googlecoe.com
The spec is actually more targetted towards deaf-friendliness. The spec mentions:
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1].
That said, it's useful in the enterprise in certain contexts like an assistive-friendly workplace that does not involve boss chats, and also between two different engineers who intentionally turn on the feature (which is an on/off feature, like audio can be turned on/off and video can be turned on/off). In your use case, you definitely want to turn this feature off.
Yep, that worked, and it works well.
In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.
However, because this standard is designed to benefit deaf people like me:
Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).
Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.
The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
I do need to correct that last sentence.
As shown in the animation, "you can transmit a multiple keypresses in only one packet per second. And yet keep the typing smooth."
There's an excellent reason for the XML (in)elegance.
- We first tried a compact binary protocol, base64 encodings, and other alternate encodings.
- But, XMPP prefers XML-based protocols.
- We wanted ease of software development, so ease outweighed a lot of factors.
- Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off
- We chose delibrately short XML tags to reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.
First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html
Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements
As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.
More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements
Only the first 3 XML elements are required (insert, backspace, and delete)
So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html
And what on earth would you use a "beep" command for?
Darn near everybody else has it:
Yahoo Buzz
BlackBerry Ping
Windows Live Nudge
XMPP.org's XEP-0224 "Attention" (for Jabber / XMPP / Google Talk / etc)
This is a protocol optimized for assistive use for the deaf, too; and it can be turned on/off. (i.e. real time text is optional) This really, is an unobtrusive add-on that can be off by default (much like AIM's existing real time text feature is off by default)
Unfortunately, deafies are stuck with this:
http://en.wikipedia.org/wiki/TDD/TTY
That's 45 baud.
It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf, and is potentially a replacement for TDD/TTY over the long term.
Hello --
Some general comments that addresses common comments:
(1) This is an optional feature that can be turned on/off.
You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to.
Just like audio can be turned on/off and video can be turned on/off.
(2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
(3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.
(4) There is an animation of the key press intervals (delay coding) at:
http://www.marky.com/realjabber/real_time_text_demo.html
(5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.
I know. :-)
One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:
http://xmpp.org/extensions/xep-0301.html#key_press_intervals
See examples 7.1 through 7.9:
http://www.xmpp.org/extensions/xep-0301.html
As well as the animation of smooth typing (non-bursting text) even at just 1 packet per second:
http://www.marky.com/realjabber/real_time_text_demo.html
This feature can be turned on/off.
It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document.
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."
- It's an optional feature, that can be turned on/off as usage warrants
- Just like audio can be turned on/off, and video can be turned on/off, real-time text can be turned on/off
- It utilizes traditional instant messaging UI, too.
It's also found in AOL Instant Messenger's Real-Time IM
http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568
However, we all wanted an open standard, that works on unmodified Jabber/XMPP, and that is how XEP-0301 got developed.
I actually thought of this.
XMPP real-time text is the world's first real time text protocol that encodes key press delays:
http://www.marky.com/realjabber/real_time_text_demo.html
So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.
XEP-0301 (the protocol) is a packetization of typing including typing delays, much like VoIP packetizes short snippets of audio.
Explained in first section in section 6:
http://xmpp.org/extensions/xep-0301.html#implementation_notes
Understandable, but real-time text can be turned on/off.
Some users like, it and some don't. AIM has an enable/disable feature for Real-Time IM.
It can be an optional feature, like optional audio or video in their IM chats.
I'm a deafie, and it's beneficial to use from time to time.