search

BenHUET / eveseat-calendar

Calendar plugin for EVE SeAT
GNU General Public License v2.0
14 stars 19 forks source link

[Enhancement] Change UI For Event Times To Force Better Specification of Permanent vs. Constrained Time Events #33

Closed Eingang closed 5 years ago

Eingang commented 5 years ago

Summary

Events without an explicit duration no longer 'fade', which is unintuitive. Change the UI for choosing times to force better event duration specification behaviour by users.

Environment

Discussion

Events without an explicit duration used to appear in the list of upcoming events and then would go into Faded when the designated time arrived because they weren't ongoing. That was predictable, reasonably intuitive behaviour.

Now, events without a duration go into Ongoing when they trigger and stay there seemingly indefinitely. This was unexpected and resulted in me having to delete events because, other than viewing the event's details, trashing it is the only option available. I came to report this as a bug, but discovered a July 22nd commit changed that behaviour and was labelled as a "fix". I'm not sure what use case this was fixing.

In an ideal world, FCs would plan ops to be a specific length, but the reality is they don't always do that. We've had an event transfer system from in-game to web-displayed for years and it was quite common for FCs to leave the duration undefined because they didn't know. Therefore, in the SeAT calendar, they simply set the start time and chose "no duration". As an another example of something we started doing recently, we add events for our logistics team like "unanchoring". They don't have a duration. They're for a specific time and we want to know about them as they approach and see that they've passed, but we definitely don't need them in Ongoing until someone deletes them.

While I can see a case being made for "no duration" equating to "forever", that's not the approach most calendaring applications take. They either set a default duration, a specific user-supplied duration, or denote it as an all-day event. It doesn't feel useful to have the default (because someone only specified a start time because that's easier) result in an ongoing, permanent event, especially since you can't edit the event once it goes into Ongoing. If someone really wanted a more permanent event, which seems a less common use case to me, they could just create an event with a lengthy end date. I'd rather see that and either the old behaviour where they go into Faded immediately, OR they're created with a default duration if no end time is specified.

Implementation Suggestion

While we could set a default time if no duration is chosen so that the event appears in Ongoing for a brief period, that's not really intuitive behaviour either. I propose therefore that we keep the backend behaviour much the same but change the UI for specifying event times to force people to specify times in a way that results in the calendar behaving in ways they might reasonably expect or predict.

First idea

Instead of saying Duration is known: Yes No, leave the Start at field in place, and use the Duration is known: Yes modal. Add a tick box outside of that modal to allow the event to be designated as Permanent (or something like that). Choosing Permanent would cause the end time to be cleared (i.e., what is now No duration). Using the Duration is known: Yes modal already sets a default time. If the user doesn't like it, they're forced to pick an explicit end time they can live with or explicitly say they want the event to be permanent. Events will therefore be better specified and the calendar would support a wide range of use cases in a more intuitive fashion.

Second idea

Keep the system you have, but change the wording of Duration is known: Yes No to something like Permanent event: Yes No. Choosing Yes gives you access to the Duration is known: No modal and removes any end time (if one had been set). Choosing No gives you access to the Duration is known: Yes modal where a default end time is supplied or the user can explicitly set one. Make the default be that it's not a permanent event. That would make it clearer, I think, to people, what's going to happen and, again, force them to be clearer about durations (or lack thereof).

warlof commented 5 years ago

Hi,

With superuser or event FC, you're able to mark an event as completed (green check) which will use current time as event ending time.

The purpose of this isn't to schedule permanent fleet but indead to schedule a fleet with unknown termination point. It's up to the FC to manage its event - as well as pap his fleet.

Eingang commented 5 years ago

I apparently completely missed the checkmark.

For groups not tracking PAPs via the calendar, it'll unfortunately likely be "out of sight, out of mind" leaving dangling events. I might tweak my local copy to work as per suggestion 2.

Thanks for the reply.