[ckan-dev] New CREP: Moderated Edits User Interface
Seb Bacon
seb.bacon at gmail.com
Wed May 25 10:39:29 UTC 2011
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.
>> 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".
>> 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.
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.
Seb
More information about the ckan-dev
mailing list