Order cycles date / time widget - the time control is confusing, broken or just badly designed?

[kirstenalarsen]

Fix (or explain) time widget in OC setup

[sstead]

A user could not be confident that their desired closing time/date had been saved... suggested improvements....

1. restore image
2. save the time in the widget and the text field
3. change the +1100 to AEST
4. put a progress bar for the time (hours/mins)

[daniellemoorhead]

@Matt-Yorkley do you think this would make a good first issue for newbies?

[Matt-Yorkley]

Sure, looks simple enough.

[sauloperez]

Just to clarify and expand the acceptance criteria for this issue:

• Restore the datepicker button in both open an close input fields
• Display the stored time when reopening the datepicker
• Show the local time according to the user locale without showing any time offset
• Show slider to select time in the datepicker

This sticks to items listed above and makes them work for other instances Agree @sstead, @daniellemoorhead?

[myriamboure]

Yeahhhh ! Thanks @sauloperez I had also some comments from users who didn't understand the "+2:00" that was confusing... i'm not sure peoplel would understand the "ECT" or "AEST" time zone mention so I would just suggest "use the locale" but don't mention any international time stuff.

[sstead]

I'm not sure how the 'locale' time works. In Australia there are a few time zones, so unless the system knows which time zone the users is in, it would be good to say AEST as the reference point (this zone covers most of Australia, then people in other zones can calculate the difference). I suspect Canada, USA etc would be similar.

[daniellemoorhead]

We have the joy of many timezones on our very big island @sauloperez.

So when you say show the user time according to user locale does that mean you would be using the user's computer/phone time setting?

[sauloperez]

So when you say show the user time according to user locale does that mean you would be using the user's computer/phone time setting?

That's the idea. Although I'm pretty sure many devs hate AUS time zones mess , that would still work. Everyone would see the time according to his timezone.

[daniellemoorhead]

Although I'm pretty sure many devs hate AUS time zones mess

It's painful for non-devs too, just in terms of remembering when you speak to people in different timezones in the same country!! But I rather this than the Chinese model where they have a single timezone and it can be pitch black but is supposedly 9am!!

Everyone would see the time according to his timezone.

So @sstead rather than needing to do the calculation our users would see the date/time based on where they are. Will this work ok? Any scenarios where it won't work?

[kirstenalarsen]

could they just pick a timezone in their setup? apologies if this has already been discussed, i’m just scanning and read last message

…

On 26 Oct 2017, at 11:00 AM, Danni M ***@***.***> wrote: Although I'm pretty sure many devs hate AUS time zones mess It's painful for non-devs too, just in terms of remembering when you speak to people in different timezones in the same country!! But I rather this than the Chinese model where they have a single timezone and it can be pitch black but is supposedly 9am!! Everyone would see the time according to his timezone. So @sstead <https://github.com/sstead> rather than needing to do the calculation our users would see the date/time based on where they are. Will this work ok? Any scenarios where it won't work? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#418 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACxryNHYy0FIo1_K8SxZMr3xCtxPsVasks5sv8uwgaJpZM4DuHwt>.

[sauloperez]

Well, we should offer the possibility (perhaps as a later iteration to keep things fast) but I'd pick the timezone offset from the browser.

Any scenarios where it won't work?

I can't think of any 🤔

[sstead]

"So rather than needing to do the calculation our users would see the date/time based on where they are. Will this work ok? Any scenarios where it won't work?" - Yes this seems good to me, but can we also show what time zone they have? The only possible point of confusion is that if the time zone isn't specified anywhere, the user will not be certain whether the timezone is set to their browser, or if it's set to eastern time by default. Some users may need to test this to confirm. Whereas if we could indicate the time zone there'd be no ambiguity.

[sauloperez]

Well, I'm not sure there's any value on showing that if it's not editable (I don't know whether spree allows it). Users assume datetimes are in local time. Just think about all the services you use, google's for instance.

[myriamboure]

Removing goodfirstissue label as it seems we need a clear inception process to decide what we do. So closing this issue for now, iceboxed it in: https://community.openfoodnetwork.org/t/hubs-can-easily-navigate-back-office-and-manage-their-shopfront/1246 and we will reopen when we decide to prioritize the hub manager UX and this will probably be one of the stories we will then put in it.
#gitcull2018