I agree with Gregg for the most part. That said, it's still a concern of standards interoperability even when limiting retroactive editing to just only the last message (or two). That's a concern right now, even if I say, I permanently give up the possibility of using a private extension to allow retroactive editing beyond the last message. (Which I would rather not -- just to keep the door open for 'niche usage')
Yes, the standards have a method of highlighting edits. There are many methods of edit highlighting, and those are virtually all a UI implementation issue. Also, my spouse is a court reporter. You'd be surprised at the low quality of some of the software available (I've seen with my own eyes) & that XMPP would be a big improvement, especially if combined with some of the security-improving XMPP standards. Thanks! Mark Rejhon On Fri, Mar 25, 2011 at 4:38 PM, Gregg Vanderheiden <g...@trace.wisc.edu>wrote: > I think that we should be very careful with retro-editing. > > Any edits should be plainly visible as edits. There will be a lot of > business carried out in this medium. And much of it will be carried out by > people who not only don't pay attention to settings, but may not even know > there are settings in their client -- or that all clients do not behave the > same. > > So having someone able to edit the RECORD of the chat, not only on their > machine, but on the machines of others. And to allow them to edit text > that has scrolled off screen (say on a phone), would allow them to change > the RECORD of a conversation without the person knowing about it. > > Hence either > 1) don't allow retro editing OR > 2) mark edits so it is clear what was said, and that it was subsequently > edited. OR > 3) when a block is edited -- it is auto-copied to the bottom and > re-transmitted. (This takes no action by the standard -- and can be done > today in any client). > > Court reporters use special secure technologies and do not use IM. > Remote captioning services would use RTT - and would also have to clearly > mark edits for a number of reasons. > > We don't want to have something we do cause this IM to be viewed as less > safe for business than others. > > > *Gregg* > ----------------------- > Gregg Vanderheiden Ph.D. > Director Trace R&D Center > Professor Industrial & Systems Engineering > and Biomedical Engineering > University of Wisconsin-Madison > > On Mar 25, 2011, at 6:25 PM, Mark Rejhon wrote: > > Please note: My real time text standard is chat-based, just like AOL AIM > 6.8 or later in "AIM Real Time IM" (Google that string). It is highly > desirable by deaf users, in message-based chat. However, when combined with > retroactive editing, it becomes more collaboration. Boundaries get blurred. > It's no longer orthogonal. > > See the problem: > > 1. Even for ONE message back, this standards are incompatible. This needs > to be fixed. Retroactive editing is useful for real time text chats too! > > 2. And, what if, there was ever a reason, for MORE than one message back, > such as for court reporting? Same retroactive edit standard? > Or create new standard? > > See the problem? > One standard or two??? > It may be easier to keep it as two separate retroactive editing standards, > to cover all use cases. > If chat based, we should merge to one. > (We *ARE* blurring the lines between chat and collaboration when we use > both of our standards in the same chat software) > > As it stands, I'm using a chat-based real time text standard which > is great for conversations between the deaf (google "AOL Real-Time IM" > for some mainstream chat background info) > > SUGGESTED timeline: > - I work quickly to finish my Version 0.02 rewrite of my standard and > submit to XMPP.org (this has lit a fire under me to do so, more quickly) > - During the "experimental" stage of the standard, work towards > compatibility using minor tweaks to both of our standards > - Make sure our standards are compatible. > > Remember.... > - Real Time Text may someday become a mainstream opt-in "assistive" feature > of chat clients > - AOL AIM -- now has Real Time IM that can be activated via a menu option > - Jabber / GTalk / iChat -- My XMPP RTT standard (and I already have a > Google contact I may petition to add RTT support to GMAIL's chat), which is > modelled the same way but as an open standard rather than proprietary. > - etc. > And may all be required to interoperate someday, too. > But we have plenty of time. I like the idea of your retroactive editing > standard. > But we have very different ideas how to approach the retroactive edit > problem. > > So, the question becomes: One standard or two? (I already have a private > extension, with a configurable X-lines-allowed of retroactive editing -- > including limiting to only 1 or 2 lines of retroactivity -- which I > originally was not going to submit) > > Sincerely, > Mark Rejhon > > >
