Usability Issue: Simulataneous Editing Of A Page

[Petrus4]

Ok this has been mentioned before, but since it is very important to me and to my users I am creating a unique thread for it.

The Deki handles simultaneous editing of a page by showing the following message to the last user who closes saves his/her edits.

• You have successfully created a new page, but you overwrote an existing page. You may want to compare the differences between your page and the old page and edit some of the changes back in.

You get to compare the differences by seeing your changes color coded alongside the changes that where made after your opened the page for editing.

This is experienced as very confusing to my users and myself, it is not clear which color codes apply to which changes. (this could be clarified in the above quoted message). If the user then wants to copy his/her own changes and then paste these changes into the old page, the user has to remove the color coding from the text.


This process becomes even more complex if a user has made major edits on (for example) a table with a lot of data. The user would have to spend a lot of time redoing their work which is very de-motivating as far as getting user to use the Wiki. It is also not fair to the users not to be warned before they start to edit a page that another user is editing the page, if they were warned they could make a choice to wait etc.

I am curious if anyone has good ideas on how this can be done in a more user-friendly manner.

SteveB suggested this:

For page editing, we already merge overlapping edits when different sections were edited. But we can do better than that. The right approach, imo, is to merge changes from multiple editors seamlessly when possible and show a merge-conflict view when a problem was detected.

I think this is a great idea... though the "merge-conflict" view would need some improvement. For example the possibility to save this view as the current page and then edit the conflicts.

PBWIKI does this:

They let the user trying to edit a page that is being edited know another user is editing the page with the following example message:

SteveB [steveb@mindtouch.com] from 68.15.8.102 is currently editing this page but has been for more than five minutes (really 32 minutes). This means it's possible that they clicked 'Edit' without ever actually following through on an 'Update'. Do you want to steal the edit lock from this person? This may cause the other person's changes to be lost.
Steal Lock

This imo is great information. It tells me who is editing the page, so I could contact them. It also tells me how long they have been editing the page, which lets me know if it may be safe for me to edit the page. And it gives me the option to " Steal Lock" or remove the lock the other user has on the pages.


Any other suggestions?

[Petrus4]

I am bringing this one back,

are there any plans to change the way simultaneous edits are handled?

[ally]

Hi!

On my Wiki (Hayes 1.8.3c), users can work on many pages at a time and sometimes they can edit the same page... Despite the measure described, I want to know if there is some way to prevent the simultaneous edit of a Wiki page by denying access to all users who subsequently like to edit it?
This way only the first user can really edit that page, others trying to edit will be refused access (e.g. a message displayed). Can anyone shed some light or propose some viable solution?

[SteveB]

Simultaneous page edits are merged at the word level and now cause conflicts very rarely.

[jsprenger]

We updated our Wiki to 1.90b and tested the conflict resolution, which does not seem to do the merge as suggested.

Here's the basic test we performed:

Created 1 page, with two Heading1 sections, each with 3 bullet points underneath. Then we performed these actions:

- User1 edits Head1 section
- while User2 edits Head2 section.
- User1 saves
- User2 saves

Instead of merging, deki wiki reports that User2 has overwritten the page and needs to compare and make appropriate edits. I would have thought that the wiki would merge in the new bullet items into each section.

Before Edits and Save:

Head1

• Aitem1
• Aitem2
• Aitem3

Head2

• Bitem1
• Bitem2
• Bitem3

After (as it should have been)

Head1

• Aitem1
• Aitem1b
• Aitem2
• Aitem3
• Aitem4

Head2

• Bitem1
• Bitem1b
• Bitem2
• Bitem3
• Bitem4

** The red items were erased when the User2 saved.

Config Details: Deki Wiki 1.9.0b (rev. ) running on: Linux 2.6.9-67.0.7.ELsmp, PHP 5.1.6, mySQL 14.12 distribution 5.0.54, and Mono .

[SteveB]

Thanks for the detailed report. That's definitively not how it should have behaved.

I filed a bug on it:
http://bugs.opengarden.org/view.php?id=3716

[gen0]

We've also experienced the problem jsprenger has described in the version of DekiWiki we just downloaded. I'd like to point something out, in case it may have been missed here:

*** This bug causes DATA LOSS! ***

In a situation of simultaneous edits, the first editor's changes are lost. They are not even saved in the page's edit history.

I would have thought this would be unacceptable for a collaborative application like Deki Wiki. Yet I notice the bug that SteveB has kindly created has been changed from a Target of "1.91" (ie next version) to "future" - indicating it's not really an urgent priority.

It's your project guys, and it's up to you how you run it, but we just chose another Wiki because of this issue alone. And I think that's a shame because you've got a great application here.

[SteveB]

gen0, thanks for calling us out on it. It's a rare occurrence, but it's a devastating one nonetheless. You'll be happy to hear that your rant didn't go unnoticed. The issue has been addressed and the fix will be part of the upcoming "Jay Cooke" v8.05 release.

Here is the original bug report:
http://bugs.opengarden.org/view.php?id=3494

[gen0]

That's great news. Looking forward to your next release!

[jsprenger]

I have run the simultaneous edit/merge test (previous post), and I can happily confirm that the test passes in version 8.05 (Jay Cooke).

Thanks for the fix. Our users are delighted.