'metadata' pattern improvements

[brandonrosage]

As we march toward making more (or nearly all) of a post's metadata editable, it's becoming increasingly important to have a reasonably consistent way to both display and edit across contexts, including:

• Postcards
• Post detail
• Post: Edit

Today, when a user transitions from viewing a post to editing it, they go from seeing the post's metadata presented immediately below the post's title...

...to seeing it abstracted into a 'toolbox' outside the form sheet:

I propose we bridge this gap by establishing a more dynamic "metadata' pattern that can handle status, author, date, and source information that's view-only and editable.

The idea is that, with this change, when a user transitions from viewing a post to editing it, they see the post's metadata in a uniform location and structure from its view-only presentation to its editable presentation:

When editable, each "chip" of information is clickable and reveals an appropriate module. If the chip must reveal a set of one-click actions, like switching to a different status, it'd display a "mainsheet":

If the chip must reveal a complex set of editing options, like selecting an author or defining post date & time, it'd display a modal:

---

@caharding said:

I do find the dropdown a little bit confusing a cluttered. Could we not use a similar drop down like we use on the "mode context" survey dropdown?

The reason the chips don't have a uniform dropdown (like those used on the survey filter) is that the actions 'underneath' them vary wildly in their complexity. Editing a post's author, for example, must allow the user to do any of the following things:

• Select an author from a list
• Search the deployment's existing users
• Provide a "custom author," which when selected, accepts name and email values (in its own window; see below)

I think trying to package all of that functionality and workflow into a single, compact dropdown menu is going to be clumsy and cumbersome. It's not really what that pattern is for.

---

So, any more feedback? I'd particularly like @jshorland, @caharding, and @rjmackay's feedback on this solution. I want to know if y'all think it's a reasonably elegant balance of the stated challenges:

• Maintain a reasonable amount of consistency in the appearance of a post between its viewable and editable states.
• Provide a unique and appropriate visual treatment for metadata within the overall survey form.
• Make the available actions reasonably discoverable.

[jshorland]

Wow you've put a lot of really good thought into making this as elegant as possible. I REALLY like the transition to chips.

I wasn't intuitively aware that chips were "clickable", especially not that there's so many powerful actions I'm able to perform by clicking on them.

In the pattern you've staged, one of the chips says "2 days". If I try to turn my own product knowledge off, I'm not entirely sure what that means. Is it two days old? Do I need to respond within 2 days? IS THERE A DUE DATE I DON'T KNOW ABOUT!?

And finally, in the longer term, I think this transition allows us to expand on things like custom tags, etc, Will there always be an action associated with every piece of potential meta data though? And if not, how are we going to make it clear when there is an action the user can take by clicking on it, and when there's not?

[caharding]

Very happy with this solution. Thanks Brandon.

On Mon, Sep 19, 2016 at 12:01 PM, Jess Shorland notifications@github.com
wrote:

Wow you've put a lot of really good thought into making this as elegant as
possible. I REALLY like the transition to chips.

I wasn't intuitively aware that chips were "clickable", especially not
that there's so many powerful actions I'm able to perform by clicking on
them.

In the pattern you've staged, one of the chips says "2 days". If I try to
turn my own product knowledge off, I'm not entirely sure what that means.
Is it two days old? Do I need to respond within 2 days? IS THERE A DUE DATE
I DON'T KNOW ABOUT!?

And finally, in the longer term, I think this transition allows us to
expand on things like custom tags, etc, Will there always be an action
associated with every piece of potential meta data though? And if not, how
are we going to make it clear when there is an action the user can take by
clicking on it, and when there's not?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1399 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABizaXADkny3uFAf8Pyn-VBBKzHXJOAMks5qrtwdgaJpZM4J-YPC
.

Charlie Harding
Product Director

[rjmackay]

Just checking, is this the current iteration of this in the PL? http://preview.ushahidi.com/platform-pattern-library/f-metadata/assets/html/5_layouts/post-edit.html

• When I click the status chip, the dropdown appears but theres no way to cancel. Its not clear if the existing Cancel and Save buttons will save the entire post or just status?
  • Can we disable/hide the post Cancel/Save buttons for any chip dropdown
  • Can we add a cancel button to the status dropdown?
• I agree the "2 days" chip is confusing.
  • In the current client we actually vary the date display depending on how old it is, you'll see either "Sept 1, 2016" or "6 days ago". The "ago" helps but probably isn't a complete solution.
