Tuesday, November 20, 2007
Real-Time Shared Editing over XMPP
The ECF project has been adding some real-time collaboration functions for dev team support...for example, sharing selected text in Eclipse editors, as well as real-time collaborative editing...all over the ECF datashare API...which means you can use your favorite public IM accounts like google talk, or skype rather than be forced to have yet another account. We've also got some new sharing of Mylyn tasks as per bug 195737.
Subscribe to:
Post Comments (Atom)
7 comments:
Scott, this look very promising! Great stuff.
It would be also really nice to unify the UI. The hyperlink idea used for one of these features seem like less intrusive and interruptive approach then showing popup dialogs or even notification popups about editor sharing or Mylyn tasks. It would be great to straighten it across all ECF UI. Then notification popups can be just a generic service that can be used for various notifications (including regular IM messages).
By the way, what are those 6 seem like ECF related toolbar buttons shown on screenshots on the wiki?
Good stuff Scott! I am working on getting Cola Real-Time Shared Editing updated (see bugzilla) and integrated.
Might come just in time for Thanksgiving :)
Hi Eugene,
Please clarify what you mean by using the hyperlink idea. Do you mean having a hyperlink in the notification dialog? We would very much like to do this...and are happy to use anything associated with bug 177974 for notifications. Could you point us to code to use here?
RE: the 6 ECF toolbar buttons, the two on the left are the regular ECF example app buttons. Three of them are UI for jgroups, JMS-ActiveMQ, JMS-Weblogic providers (other providers that have/use example apps) running and testing in my workspace. And the last one is to open contacts.
Please try to avoid dialogs triggered by IM events (think that someone could be in a middle of printing something when dialog jump out of nowhere). By hyperlinks I meant one shown on this screenshot.
Can you shrink all those toolbar buttons into one toolbar with a dropdown? So, first item would be to open person, then the rest will be provider specific stuff. Too many toolbar buttons are polluting workbench UI.
RE: avoiding dialogs in response to events...we need some mechanism (notification popup, etc) that provides (accept/reject) options to user as there may not be any chat established prior to the event. I agree that providing the user a hyperlink in the chat is a good mechanism, and we will continue to use it when available, but we can't guarantee a UI for the hyperlink in advance of the event so need some other mechanism to handle this case.
RE: toolbar buttons...these are not the permanent UI and we will consider other mechanism...RE: polluting workbench UI...the ones that remain after changes will be in communication perspective only Feel free to make design/impl contribution for specific designs.
If chat is not opened, it need to be opened at the first event, either it is a plain IM message, or hyperlink, or editor sharing invitation, or anything else. This is semantically the same as getting plain IM message. Note that any popups, including notification windows don't provide appropriate persistence in the UI and distract user (so, some may want to completely disable them all together). Also note that notification poups are usually shown for some fixed time and then discarded, if they would be only available from these popups. Also note that other popular editor sharing tools do provide parallel chat, and it really worth to reuse their UI experience.
I think it makes sense to minimize UI regardless of the used perspective. Less UI is better.
Anyways, if you don't trust my suggestions, then please consult with the UI working group.
Thanks for the suggestions.
>This is semantically the same as >getting plain IM message.
I don't think I agree with you about this. In general, I would say it depends upon the event (and implied action of the event). Not all such actions are 'semantically equivalent to IM'.
Some might consider raising the messages window (as a result of an editor share action) kind of unexpected...as well as unnecessary UI. Depends upon context, I would say.
RE: disablement and control of popups...I agree, there need to be options WRT how notifications are handled. This was/is my hope for bug 177974 as it doesn't seem to me everyone should/have to reimplement these same mechanisms for different notifications situations.
RE: limiting communications UI and less UI is better...I agree with you except when the desired action is communication :).
RE: consulting with the UI working group...we are, but your suggestions are welcome nonetheless. Contributions also welcome.
Post a Comment