[ckan-dev] New CREP: Moderated Edits User Interface

[Seb Bacon]

On 25 May 2011 23:49, David Raznick <kindly at gmail.com> wrote:
>
>
> On Wed, May 25, 2011 at 11:39 AM, Seb Bacon <seb.bacon at gmail.com> wrote:
>>
>> On 25 May 2011 10:34, John Glover <glover.john at gmail.com> wrote:
>>
>> > @ Seb
>> >
>> >> 1. I can imagine a moderator would want to quickly flick between
>> >> versions, simulating edits over time, then stepping back again.  For
>> >> this, it might be handy to have a view of the history that is
>> >> horizontal, which suggests the passage of time better, and with prev /
>> >> next change links, so I can just keep pressing "next" and incrementing
>> >> the version.  Something like:
>> >>
>> >> <- prev  24/05/11 *25/05/11* 27/05/11 next ->
>> >>
>> >> This might be in addition to the RHS vertical nav, or possibly instead.
>> >
>> > That is interesting, we hadn't really considered that so far. I'll
>> > mock something up for it.
>> >
>> >> 2. It would be nice to include some more visual clues to help
>> >> highlight the changes.
>> >> a) Perhaps fields that have changes would be highlighted, and fields
>> >> without changes not highlighted (making the "matches 24/05/11 Name" in
>> >> such fields redundant)?  The highlight colour would match a similar
>> >> highlight colour behind today's currently selected date in the
>> >> revision navigator(s).
>> >> b) Something visual for the "use this value button": perhaps the
>> >> button includes an arrow pointing upwards towards the field, and the
>> >> text says "copy this value"?
>> >
>> > a) Yes good idea, I don't think that the 'matches' line is ideal really.
>> > b) I had considered that but thought that it might make the area start
>> > to get a bit too cluttered, but I'll see if I can find something
>> > suitable.
>>
>> Cool.  I don't think it needs to be cluttered, just that the button
>> should have an arrow pointing upwards.
>>
>> >> 3.  You're perhaps going to need a visual state to indicate a field
>> >> that's been changed since the last moderated edit.  E.g. if the Title
>> >> was "Old Expenses Title"; I change it to "New Expenses Title"; then I
>> >> visit another revision with the title "Another Expenses Title"; should
>> >> there me some indication that not only the currently viewed revision
>> >> has a different value, but I've already changed it since the last
>> >> moderated version?
>> >> Perhaps a small icon to the right of each dirty field that requires a
>> >> logical save?  Not sure what this could be.  Perhaps not necessary,
>> >> but I feel like I'm on to something :)
>> >
>> > I'm not too sure about this one. The idea of the shadow field is to
>> > allow you to compare your current changes with a given revision, it
>> > might be getting a bit complex at this stage to compare changes
>> > between more than 1 revision.
>>
>> I'm not sure either :)  I didn't mean to compare multiple changes,
>> though: just to indicate that you have edited a field.
>>
>> It could be useful data if you are skipping between lots of different
>> versions to give an indication that you have *already* edited a field.
>
> I think to have a sign showing what you have changed is a really good idea.
>>
>> >> 4. On the same theme, by default the last of the revisions shown in
>> >> the RHS navigation should probably be the last moderated revision,
>> >> with a link to "show older revisions" which expands the list to all
>> >> revisions.  This would make it clear that the point of the page is to
>> >> review changes since the last moderated revision.
>> >
>> > We're intending this page to be for everyone editing the page, not
>> > just a moderator, so there may be several changes that are newer than
>> > the moderated/approved version. I think that the hope is that the
>> > community can do the majority of the work with the moderator just
>> > stopping by to look at changes without having to do too much extra
>> > work. Although in my mock up the most recent change has been
>> > moderated, we're not assuming that the newest changes will always be
>> > approved, so we thought it made more sense to show the newest first.
>> > This is still up for debate though, and of course we could still just
>> > show the latest revision (moderated or not) that can be expanded to
>> > 'show all revisions'.
>>
>> Ah, OK, that makes it a little bit different then.
>>
>> As per previous comments, I think we need to make a clear visual
>> distinction between a moderated and unmoderated version, beyond an
>> asterisk or something -- e.g. an unmoderated version that has a
>> previous moderated version could have a banner along the lines of
>> "this is the most recent community edited version of the resource.  to
>> see the most recent moderator-approved version click here".
>
>
> This should say 'to compare it against the latest moderator approved edit
> click here'.

