How to approach UX?

[martin-sweeny]

I jumped into this not thinking much about the nuances of time zones. Some caveats I didn't think of:

• Of the 106 time zones available, only 73 have unique abbreviations
• Time zones that adhere to daylight savings are technically duplicated too (i.e. EST and EDT are unique time zones)
• If a user selects a time zone that does adhere to daylight savings, the bot will have to convert their role back and forth periodically
• Daylight savings rules vary by location and year

Of course, there are time zone lookup APIs (Google Time Zone API being the most obvious); but to look up the appropriate time zone means to ask the user for their location, which is not great.

This issue is to have an open discussion about how to approach these problems.

[martin-sweeny]

@GalGreenfield, why do you think? (pinging you because of your interest in the other time zone role bot)

[martin-sweeny]

I'm leaning on having the bot DM the user to ask for their location, but that still doesn't feel very nice

[GalGreenfield]

Thanks for pinging me. :)

About Daylight Saving Time: If you want to account for that, I think the only way is to either switch time zones by name (like EST/EDT), or standardize the location to something like a class/object with something like the following properties:

<string/number/whatever> id - ID for the time zone
<Datetime.time> standard_time - UTC offest of the "standard" (winter) time
<Datetime.time|null> daylight_savings_time - UTC offset of the daylight savings time - null if not defined for this timezone
<Datetime.time> current_timezone_type - the active time in the time zone - standard or daylight saving time
<Datetime.date> current_date - the current date in the time zone

Or you could not use an active_timezone_type and switch based on the date - but that'd be a pretty bad idea, IMO because it might not standardized anywhere (I don't know) by default. And actively, I do know of a case where a few years ago where a government decided to change to its country's (single-time-zoned ) time to its standard time zone earlier than it usually's changed (it was Israel - I don't remember the reason, though). I think it'd be better to define it modularly, per time zone - and there's information about it online

About Location Privacy:

• If users share their location:
  • I saw a bot that does timeozone functionality, Friend Time, sort of, and it did use locations - so I already saw a solution that works.
  • To increase privacy, the bot could store that information, possibly even encrypt it, and, addtionally, the information could not be displayed to anyone - including to people with access to the code. If it's encryption, the users' trust would be in the encryption and the holder(s) of the encryption key.
  • Although this is an expanded scope for the functionality of the bot, I initially envisioned the ability for users to share their location, too - to have this bot be used to be able to find people who are also nearby you, for distance related things, such as in gaming, for people to play on the same server, or for social things, making friends in nearby areas. Also, if people are willing to share their time zone, they might be more okay with sharing their location (which doesn't have to be an exact address, even just a state would be a small-enoguh geolocation identifier, in my opinion - in the existing bot they a city+time zone combination).
• If users don't share their location:
  • I'm not sure it'd be possible to escape the daylight saving time time zone change issue.

About UI/UX: What I was thinking (I planned to implement such functionality) was to do reaction-roles, possibly with a search toolbar with embeds). Is it even possible for a Discord to relay that information to the bot? As in, prompt the user for their location natively, and send it to the bot? I don't think the Discord API enables that. If that's not possible, you need to do external redirection, like what Friend Time does (it refers users to choose their time zone here, which is pretty intuitive thanks to it being graphical, and doesn't require them to mention a particular city - it goes down to the state-like level, although it's not as accurate for location - which might be a pro or a con, depending if you want to hide it as much as possible or want it to be more accurate or less accurate.

I think you could use do the UX in a multi-step process - with embeds with some form solution to your liking, or, In some desired channel, send a message with the bot with for users to interact with:

• Text: "Time Zone"
• Reactions to CRUD time zone: "➕" (to add a time zone), "🖊️" (edit/change) "✖️" (remove) That's for the user input. From here on, you need to actively send messages to the user. To avoid clutter and mess and ease of use, I think it's better to avoid text interactions in public channels. So there are 2 solutions I can think to this:
  • DMs, as you suggested - possible, and is used most of the time in verifications with external services
  • Creating temprary, specific-user-visible channels for the interacting user to interact with the bot. That's something I saw with some Discord Ticket Tool bot on this Among Us Discord Server - they might have implemented a custom solution for creating channels - I don't know, I haven't checked the bot's capabilities.

DMs vs Private Channels It's mostly a privacy vs. comfort trade-off -

• DMs - no information goes through the server, it's all external and goes only through the bot. The server gets only the final result.
• Private channel:
  • If using messages for prompts: information does go through the server, but the user doesn't leave the server.
  • If using embeds: I don't know if information goes through the server (I haven't researched that) - in case it doesn't, then you get both increaserd security and increased comfort, but you need to program both a back-end and a front-end for it.
  • Can be deleted automatically once the process is complete, saving the user managing messages. Can also be hidden away from the user when done instead of being deleted, and when either updating and/or deleting the timezone, revealing it again - or, alternatively, saving the interaction data in a database and re-creating the channel (to not put a load on the server) - I'm not sure what Ticket Tool does, but it's basically that kind of functionality.

[martin-sweeny]

@GalGreenfield thanks for the thorough response. I'm gonna wake up a bit and come back with some thoughts

[GalGreenfield]

@GalGreenfield thanks for the thorough response. I'm gonna wake up a bit and come back with some thoughts

I updated my response so please read it when you can. It might be a bit unorganized in terms of orders (I mostly just "threw" my thoughts without much editing). If there's anything you don't understand, please let me know.

[martin-sweeny]

Do daylight savings rules vary within time zones? If not (and I don't think they do), the bot needs only ask the user what the current time is to determine what the correct time zone is.

[GalGreenfield]

Do daylight savings rules vary within time zones? If not (and I don't think they do), the bot needs only ask the user what the current time is to determine what the correct time zone is.

What rules do you mean, exactly, and what kind of variations are you referring to? If I understood you correctly, when daylight savings time change (i.e when the clocks are moved) is usually standard and doesn't change - except for rare examples like when a government decides to change it actively (like in the Israel case) - a case that I don't think is worth it to be taken care of by the bot. But in case it's not standard (which I think it is) - i.e it's changed on the same date in the local time zone, in all time zones that have daylight saving time - maybe it'd be worth it to add a parameter for when it's changed - I suppose it requires research about DST changing. But I'm pretty sure that some big API, like Google's, already solved that, if it's not standardized, but that might require needing the user's approximate location - and if it comes to needing this much effort for accuracy, I think it'd be worth it to ask that.