Last modified: 2014-07-04 00:37:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1898 - Provide a real-time collaborative editing system
Provide a real-time collaborative editing system
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Sean
http://intcomm.wiki.taoriver.net/moin...
:
: 4427 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-15 15:40 UTC by Sean
Modified: 2014-07-04 00:37 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sean 2005-04-15 15:40:13 UTC
== WikiMeet - Real-Time Concurrent Editing ==

WikiMeet is a blend of the Wiki philosophy with the productivity potential of
[http://en.wikipedia.org/wiki/MoonEdit MoonEdit] and the grace of
[http://en.wikipedia.org/wiki/SubEthaEdit SubEthaEdit].

Being able to see the changes that are happenning in real-time in a rich-text
editor would push the wiki philosophy in a new direction. While admittedly, it
would often be distracting for large-scale sites with many users editing at
once, it is ideal for many situations.

Examples:
*A blending between chatting and wiking. Rather than discussing changes in one
window and then implementing them in another, it would be a huge time saver to
both discuss and implement the changes ont he wikipage itself.
*Coding together through this system would in many cases provide a huge boost in
productivity.
*Collaborative writing - In terms of writing books or papers, being able to see
these changes in real time is crucial.
*Online collaborative-notes for classes. As the instructor is lecturing, the
students can create and organize their notes, see the changes and notes the
other students are creating, etc. At the end of the class, the result should be
an impressive document covering all the relevant material discussed in that session.

Real-time is the key here. Possible implementation methods include an ajax
front-end with a java backend, active-x (yech), flash, or some other as yet
unnamed method.

It should be built as an extension to the current mediawiki project, as an
optional method for editing the text, ie.

Edit:
*View other's edits in real-time
*Edit alone

So we don't alienate people who feel uncomfortable or annoyed with this
methodology, yet allow those who would take advantage of the feature to do so
without jumping through additional hoops.
Comment 1 Omegatron 2005-08-06 02:09:11 UTC
"Rather than discussing changes in one window and then implementing them in another"

There would then be no record of the discussion?
Comment 2 Melancholie 2006-04-28 04:19:43 UTC
It's not exactly what you want, but on [[fr:]] they use a JavaScript tool that lets you 
previsualise your changes pretty fast and easily, without having to submit the changes to the 
servers first (preview button). But it does not work in real-time, so this is just a minor note.
Comment 3 Minh Nguyễn 2006-04-28 06:12:11 UTC
As a first step, it would at least be nice for the edit page, after (say) 15
minutes, to check with the server and see if the page has already been edited.
If it has been edited, the page could then automatically display a note and
diff, so that the user will know beforehand about the edit conflict and not make
things worse by continuing to make changes. The ping interval should be long
(and probably configurable), so that the server doesn't get bogged down by a
bunch of users who forgot they had that other window open. :)
Comment 4 Mark A. Hershberger 2011-05-15 00:27:58 UTC
http://hackpad.posterous.com/live-editing-mediawiki-with-hackpad looks fixed for me
Comment 5 Bawolff (Brian Wolff) 2011-05-15 18:34:31 UTC
(In reply to comment #4)
> http://hackpad.posterous.com/live-editing-mediawiki-with-hackpad looks fixed
> for me

Have you tried it? Well its a step in the right direction, I wouldn't exactly call it usable by the general public [or perhaps it just sucks on my browser]. But really this is a dupe of bug 4427
Comment 6 MZMcBride 2011-05-17 05:18:41 UTC
This isn't fixed in any real sense. Re-opening.

(In reply to comment #5)
> Have you tried it? Well its a step in the right direction, I wouldn't exactly
> call it usable by the general public [or perhaps it just sucks on my browser].
> But really this is a dupe of bug 4427

That bug would be a duplicate of this one, if anything. This bug came first.
Comment 7 Bawolff (Brian Wolff) 2011-05-17 05:21:55 UTC
*** Bug 4427 has been marked as a duplicate of this bug. ***
Comment 8 James Forrester 2014-07-04 00:37:14 UTC
Renaming so people find it.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links