961188 - Add "show changes" button to pages when you have a cached draft

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: General, defect)

Description

[Eric Shepherd [:sheppy]]

What problems would this solve?
===============================
When you open the editor on a page for which you have a saved draft, it would be helpful if there were an option to let you see the changes made in your pending draft, so you can tell if you want to use it or not. Sometimes that draft is bogus, or very out of date.

This would be helpful and convenient, but could also help prevent accidental overwriting of newer revisions with old drafts.

Who would use this?
===================
Frequent editors of the site, mostly.

What would users see?
=====================
A button that would show a diff between the current revision and the cached draft.

What would users do? What would happen as a result?
===================================================
Clicking the button would show a diff between the current revision of the article and the cached draft, and ask if you'd like to restore the draft or remove it.

Is there anything else we should know?
======================================

Comment 2

[Jiri TRAVNICEK [:JITR]]

This is something I've been missing too, but my motivation is a bit different -- see bug 1030709.

However I think the proposed button name should be a bit different, because there's already a `Preview Changes' button. Having another button labeled `Show Changes' could become confusing, although this is precisely what MediaWiki uses. Relabeling MDN's buttons could probably also be a solutuion...

Comment 3

[Eric Shepherd [:sheppy]]

Yes, labeling needs to be figured out. Maybe a "See changes in draft" link?

Comment 4

[Jiri TRAVNICEK [:JITR]]

Well, I'm hardly the one to have a definitive word on this, but `See changes in draft' seems to be pretty clear to me.

For completeness: When I wrote my (duplicate) RFE in bug 1030709, I tried to come up with something similar to the existing `Show Changes' button and came up with `Compare Changes'.

Comment 5

[Akshay Aurora [:system64]]

Right now, the draft uses "Local Storage" API. And the diff's for document revisions are done at the backend. Doing the diff client side might be tricky.

We could probably use something like this – https://github.com/kpdecker/jsdiff 

If I can get some guidelines on the UI/UX for this, I'd like to give this a shot :)

Comment 6

[Eric Shepherd [:sheppy]]