I'm thinking of the casual visitor to the site, who just wants to have
some confidence they're seeing reliable data (Avril at
http://wiki.ckan.net/User_Stories).

I'm not sure they want to compare things to other things.  They just
want to know someone says "this is approved".

> I think that the moderator should just have the shadow fields default to the
> last approved edit.  I do not think the community editors should though.
> They should *not* be too concerned about what the latest approved edit is,
> they should just be concerned with improving the latest community one.
> Community edits should be as much like wikipedia as possible in my opinion.
> They already will have access to a preview (the preview button) and perhaps
> we should add some kind of overall diff too comparing their change to the
> last edit?

Something like this seems right to me.

>>
>> >> 5. Although this is technically just another flavour of an
>> >> edit-and-save operation, I think it should have some clear visual
>> >> indication at the top that this operation is going to end with a
>> >> *moderated* / "official" version.  The top title should say "moderate
>> >> data package", there should probably be a short banner with some
>> >> inline help (e.g. "Use the revisions panel to navigate between
>> >> suggested changes", etc), and the save button at the bottom should say
>> >> something like "save moderated version".
>> >
>> > Even if the user that is logged in is a moderator for the current
>> > package, they still might want to save a revision without labelling it
>> > as approved/moderated (see David Read's point from the previous
>> > email). But yes it certainly needs to be clear that they are saving a
>> > moderated version, either by having a separate button or by requiring
>> > them to tick a checkbox that will have a suitable message beside it.
>> > We could also put some sort of banner at the top to say 'you are a
>> > moderator for this package' or something along those lines though,
>> > maybe with a 'what does this mean' link that shows a help page or
>> > something similar?
>>
>> I do think the act of moderating should be clearly disambiguated from
>> the act of editing, even if the underlying operations are almost
>> exactly the same.
>
> I am not sure that I agree here, as it is good to think that the community
> edits as moderating also.
>
> I do not see any difference between the two actions except for the moderator
> gets to also mark the revision as approved.

The difference (in my mind at least :) is that quite often a moderator
will just be approving versions, rather than creating new versions.
Hopefully the community will be ensuring that the latest version is
reliable, like they currently do on Wikipedia.  The moderator would
just be freezing a known-good latest version.

That's why I thought the two operations would be worth disambiguating.

> There should be an approval revision as well to show this even if there has
> not been any change from the last community edit.
> If we do not make this, the revision history will loose information as to
> what was made approved when.

Does that matter?  If version B was last edited on 3rd March, that's
all I need to care about.  It doesn't matter when it was approved...
does it?

> I am personally for the two button approach for the moderator, one for add
> this as a community edit and one for mark this edit as approved.  The second
> one having a popup to ask if you are *sure* that you want to accept this
> revision as approved.  This popup should probably also have the package
> preview (or diff from last moderated edit) in it too, to show what is being
> approved.
>
>> e.g. perhaps a moderator would always save & edit a document like any
>> other editor, but then would assert "make this the current moderated
>> version" through a separate UI component, e.g. a button next to each
>> revision.
>
>
> I do not like the idea of putting a button next to each revision to mark it
> as active.  It is much cleaner to have a linear editing path.  I do not
> think an old edit should be made approved only the latest one.
> I also do not like it because the moderator could click on any revision as
> the approved one without even looking at the edit itself.

That is a good point, I guess the "approve" button should be at the
bottom of the form.

> This is just my opinion on this of course...

Me too

Seb