SigTools
SigTools copied to clipboard
Enhance how events are listed in Modals
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:
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:
- Course name
- Type of exam ("mini teste", "época normal", ...)
- Date and time
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:
- How events are created in calendar clients (user customisable)?
- How do we list/represent events in the UI for exporting? Must show all the information to correctly identify the events. Will vary from extractor to extractor.
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
@msramalho any thoughts on this?
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.
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
sounds perfect :)