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

Wed May 25 11:47:33 UTC 2011

> Cool.  I don't think it needs to be cluttered, just that the button
> should have an arrow pointing upwards.

I've updated the mockup in the CREP to include this and a couple of
the other changes: http://trac.ckan.org/ticket/1141, let me know what
you think. I couldn't really find a timeline visualisation that I
thought was suitable so I might need to put together a custom widget
for this, I do like the idea though.

>>> 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 I'll leave this out for now but we can always add it in later
after the basic functionality is complete.

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

That's what I had in mind when I mentioned the checkbox, which
together with its label would be in a separate fieldset, but I'm quite
happy to going back to having buttons beside each revision.

Thanks,
John