msramalho / SigTools

📆 Sigarra Tools | An extension that makes the information system of the University of Porto slightly better.
https://chrome.google.com/webstore/detail/sigarra-to-calendar/piefgbacnljenipiifjopkfifeljjkme
Apache License 2.0
37 stars 0 forks source link

Enhance how events are listed in Modals #128

Open fabiodrg opened 2 years ago

fabiodrg commented 2 years ago

Motivation

At the moment, the modal of events for exporting shows the event title, which is the same title used when creating the events for Google/Outlook/ICS/etc. Note that if the user changes the title formatting, it also affects how events are shown in the lists.

I personally think the modals should show all the necessary information so that the user can easily identify the events. For example, consider the exams. The default title format is Exam [${subject.acronym}] - ${location}. So the list looks like this: image

A few problems. First, the course name/acronym is not sufficient to identify which exam is which. For instance, note the two exams for the course AC. Is the first AC exam a "mini teste"? a special exam? is it the same exam but split in two turns? In my opinion, it would be more meaningful to show richer information such as:

Back to the example AC, and with the richer information, it would be obvious it is the same exam but it has two turns.

Proposal

So in my opinion we should separate these two concerns:

As we migrate event related extractors to EventExtractor, I think is not very difficult to solve this problem. Extend the current createEventsModal to take an additional and optional argument that is a callback function. https://github.com/msramalho/SigTools/blob/ffe3959c61125d051af6686ec240ce1e145cb3d2/src/js/utils/modal.js#L133 The callback is called to generate HTML per event, replacing the code below: https://github.com/msramalho/SigTools/blob/ffe3959c61125d051af6686ec240ce1e145cb3d2/src/js/utils/modal.js#L174-L178

fabiodrg commented 2 years ago

@msramalho any thoughts on this?

msramalho commented 2 years ago

Indeed the priority is identifiable events rather than maximum customization, so I'd support separation of concerns, and if we must restrict how the events are show in the UI to a single constant format than that should not be such a big deal. Though ideally we would still allow users to customize how they show up in the calendar.

fabiodrg commented 2 years ago

Though ideally we would still allow users to customize how they show up in the calendar.

Yup, the idea is to keep that feature, I consider it a must have :smile: What I am proposing is that the UI would be controlled by us to ensure all the relevant information is shown

msramalho commented 2 years ago

sounds perfect :)