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

Thu May 26 11:52:45 UTC 2011

On 26 May 2011 12:48, David Raznick <kindly at gmail.com> wrote:
> 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.

Ah, OK.  I thought I remembered people saying that the "view" page
would be the latest edit, that's why I was going down this route.

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

Agreed :)

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

We can timestamp the approval anyway, even if we don't expose it...

Seb