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

Thu May 26 11:48:51 UTC 2011

On Thu, May 26, 2011 at 11:37 AM, Seb Bacon <seb.bacon at okfn.org> wrote:

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

The package "view" page will default to have the latest approved edit of
course.  The package edit page should not be a concern or viewed by Avril at
all.

Personally I think the package view page needs the most amount of work
concerning its general appearance.  It is currently much clearer to look at
the edit page to see information about a package.  To the point where it
seems like people forget the view page exists!

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

I am coming around to this too.

>
> > 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 quite happy for it not to matter :)  We will loose this date from the
too database too which I was worried about.

This has an effect on how I do the revisioning, so its an important point to
me.  I think this is a decision now, as I agree.

>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110526/e322f8a4/attachment-0001.html>