Editable post dates

[rjmackay]

This has been designed in the PL but isn't implemented.
Background on #752

Need to

• Add a post date field to the post table and API
  • This should default to creation date but be editable
• Post created and updated dates should remain auto generated
• Add UI for editing post date
• Use new post date field for sorting lists of posts.

[brandonrosage]

I've staged a solution for editing a post's date, author, and status from the same place: The "metadata" pattern.

In the interest of making the visual structure for editing a post reasonably similar to viewing it, this solution keeps those pieces of metadata inside the form sheet, but styled uniquely. It also lays the groundwork for patterns and conventions we can benefit from throughout the platform, including:

Chip

Condensed information that's clickable, to reveal more details.

Mainsheet

Modal actions, used when selecting something that should offer a list of options -- and no fields. It's meant to be used, for example, when a user selects the "Add" button and there are multiple options (e.g. Surveys).

NOTE: The reason one clickable item (like a chip) might trigger a "Modal" and another might trigger a "Mainsheet" is that, in the former case, it must reveal multiple kinds of actions, like a multi-select list with an added search field. But in the latter case, the clickable item must reveal a list of actions that, with one click, complete the task or take you somewhere else.

---

So, to the point about editing post dates, the user could do so by selecting the post date "chip" and revealing a modal window with editable fields related to that metadata.

You can demonstrate this interaction in the sprint-11 edition of the PL: http://preview.ushahidi.com/platform-pattern-library/sprint-11/assets/html/5_layouts/post-edit.html

---

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.

[caharding]

I really like this overall approach. The chips are excellent, easy to find
from non users, and treated in a unique way. Very nice.

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?

On Mon, Sep 12, 2016 at 1:36 PM, Brandon Rosage notifications@github.com
wrote:

I've staged a solution for editing a post's date, author, and status from
the same place: The "metadata" pattern.

[image: metadata]
https://cloud.githubusercontent.com/assets/1136279/18451240/bc93dadc-78fb-11e6-9819-bd64d2c4f159.png

In the interest of making the visual structure for editing a post
reasonably similar to viewing it, this solution keeps those pieces of
metadata inside the form sheet, but styled uniquely. It also lays the
groundwork for patterns and conventions we can benefit from throughout the
platform, including:
Chip

[image: chip]
https://cloud.githubusercontent.com/assets/1136279/18451370/371cb094-78fc-11e6-9cdf-89b0bd370774.png
Condensed information that's clickable, to reveal more details.
Mainsheet

[image: mainsheet]
https://cloud.githubusercontent.com/assets/1136279/18451607/4711853c-78fd-11e6-94ef-7a5089f4a1a7.png
Modal actions, used when selecting something that should offer a list of
options -- and no fields. It's meant to be used, for example, when a user
selects the "Add" button and there are multiple options (e.g. Surveys).

NOTE: The reason one clickable item (like a chip) might trigger a
"Modal" and another might trigger a "Mainsheet" is that, in the former
case, it must reveal multiple kinds of actions, like a multi-select list
with an added search field. But in the latter case, the clickable item must
reveal a list of actions that, with one click, complete the task or take

you somewhere else.

So, to the point about editing post dates, the user could do so by
selecting the post date "chip" and revealing a modal window with editable
fields related to that metadata.

You can demonstrate this interaction in the sprint-11 edition of the PL:
http://preview.ushahidi.com/platform-pattern-library/

sprint-11/assets/html/5_layouts/post-edit.html

I'd particularly like @jshorland https://github.com/jshorland,
@caharding https://github.com/caharding, and @rjmackay
https://github.com/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.

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

Charlie Harding
Product Director

[rjmackay]

Sorry - this issue was queued for a sprint with design done. Why are we iterating the design again at all?!
We can't build anything if the design keeps moving.

[jshorland]

I actually think these are two separate issues. We have two options for this immediate sprint starting tomorrow:

1. we continue with the original issue of matching date picker to the current pattern library in sprint 11, and pull the second issue of meta data chips out into Editable post author #1361 and deal with that larger issue in a further out sprint, or
2. we nix fixing the date picker pattern for now and deal with it all in the larger issue of meta data.

I recommend #1

[brandonrosage]

@rjmackay It looks like we have a misunderstanding about the process.

As I understand it, an issue that's designated for a sprint must have it's design completed before its sprint begins. And because this issue's sprint, No. 11, had not yet started, the work I shared above was my attempt to get y'all something solid before things kick off in our scheduled meeting Sept. 13.

