Overwriting Page Logic

[opn]

Dragging and dropping a link / paragraph from one page to another results in a strange precedence logic in that the page dragged from is registered as the most recent change and over-writes the page where the content was dropped.

I have not tried reproducing this, but file this issue now to raise the general issue of over-writing the Welcome Visitors page which is the most common mistake / bug newbies face.

The sequence of events I just observed was:

1. Drag a foreign Welcome Visitors page to your site
2. Drag and drop a paragraph from the foreign Welcome Visitors page to your own Welcome Visitors page
3. Click on your Welcome Visitors flag to refresh the site

The result is that your own page has been replaced by the foreign Welcome Visitors page and all your content on that page lost.

[paul90]

I can't recreate this. Are you sure you are using the latest version of the client? Should be wiki-client: 0.7.7.

[paul90]

Are you sure you are not doing:

• Drag and drop a paragraph from your own Welcome Visitors page to the foreign Welcome Visitors page.

As that would have this effect.

[opn]

I was watching on a screen sharing session - so I can't be positive. I will
try to reproduce. The behaviour you describe is what I is what I would
expect.

On the other hand this general issue is the number one issue for newbies.
They lose data and the first data they write (as it tends to be the Welcome
Visitors page whatever we tell them :)

It would seem to me that we would be better off implementing a simple merge
strategy for the journal when overwriting a page:

1. Keep the common history of the pages (if any)
2. Insert the old pages extra history
3. Add the new pages extra history

I'm not entirely clear of the current history recreation code, and we may
need to reference a previous history item rather than assuming it is the
item before in the journal - but losing data is something that should never
happen?

On Saturday, 18 June 2016, Paul Rodwell [email protected] wrote:

Are you sure you are not doing:
2. Drag and drop a paragraph from your own Welcome Visitors page to the
foreign Welcome Visitors page.
As that would have this effect.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#164 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAE71oiAnE2tRhw214SxdwogjuvVHW9Jks5qM44zgaJpZM4I4lC1
.

[paul90]

In WardCunningham/Smallest-Federated-Wiki#431 (comment) @WardCunningham reflected that:

ALL implicit forks go to local storage. If they were accidental, then they could be discarded with no harm to the origin server. If they were desired, then an explicit fork from local storage to the origin server will save the page in a single (additional) action.

I don't think this was followed up on at the time. The underlying problem is really that it is possible to overwrite a page with an implicit fork. While there may be times when this has the desired outcome, it has consequences when it is not.

By making ALL implicit forks go to local storage, we can protect from the harm that the implicit fork to the origin server can cause. The user can always undo the action by removing the page from local storage, or do an explicit fork if that is what they really want.

[WardCunningham]

I'm sorry to see this useability trap rear it's ugly head again.

Our goal has been to allow organization to emerge by relocating paragraphs to pages later made to hold them once the subject of that page has been recognized. Thus dragging a paragraph from one page to another changes both.

The drag logic has been hacked to avoid self-destructive situations that occur when dragging a paragraph from an earlier revision of the same page.

The drag logic does not consider it an error to reorganize content held by another site. Should I decide that the organization of your pages could be improved by a move, I make that move and implicitly fork both pages to my own in the act.

By this second interpretation, two implicit forks to local storage should be expected when one doesn't have write access to the origin.

I am not in favor of abandoning refactoring, even for the often damaged welcome page.

I do see two improvements that have been discussed but remain unimplemented.

• Fix drag-and-drop refactoring to more cleverly choose, and make obvious the distinction, between move and copy.
• Save deleted pages and make them available to the owner as another kind of twin that can be recalled and then refactored or forked back into existence

The more we think of federated wiki as a tool to be used rather than an experiment to be performed, the more priority these improvements deserve.

Aside: This case has many similarities to the trap in unix where an accidental space in rm test* irreparably deletes all of one's files.

[WardCunningham]

After rereading @opn's initial observation carefully I can agree that the inopportune order of writes is likely the case. The logic in question is in handleDragging registered in refresh.

https://github.com/fedwiki/wiki-client/blob/master/lib/refresh.coffee#L49-L87

This function is called twice, once each for source and destination. The order of these calls is determined by jQuery-UI and is, as I recall, the destination first, then the source. Subsequent processing is asynchronous and thus subject to reordering.

The logic on line 67 tries to recognize and ignore the case where they are different copies of the same page. This is the hack I mentioned above.

[WardCunningham]

After rereading @paul90's suggestion I see it as a possible implementation of "Save deleted pages" that we haven't considered before.

Our url syntax includes three synonyms for the origin domain name, origin, local and view, where view means local if present, origin otherwise. I have been imagining we would add to this trash along with some server protocol to learn of and fetch from the store of deleted pages. But what benefit do we accrue by storing these on the server? Maybe none?

On further thought, Paul is suggesting that the newer page be stored local, not the page it is about to replace. We have some precedent for this when a page goes local when one forgets to login. But we also use ghost pages for Transport results that are not stored anywhere except that they appear in the lineup.

The user interface for deleting local pages is hidden in Local Changes, mentioned on Recent Changes, mentioned on Welcome Visitors. Ghost pages need not be deleted because they are not saved except in the lineup.

[opn]

I like ghost pages. They are innovative, and clear.

When overwriting a page of the same name by fork, or dragging an item -
then the page that is "deleted" but still in the lineup should be ghosted.
This is not as robust as storing deleted pages somewhere - but it is
probably good enough.

It has the advantage of:

1. Not keeping lots of dead pages around
2. Giving clear and simple visual feedback. Even the effects of the drag
   would become much clearer.

It may also prepare a precedent for deleting, or other modifications of
pages - show a ghost page before deleting - refork = undo. If we combine
this with closing pages in the lineup as per Clements patch = we have
deletion and undo within the wiki paradigm.

On Saturday, 18 June 2016, Ward Cunningham [email protected] wrote:

After rereading @paul90 https://github.com/paul90's suggestion I see it
as a possible implementation of "Save deleted pages" that we haven't
considered before.

Our url syntax includes three synonyms for the origin domain name, origin,
local and view, where view means local if present, origin otherwise. I
have been imagining we would add to this trash along with some server
protocol to learn of and fetch from the store of deleted pages. But what
benefit do we accrue by storing these on the server? Maybe none?

On further thought, Paul is suggesting that the newer page be stored
local, not the page it is about to replace. We have some precedent for this
when a page goes local when one forgets to login. But we also use ghost
pages for Transport results that are not stored anywhere except that they
appear in the lineup.

The user interface for deleting local pages is hidden in Local Changes,
mentioned on Recent Changes, mentioned on Welcome Visitors. Ghost pages
need not be deleted because they are not saved except in the lineup.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#164 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAE71hsAHBfs0Mht03nATjYh-pQKNJmLks5qNAaAgaJpZM4I4lC1
.

[WardCunningham]

@opn's most recent suggestion addresses the confusing situation when forking an earlier version (ghosted) from history leaves two conflicting versions side by side with no indication which is currently stored. Better to ghost any version that has become obsolete by an action elsewhere in the lineup.

Imagine browsing five revisions side by side. Fork any one and the others will relinquish currency by becoming ghost. There would be no other current page since none other would have the most recent fork action showing in its journal.