Editable post dates

[sophshep]

I have run into an issue (as has @jshorland) of posting something that happened in the past, and that post then gets the date of when it was posted. To solve this issue, I think we should treat it like this:

1. Date posted is the default date
2. "Date X Happened" can be added as a field in a custom post type
3. Date range filter should show all date types
4. On bar charts, there should be a dropdown to choose which date type you want to have as your X-axis

cc/ @brandonrosage

[brandonrosage]

@vbhv We discussed the notion of adding a select control to Timeline view (for example) that allowed the user to define the 'date type.' While it adds UX complexity, what's your take on it's technical complexity? Or your take on it, generally?

[vbhv]

@brandonrosage The requirements/cases for this feature are documented here – under the heading Timeline and Bar Chart Views, Iteration 2:

https://docs.google.com/document/d/18-4bA0uSJbDU-PtbW5BzZThgRaUbd4JtcBxOFAUSaHU/edit#heading=h.5qlx5nnt2lua

And the UI wireframing task is #666 . A good drag and drop interaction pattern will make this an easy to understand interaction. We can have a brainstorm around this.

In addition to allowing date type we have to allow for selecting other custom field attributes. Technically we do have the ability to generate the required data for such custom attributes. What we need is a pattern that scales for mobile as well.

[rjmackay]

@vbhv We discussed the notion of adding a select control to Timeline view (for example) that allowed the user to define the 'date type.'

I think this is relevant for other views too: if filter by date, which date? when post list is in date order, which date?
One problem with how we store the data for posts is that if you add 'Date X Happened' to a post type.. each post type will have a different field. We don't have any way to share fields between post types. We can just expose each field in the UI.. but that might end up with confusing results..

[rjmackay]

Relevant user request https://app.intercom.io/a/apps/hl5rfiga/inbox/unassigned/conversations/5100150751

[brandonrosage]

@rjmackay Are there any red flags we should consider in designing for a permanent, editable "Post date" field?

In other words:

• Created: Time & date (not-editable)
• Post: Time & date (editable; derived from 'created' by default)

[rjmackay]

We currently have

• Created: Time & date (not-editable)
• Update: Time & date (not-editable)

We'd be adding

• Post: Time & date (editable; derived from 'created' by default)

For end users - they probably only ever need to the Post date. But we continue to track the others in case we need to expose them later.

[brandonrosage]

@rjmackay Is "Update" the time & date the post was most recently edited? And if so, I assume it changes automatically and presumably the most often?

[brandonrosage]

I've staged a few examples, starting with "Post: Edit."

[rjmackay]

I'm not sure that Author should really be editable.
On dates, Would it make sense for this to work similar to how it was handled in v2 where the date isn't initially shown as editable but has a button to toggle that

[brandonrosage]

RE: Editable 'author' field
I think this is as (or nearly as) valuable as making "post date" editable. A few scenarios demand it, starting with a single user populating a deployment with a team's contributions. Rather than forcing them to log into each of their accounts to properly attribute their posts to them, the user could create every post and attribute them to the correct user, on the fly. Post date and author would be fields a user could access only with explicit permission (by way of their role).

RE: Visibility of the 'post date' field
The current proposed solution makes it a little more discreet, but nonetheless discoverable:

In my various attempts at designing this field, I found that displaying the post date in plain text and revealing editable fields that represent it is confusing and problematic. And we don't have a convention for it because, in our design system, content is either editable or it's not. It's not "toggle-able."

[rjmackay]

👍 moving the meta data to the sidebar is good.
I take your point on editing the post author.. it bugs me a little that we're losing the audit trail but thats really another feature entirely, for another day. I'll queue this for the next sprint.

[rjmackay]

@brandonrosage follow up question on editable authors

In the API we currently have an option to record an author name + email. This was to allow non-logged in users to leave authorship details when submitting a post. At some stage we dropped this from the UI (accidentally). So first

1. I think we should bring that back.. but where would those author name + email fields go? with the Post fields?
2. When editing an author, should we allow setting author to another user OR to a custom name + email .. what would the UI for this look like? .. I'm not clear what the UI is once I click 'Change author' anyway.
   http://preview.ushahidi.com/platform-pattern-library/develop/assets/html/5_layouts/post-edit.html

[rjmackay]

@jasonmule can you add the screenshot of the author editing UI you've implemented so far?

[jasonmule]

At the moment, change author simply brings up a form that allows the user to add a custom author to the post:

Please note that the author added/ edited here is set to a post and not a user.

[brandonrosage]

If possible, I'd like to lay the groundwork early for a "user picker." It's obviously needed here. And will definitely be needed for future features, like "Tasks," where picking users as assignees.

It'd amount to a modal, like this:

I battled with this pattern for a long time, trying to avoid a modal -- trying to make a compact popover control work. But we use it in so many different contexts where that pattern falls down. So here we are.

Any thoughts or concerns?

[rjmackay]

Looks good for setting another User as author.. but that doesn't address any of my comments about custom/non-user authors.

[brandonrosage]

You're right, @rjmackay. When editing a post's author and/or post date, here's what I've staged in the PL:

Logged out

When you encounter the "Add post" page, you'd see a summary of the metadata:

If you select "Change," the fields for providing author information replace the text-only appearance:

The rest works as you might expect. It's a typical form sheet.

Logged in

When you encounter the "Add post" page, you'd see a summary of the metadata:

When you select "Change," the fields for providing author information and customizing the post date replace their text-only appearance:

If you want to change the author, you can remove the existing "bug," which would change that fieldset's appearance to:

In this case, because you're logged in, typing into the author "Name" field will perform a search of the deployment's users and return matching results in a dropdown:

If you choose to simply type a name and not select an existing user from the list, the form will record your custom author name and (optional) email address. If you choose an existing user from the list, the "name" and "email" fields are replaced by that user's "bug."

How do we look now?

[rjmackay]

Moving discussion of editing authors to #1361.

[rjmackay]

Moved date editing to #1362 and closing this issue