mobwrite and undo or revert

[Brian Slesinsky]

I started out with a simple form to edit a document with Save and
Cancel buttons. After adding mobwrite, I'm no longer sure about what
these buttons should do.

It's automatically saving, so Save is really Send or Publish or Take
Snapshot. And instead of Cancel, I think maybe I need a Discard Draft
or Revert button, or perhaps a way to revert to any previously saved
version, like in Wikipedia.

So the first question is how to implement Revert. I think I need a
Javascript function that sends an "R:" request in the protocol.

However if someone else is editing the doc at the same time, reverting
it on them without warning or a chance to veto seems rather
unfriendly. It seems like I'm missing something here. What are typical
UI actions for collaboratively edited documents?

[Neil Fraser]

2009/11/13 Brian Slesinsky <bsles...@gmail.com>:

There's very little change, it's still just submit and cancel.

The submit button does one final sync (ideally this would be done
automatically by onunload, but webkit breaks this when using JSONP
connections, so this needs to be called manually), then sends the
current contents to the server. If the server is paranoid about
getting race conditions on the final submission, it could ignore the
user-provided content and fetch it directly from MobWrite.

The cancel button should simply set:
mobwrite.nullifyAll = false;
Then leave the page (doing a final sync in the process). As described here:
http://code.google.com/p/google-mobwrite/wiki/WebClient
If another user is still editing the page, then their next sync (or
submission) will repopulate MobWrite seamlessly.

--
Neil Fraser, Programmer & Wizard
http://neil.fraser.name

[Brian Slesinsky]

Okay, it sounds like that will work well for making sure that the
single-user experience is the same as if mobwrite weren't there.

However, it seems like this could be surprising if you don't realize
that someone is editing a document.

Scenario:

User A starts editing the end of the document with some changes that
aren't ready to commit yet.
User A goes to lunch with changes uncommitted.
User B goes to the document and doesn't realize it's already being
edited.
B makes a simple spelling correction at the top of the document and
submits it, without even scrolling to the end.
As a result, User A's changes get submitted prematurely, and they're
attributed to User B.

Some ways to fix it:
1) make sharing something you have to explicitly turn on, so you can
make your change without disturbing someone else's edits.
2) don't have a publish step. All edits are immediately live.
3) have a preview step before publishing, with a way to roll back any
changes you don't want to publish yet.
4) warn the user when someone else started editing the document first
and provide a way to see what they changed.
5) annotate each change with all of its authors
6) use a very fine-grained history so each edit has one author

I believe Writely does 1 (only one person can edit by default), 2, and
6. Wave does 2, 4, 5 (at the blip level), and 6. For development you
can have 1 and 3 (via code review after sharing is turned off).

This doesn't seem like a simple drop-in addition to a form anymore.
Sure, the integration is easy but the user experience is very
different and requires some thought.


On Nov 13, 11:27 pm, Neil Fraser <r...@neil.fraser.name> wrote:
> 2009/11/13 Brian Slesinsky <bslesin...@gmail.com>:

[Mikey]

Heya!

Everything that you mention here is all to do with how the information
is displayed to the users. It doesnt really have much of an impact on
mobwrite system itself. I think you already understand this from your
suggested fixes. My point is that any scenario can be easily fixed to
accommodate mobwrite (real-time collab).

fix 1) While is valid, It isn't real-time collab. And so has very
little to do with mobwrite. If you want your client to support this
then just impliment GET/PUT/LOCK/UNLOCK ? That said, Authorization and
Authentication support is something desirable, which would mean you
can select who can edit and do what to the documents.

fix 2+3) Mobwrite is always live. the "submit" button is for users to
double-check there changes have been made. A publish step might move
the mobwrite document into a "published" location (live webserver?).
Because you have the mobwrite document and you know where its going,
you can diff the two, and show the user whats going to be changed when
published. The user might be given some checkboxes next to the list of
changes so they can select which bits to include and which bits not to
include. So the spelling correction can be done instantly, while user
A's stuff can be ignored. This is however specific to your
application, Its something that your client should handle outside of
mobwrite.

fix 4) is a bit tricky. To tell what changes have been made requires a
point of reference. Keep one and show the users a list of patches that
have been made to the live mobwrite document (something i plan on
doing). It opens up a whole new set of problems tho. If i "uncheck" an
edit, does it vanish? off my patch list too? If no, you now need 3
points of reference (original, mobwrite document, clientView document)
etc. Making patches becomes a whole lot harder!

fix 5+6) Yep could do, this is closely related to colouring and
highlighting. Something already in the pipelines. But doesnt really
solve your scenario on its own.

Mobwrite is a method of synchronizing data. Yes, these things listed
above cannot be done with a simple form, they are all specific to your
application. While mobwrite does offer some editors, they are in early
stages of development. The examples are more to show you what you can
do to your web pages using mobwrite. Any input element can be collab'd
using mobwrite.

As for the other bits.

Submit = Force Mobwrite Document Sync.
Cancel = Delete current document (as neil said, if another user is
editing it, they "recreate" automatically)

I take "Revert" to mean to different things.

Do you mean, completely remove all edits? If so, you again need a
point of reference. And you simply replace the mobwrite document with
the original it was created from.

If your talking about "Undo/Redo". First you have to decide who's
edits are you going to be undo'ing and redo'ing? With the Gedit
plugin, the undo/redo function only changes what the current user has
typed. All changes from other users can not be "undone". It made the
most sense for me, as i intend to list all changes from the original
in a list at the bottom of the page, so when typing the user only
affects there content, but still has the option to undo/redo ALL edits
made on the document. but depends on your application.

Mike

[Brian Slesinsky]

On Nov 20, 6:42 pm, Mikey <mikey...@gmail.com> wrote:
> Heya!
>
> Everything that you mention here is all to do with how the information
> is displayed to the users. It doesnt really have much of an impact on
> mobwrite system itself. I think you already understand this from your
> suggested fixes. My point is that any scenario can be easily fixed to
> accommodate mobwrite (real-time collab).
>
> fix 1) While is valid, It isn't real-time collab. And so has very
> little to do with mobwrite. If you want your client to support this
> then just impliment GET/PUT/LOCK/UNLOCK ? That said, Authorization and
> Authentication support is something desirable, which would mean you
> can select who can edit and do what to the documents.

That's something else altogether. What I meant was that if you turn on
sharing with a menu item (as we are doing it in the IDE plugins) then
you're not surprised to see that someone else is changing the
document, because you turned it on. In a form on the web, we don't
expect this to happen and it will be an unpleasant surprise if it
happens without warning.

My main point was just that in its current state, you probably
shouldn't enable Mobwrite on a form without thinking about how it
affects the UI. There's more to it than that.

- Brian