Ideal scenario: clicking the "See changes in draft" link would open a lightbox type of panel that contained the diff, using a similar format to what we use on history revision comparison pages, with a "Close" button to close the panel and perhaps a "Use this version" button (wording should match what the main window's UX presents).

If the lightbox type of presentation isn't feasible, then do the same but on a new page.

Comment 7

[Eric Shepherd [:sheppy]]

(In reply to Eric Shepherd [:sheppy] from comment #6)

> If the lightbox type of presentation isn't feasible, then do the same but on
> a new page.

In this case, of course, "Close" would return you back to the editor where you were before.

Comment 8

[Akshay Aurora [:system64]]

Lightbox makes sense.

I think, :shobson is working on bug 1024649, which might give us a re-usable lightbox component.

Comment 9

[Luke Crouch [:groovecoder]]

Text diff output can be overwhelming since all our content is in HTML. The diff tool I'd love to use on MDN is daisydiff, which we use on localwiki:

http://localwiki.net/tulsa/TulsaWebDevs/_history/4...12

It shows diffs between rendered HTML really cleanly. Best tool I've found for it.

Comment 10

[Stephanie Hobson [:shobson]]

(In reply to Akshay Aurora [:system64] from comment #8)
> Lightbox makes sense.
> 
> I think, :shobson is working on bug 1024649, which might give us a re-usable
> lightbox component.

That bug isn't moving forward right now so I wouldn't wait for my work, I was going to see if we could re-use the CKEditor light box (that opens when you click add a hyperlink for example).

Comment 11

[Stephanie Hobson [:shobson]]

Rather than include a "see changes in draft" button I would add another option to the yellow box that appears when you have a draft along the lines of:

"You have a draft in progress. Would you like to _compare the draft_ with the current version, _restore the draft_, or _discard the draft_?"

Comment 12

[akshayaurora]

(In reply to Luke Crouch [:groovecoder] from comment #9)
> Text diff output can be overwhelming since all our content is in HTML. The
> diff tool I'd love to use on MDN is daisydiff, which we use on localwiki:
> 
> http://localwiki.net/tulsa/TulsaWebDevs/_history/4...12
> 

That diff looks beautiful!

I looked up daisydiff and its only in PHP and Java, still looking for something similar in python.
But I like the idea of rendered diffs.

For the diffs with drafts, we can probably do it client side or have some kind of backend API that takes in local draft and returns the diff with last revision. 

Not sure, which is the best way. Doing it only in python would require lesser maintenance and consistent diffs.

Comment 13

[Jiri TRAVNICEK [:JITR]]

(In reply to akshayaurora from comment #12)

> That diff looks beautiful!

Yes, it's gorgeous. :-)

Even if this would not be suitable as a client-side solution, I have a feeling this could be a nice upgrade for the existing diff implementation. ;-) Well, perhaps some time...

As for the client side, I'd be happy with whatever works reasonably. The jsdiff would probably do as well. Although an idea of generating *all* diffs server-side using a single implementation looks like it would also have its merits.

Comment 14

[Jiri TRAVNICEK [:JITR]]

(In reply to Stephanie Hobson [:shobson] from comment #11)

> Rather than include a "see changes in draft" button I would add another
> option to the yellow box that appears when you have a draft along the lines
> of:
> 
> "You have a draft in progress. Would you like to _compare the draft_ with
> the current version, _restore the draft_, or _discard the draft_?"

Yeah, that actually seems like an even more elegant solution of the problem. :-)

However this wouldn't probably work well for the use case I have described in bug 1030709. My concern here is that the `You have a draft in progress.' message is (if I have noticed correctly) only shown upon re-entering editing of the page and not necessarily during normal editing. I think this purpose would be better served by a (new) button.

Given the elegance of your solution I'd suggest to implement both, but that might be considered an overkill. In such case a compromise solution that could serve both use cases might be preferable.

Comment 15

[Stephanie Hobson [:shobson]]

Hm. I think this bug summary needs writing to take :jitr's use case into account.

This reminds me a lot of the request from the translators to be able to compare to a selected English version while editing. I think we can share UX with bug 1024649.

I don't want to add a 5th button to our current row of buttons. Let me sleep on the UX for this.

Comment 16

[Eric Shepherd [:sheppy]]

(In reply to Stephanie Hobson [:shobson] from comment #15)
> Hm. I think this bug summary needs writing to take :jitr's use case into
> account.
> 
> This reminds me a lot of the request from the translators to be able to
> compare to a selected English version while editing. I think we can share UX
> with bug 1024649.
> 
> I don't want to add a 5th button to our current row of buttons. Let me sleep
> on the UX for this.

That's a good point. I wonder if we need to rethink how the various "You're in edit mode, here are things that affect whether or not you're still in edit mode" features are accessed, either by switching to labeled icons or by moving some of the less-used items into a little drop-down menu, or...?

Comment 17

[Luke Crouch [:groovecoder]]

localwiki is also a python + django app. We run a daisydiff java sever behind django and use its API to get the rendered diffs.

Almost exactly the way we use kumascript now. So it's very do-able, but we would need to get daisydiff approved by IT & WebOps.

Comment 18

[Eric Shepherd [:sheppy]]

(In reply to Luke Crouch [:groovecoder] from comment #17)
> localwiki is also a python + django app. We run a daisydiff java sever
> behind django and use its API to get the rendered diffs.
> 
> Almost exactly the way we use kumascript now. So it's very do-able, but we
> would need to get daisydiff approved by IT & WebOps.

Which would be nice because I've been wanting us to use daisydiff for all our diffs for like two years now. :)

Comment 19

[Stephanie Hobson [:shobson]]

Attachment: compare_open.jpg

Potential placement/wording for button to show changes to draft.

I would especially like feedback on the wording "current version, previous version".

Comment 20

[Stephanie Hobson [:shobson]]

Attachment: compare_closed.jpg

Button would be smaller until hover or focused on.

Comment 21

[Eric Shepherd [:sheppy]]

I'm not sure what to make of this proposed UX. It's a little confusing. There's no message here explaining that there's a saved draft in your local storage, for example, as there currently is in production, so the entire functionality of these buttons is muddled behind the lack of that information.

Ideally there would still be text along the lines of "You have a draft of this page saved on your computer" with buttons to "discard draft", "edit draft", and "compare to draft" (where the last option would compare the most recent revision to the locally-cached draft).

That last option needs a less awful name, but hopefully that makes the point.

Comment 22

[Eric Shepherd [:sheppy]]

(In reply to Stephanie Hobson [:shobson] from comment #19)
> Created attachment 8455427 [details]
> compare_open.jpg
> 
> Potential placement/wording for button to show changes to draft.
> 
> I would especially like feedback on the wording "current version, previous
> version".

Specifically -- it's important to note that this isn't about comparing what's currently in the editor to the last saved copy of the article, but about the locally cached draft from a previous editing session (such as one that was in progress when the browser crashed or the tab was accidentally closed).

Comment 23

[Stephanie Hobson [:shobson]]

> Specifically -- it's important to note that this isn't about comparing
> what's currently in the editor to the last saved copy of the article, but
> about the locally cached draft from a previous editing session (such as one
> that was in progress when the browser crashed or the tab was accidentally
> closed).

Sheppy, I was trying to address :jitr's use case. If this bug is only about the use case you mentioned (quoted above) Bug #1030709 should be un-marked as a duplicate.

Comment 24

[Eric Shepherd [:sheppy]]

(In reply to Stephanie Hobson [:shobson] from comment #23)
> > Specifically -- it's important to note that this isn't about comparing
> > what's currently in the editor to the last saved copy of the article, but
> > about the locally cached draft from a previous editing session (such as one
> > that was in progress when the browser crashed or the tab was accidentally
> > closed).
> 
> Sheppy, I was trying to address :jitr's use case. If this bug is only about
> the use case you mentioned (quoted above) Bug #1030709 should be un-marked
> as a duplicate.

Yeah, these are two totally different things. I've un-duped bug 1030709.

Comment 25

[Stephanie Hobson [:shobson]]

With Bug 1030709 being separated from this one again it sounds like the interface change I proposed in Comment 11 is still appropriate. If this feature gets added to the staff deliverables or if a contributor wants to work on it and more interface direction is needed just needsinfo me again :)

Comment 26

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.