• I'm not sure if its clear the chips are actually editable - this might be overkill - but should we user test this?

[brandonrosage]

I've made some revisions to the 'metadata' pattern, as well as the 'chips' and 'mainsheet' patterns that are connected to it.

First, the visual appearance:

Chips

Chips now share more visual DNA with buttons, so they appear even more clickable. They also have an optional treatment for labels, icons, and avatars. So, for example:

Chip, with text:

Chip, with text and label:

Chip, with text and avatar:

Chip, with text, label, and avatar:

Chip, with text, label, and icon:

Chip, with 'alpha' treatment:

It's used here to call out to the user that the post isn't published and requires review.

Metadata

The presentation and markup used for the 'metadata' is even more consistent than before, making it easy to mix editable data items (chips) with non-editable ones (plain text):

As seen on 'Postcard,' where none of the items are editable:

As seen in 'Post: Edit,' where one or more may be editable

Mainsheet

I've revised the 'mainsheet' window so that it shares more DNA with a modal, and less with a toolbar or datepicker. To that end, on larger screens, it appears in the middle of the user's screen (rather than up from the bottom).

It is unlike a modal in its purpose and function, however, which is why it's a unique pattern -- despite its style looking a lot like a modal. That purpose is to provide a two-click path to completing a task: Click once to edit and once more to select your choice. Done.

This is useful for things like submitting a new survey from the "+" button, where we ask them first to indicate which survey they want to submit (in the event there are more than one). It's also useful for toggling between options, like post status. No third click required to confirm. Keep it as fast as possible.

In the event that a mainsheet is invoked, but the user wants to dismiss it, they can simply select an area of the screen outside the mainsheet itself. This is exactly the same convention used by "modal bottom sheets" in Google's "Material" design framework.

Date labels

I'd propose we only show a label like "2 days ago" when both, A, we're showing a postcard (not editable), and B, the post is not older than four days. In every other case, we'd display "Sept. 21, 2016."

Demos:

• Post: Edit
• Post: Add

---

Feeling better about this, @rjmackay and @jess?

[jshorland]

I keep thinking it's a toggle button or a scrollable-esque bar when there is a label. Especially with the "alpha" status coloring. I like the consistency though. I think we should align left vs. centered. Makes total sense re: date labels. @caharding would love to hear your thoughts on this too. This might be something we should put to user testing to see which version is most clear.

[jshorland]

User having an issue with pre-dating a post relevant to this: https://app.intercom.io/a/apps/hl5rfiga/inbox/all/conversations/6065074701

[rjmackay]

Pretty happy with this revision. Still missing a 'cancel' action on the post status modal though.. less of an issue now but still in consistent with the other 2 modals.

[caharding]

I'm happy with this solution.

On Sun, Sep 25, 2016 at 8:34 PM, Robbie Mackay notifications@github.com
wrote:

Pretty happy with this revision. Still missing a 'cancel' action on the
post status modal though.. less of an issue now but still in consistent
with the other 2 modals.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1399 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABizacsMUhWLB7xxpg43XpVZuDUlW4Deks5qtxL5gaJpZM4J-YPC
.

Charlie Harding
Product Director

[brandonrosage]

@spiral99 I'm preparing a design solution for this that will be ready to test early next week.

Let's conduct a user test for this user question: "How do you edit a response’s author, date, and status?"

This will require testing either a Pattern Library prototype (which I will help stage), since the solution we want to test isn't implemented in the product.

The proposed solution would provide a path to complete this task by choosing to "Edit" a post (which can be engaged a few different ways), and then using the various 'metadata' "chips" to configure each one.

We want to know if these are discoverable and reasonably simple to use in completing the task.

[brandonrosage]

@spiral99 What's the latest on the task of testing this question?

[brandonrosage]

Nov. 10 user test findings, from @spiral99:

All of the users found it easy straight forward that accessing the date and author metadata to make changes to those features.

[rjmackay]

Just reviewing this while thinking about the Kuwait deployment and requirement for non-logged in posters to be able to input their name + email. These pattern are really good for admins creating and editing a post, but when a non logged in user creates a post this does provide a useful prompt for them to enter their name + email

[rjmackay]

@jshorland is it worth including this in UX cleanup? Otherwise I'll icebox it for now

[rjmackay]

@jscherer not sure this is relevant anymore. I'm going to close. Reopen if you think this matters.
This was one way to get right of the floating 'toolbox' for editing post status/date/etc