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

Wed May 25 22:49:06 UTC 2011

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 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?

>
>
> >> 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.

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.

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.

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

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110525/1947acb4/attachment-0001.html>