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

John Glover glover.john at gmail.com
Wed May 25 09:34:10 UTC 2011


Thanks for the feedback guys.

@David

> If I understand this right, when you click on a revision (right hand
> side), the shadow boxes (under each field) take the values from the
> revision, or say "Matches xyz value".

Yes that is the idea at present, although the 'maches' line might not
be necessary.

> Is it the case that as soon as a user starts editing a field, the
> "Matches xyz revision" message is deleted and is replaced with this
> frame showing the old value? This change might be distracting, what
> with the frame being bigger and the rest of the form having to move
> down to accommodate it. What about a sort of floating speech bubble
> popping up with the previous value? If it was positioned North of the
> edit field, it probably wouldn't cover up anything relevant to the
> field. It could have an "x" button to dismiss it and the 'revert to
> this value' button. Or maybe this is all too tricky.

Interesting. That feels more like an autocomplete UI to me (which
might be your intention), where as this will not just be a value that
will be displayed when the user is editing a particular field, we
wanted a moderated to be able to scan down through a revision with
possibly several edited fields and be able to see all of the
differences. Do you think that the tooltip / speech bubble is
appropriate for this as well? I'm not so sure, but I could mock
something up for comparison if you like.

> I see you wavering between identifying the revisions as 1,2,3,4 or as
> dates. I think it is easier to understand if you show 1,2,3,4, and you
> may have more than one edit per date, which makes it confusing to know
> which one was first. Perhaps if the user mouse-hovers, they reveal
> their real hex Revision ID (just in case the user actually wants to
> cross-reference with the revision history page).

Yes I wasn't sure how to label them, I thought that having 1,2,3 might
be confusing as that only really refers to their order in the panel on
the right and is not an ID of any sort. So every time you reload the
page, Revision 1 for example could be completely different. I thought
that dates would be clearer, but perhaps with the UUID being displayed
on mouse-hover. What do you think?

> I guess when submitting, a moderator could be given the choice of
> denoting this revision as moderated or not (i.e. leaving moderation
> for later or another moderator). This could be a checkbox, a different
> button - lots of options. What do you think?

Initially I had thought of using another button, but I'm leading
towards having a checkbox now, as it would probably give more space
for adding a 1-liner with a description of what marking a revision as
moderated/approved implies, but I'm not particularly attached to
either option.


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

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

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

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


Thanks,
John




More information about the ckan-dev mailing list