If this sprint started early, or was already underway, I apologize. I only jumped in because, from my vantage point, the sprint hadn't yet kicked off.

If necessary, I think it's fine to implement this feature using the design that's been previously staged. I can re-stage it in the sprint-11 branch, if you need.

[rjmackay]

Once something makes it to 'Waiting for sprint' I don't think it should move backwards unless @jshorland pulls it out. It was put into Waiting for sprint on the basis of design worked that already existed in the PL.. and with a scope based on that. The sprint is due to start today.
I think the intention is that in general design + spec should all happen before an issue is queued for a sprint.

The new changes would expand the scope of this issue to something I don't think we can complete in this sprint, but also don't have time to feedback and scope the issue now.

[brandonrosage]

In that case, let me stage the previous solution in the sprint-11 branch and create a new issue for the revised treatment of metadata, which would include changes to "post date."

[brandonrosage]

@rjmackay & @jshorland: As promised, I've staged the "Post: Edit" and "Post: Add" layouts for the sprint-11 branch such that they use the "toolbox" pattern that I offered in June:

This should help you keep the implementation of this design solution within the Sprint 11 tech spec you originally provided.

I've also created a feature-specific branch -- f-metadata -- dedicated to demonstrating the solution that I'd like to bring in a future release to improving the editing experience for what is increasingly every piece of metadata:

We'll get that merged into a sprint-specific branch once the issue is designated for a sprint.

[rjmackay]

@brandonrosage thanks for splitting that out. Can you create a github issue for the f-metadata change too? so we 1. don't lose track of it 2. it can go through any feedback/spec stages needed.

[brandonrosage]

@rjmackay Done: Issue #1399

[jshorland]

@rjmackay should i move this back into in progress? or let you do that?

[rjmackay]

@jshorland pushed a fix to this. Should be live soon

[rjmackay]

Well I fixed the ordering but I have timezone issues of some form.
If I set a date, then view the post the post date doesn't match what I set. Its off by 13 hrs (I'm in UTC+13)

[jshorland]

oh interesting. its probably because it matches the default time zone set in the deployment. It's the same for me in eastern standard time US

[jshorland]

My recommendation is to push the changes in this issue, and resolve any confusion around time zones in a new issue.

[rjmackay]

I really don't think this should go into production till we fix timezone issues. The primary issue TBH is that if you edit a post, and save it (having made no changes on the form) it overwrites the post date.. so we're corrupting post data.

[rjmackay]

Let me provide better info on whats broken here:

• If I edit a post, and don't touch the form or date fields.. then save. It overwrites the post date, rounding it to the nearest half hr, possibly breaking timezone.
• If I set a post date, its assumed the date is UTC, not my actual timezone. This isn't influenced by deployment timezone and basically leads to corrupt data.
• Under some unclear conditions if I set post date, the time is overwritten with the current time.. regardless of what is set on the form..

TLDR: This feature is really broken

[rjmackay]

I've hidden this on production until its fixed. The more I messed with it was broken :(

[rjmackay]

Also noticed that you can't edit the post date when creating a new post, kinda counter productive.

[jshorland]

Fair enough. Create a new issue, or make sure the same issue goes backward so we don't lose it

iPhone iTypo

On Oct 28, 2016, at 8:30 PM, Robbie Mackay notifications@github.com wrote:

Also noticed that you can't edit the post date when creating a new post, kinda counter productive.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jshorland]

Post dates not editable at all on qa.ushahididev.com -- is that where I'm suppsoed to be testing this?

[rjmackay]

No. Sorry sent the link in Slack a few days ago.. but not here: http://qa.fix-date-timezone-issues.ushahidilab.com/

[jshorland]

• successfully edited post date on post 2530 (http://qa.fix-date-timezone-issues.ushahidilab.com/posts/2530)
• system successfully updated the "last edited" meta data on the post with my date and time in MY timezone
• system successfully ordered post by the most recently updated post date on timeline
• post still visible in map view with the correct post date

CHANGED TIME ZONES ON MY COMPUTER to WELLINGTON NEW ZEALAND AND RE-TESTED.

• first, checked the last updated meta data. It is correctly in NZ time (Last updated at November 11, 2016 8:56 AM)
• Successfully saved the post after editing the post's date on post 2503 (http://qa.fix-date-timezone-issues.ushahidilab.com/posts/2530).
• system successfully updated the "last edited" meta data on the post with my date and time in my newly changed timezone
• system successfully ordered post by the most recently updated post date on timeline
• post still visible in map view with the correct post date

PASSES QA.