Based on the Refactor revisions to use a version control system proposal changed, I post this proposal.
The problem
Core only allows the first user that sumbit the node form to save the changes; so the others have to see the saved node again and manually make the changes, hoping no other user save it before he does it. Clearly, it's a really slow way to make a contributed document.
In 2006's edition of Google Summer of code a student made collaborative_editor module, giving this facility. But I think it's not so good managing revisions.
During this Summer of Code, I want to make the simultaneous editing better, using the better tool I found in my research. The initial list of posibilities to handle the changes include: some VCS, COMET, AJAX(used in the module).
Why?
Drupal is growing up and it is being used to different kind of websites, but it's not widely used by wikis. So it is a potentially new group of users who can make grow up Drupal still more.
Simultaneous editing improve user interaction inside a web, which is a notably a usability feature, which is one of the planned improvements goals in Drupal 7.
Reactivate the life of the collaborative_editor module developed on GSOC 2006, that actually has no activity.
Comments
do you want feedback?
I was looking into this myself, and there are a few things that I find unclear in your proposal. First question I have is, what is the better tool?
I think there are several challenges that I ran into on this project, and I would be happy to go over them with you. I think it would suck that you engage on this project for awhile, and then just discover that your original goals were ill defined, and that the goals you have chosen are in fact quite challenging.
I never saw the collaborative editor as trying to be a wiki. I think of those things as different things, and thats really the main issue I see with your proposal. It seems like you have set your goal is to combine 3 things, real time, wiki, and drupal. Trying to combine any 2 of those has yet to be done (I think) and is a project in and of themselves.
I actually have no idea how the SoC works, so I don't know what you are looking for atm.
Why not?
Why not just do some collision detection and alert someone when another is doing editing?
Could also have a time out so if someone walked away for too long it would pop up a warning to them and in another bit of time log them out of the edit form and then notify others waiting in the cue?
Seems simple to me! Though admittedly I've not installed the wiki module in question ... this is just a quick thought!
Maybe for a more live interface you can treat the different tags or classes... etc with collision detection, so any given user only has control of the paragraph or lines they are editing.
What is the granularity of
What is the granularity of changes you want to track? Paragraph? Sentence? Line?
Simultaneous editing is rather cool and definitely useful, but using a VSC is an overkill (IMHO), even if you want to support a distributed undo.
Some collision detection and signalling between different editors + the current or improved revision system should be sufficient.
Having said that, the current collaborative editor is stale, needs lots of tlc, which probably will make it smaller and simpler, since drupal has jquery on the client side now.
Hmmm... So many ideas
Hmmm...
So many ideas here...
Here is a wiki by a friend that uses mercurial to track changes:
http://dandelion.sheep.art.pl/
I am thinking that this could also be a possibility for Drupal, too. That revisions could go to a small revision control system like hg. Thoughts?
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
sure, many ideas
I think revision control should be kept apart though.
"the editor" implies online, simultaneous collaborative editing. Probably it is better to keep it as simple as possible. Sure with dvcs you will be able to have more sophisticated undo, but do you really care about that? I know I would get confused.
Letting some cats out of the bag?
I think this project does not have hope for success, mainly because you are going head to head with Google on this one. I know this because when I was tacking a stab at this project, I contacted the developer of another project with the same goals as this one, except that it wasn't connected with Drupal. His project was Mobwrite, and I took a stab at connecting it to Drupal. It was a boring pain to do so. Browser bugs would just pop up out of nowhere, and I had no clue where the actual documentation was for the features I was using, which left my kinda flailing about trying to fix the bugs. I did fix them, in a totally hacky manner. I eventually decided that the features gained was not worth those hacks to get them working.
Anyway, I learned two interesting things, emailing the dev of mobwrite:
a) the problem of syncing html data (which has a tree structure) is very difficult. In his project, he simply by passed the problem by converting any html tags to their escaped text counterparts. I realized that this must be the reason why wikis use a custom markup (without tree structures), rather than html.
b) He had just been hired by Google to work on the very problem described in point a.
So, Google is working on this project, just not for drupal. [Cue Microsoft effect] Why would you want to code a project that at best, could match the features of Google's version, but would be at a disadvantage being unable to interoperate with the rest of Google's software. [/Microsoft effect]
Additionally, is this project really in line with the direction that drupal is going? I ended up figuring that if I really wanted a wiki, I should just install a wiki.
So, there are the strikes against this project that I see. I don't think this project needs TLC (Tender Loving Care), but TLFA (Tender Loving Funeral Arraignments).
google-mobwrite
danbh - Seems like Google has released the project you're referring to. Having read your comments above, I still think it would be valuable to write a new module that you can integrate into Drupal content types configurably.
http://code.google.com/p/google-mobwrite/
This would allow content managers to co-contribute to a page/story/whatever simultaneously. I've found this type of real-time collaboration to be useful on several occasions recently while working with others in Google Docs.
Any new thoughts?
:o
Thanks for pointing this interesting project, I made a new proposal on Soc2009 :D
Synchronous edition in Drupal with google-mobwrite
Seems worth reviving.
Seems worth reviving.
quoting webflo(another
quoting webflo(another alternative):