1754482 - Remove (or hide) icons in the calendar views

Status: NEW

(Calendar :: Calendar Frontend, enhancement)

Description

[Henry Wilkes (they/them) [:henry-x]]

Attachment: all-icons.png

This has been in the back of my mind ever since I first worked on the calendar view, but was prompted by bug 1674912, which is adding an icon for event recurrence.

Problem: icons can take up a lot of space in the calendar views.

I attached an exaggerated example on a 1280×720 window.

The example requires setting a recurrence (using bug 1674912), setting a reminder, spanning more than one day, and setting the privacy. In principle, you could also have an "email" and "audio" icon if your calendar supports such reminders (https://searchfox.org/comm-central/rev/ae96a5579404d1cc6792421f6cd38142adc70eb9/calendar/base/modules/utils/calAlarmUtils.jsm#167).

So it's probably not common to see all these icons, but even just two icons can block most of the event name. And with the new recurrence icon, this will be more likely since a recurring event with a reminder wouldn't be unusual.

This can be worse in the week view if you have overlapping events, but I have a plan to try and improve this in bug 1746895. I could do a similar thing in the multiweek and month views to ensure each column has a decent min-width, but it would mean some users have to scroll horizontally.

The other thing I'm worried about is that most of these icons have no key, tooltip or documentation to give them a definite meaning. The "alarm.svg" icon at least appears in the edit dialog, so can be inferred. The "alarm-no.svg" icon is more vague: it means a reminder is set for the event whilst the calendar has reminders disabled, but it reads as "no reminder" or "cancelled reminder". The "email.svg" similarly means an email reminder is set, but could read as "sent invitations".

I like the look of the new recurrence icon, but I think it similarly needs some explanation for users to understand what it means. The recurrence-exception icon needs this even more, since it can read as "not recurring" or "cancelled occurrence".

Note there are related problems where the styling of the event in the view is used to convey information. E.g. a dotted outline means "needs action".

Do we still want icons in the calendar views?

For the reasons above, I was already considering dropping the privacy icon entirely in bug 1746392. But I think we should also drop most of the icons from the calendar views, at least by default.

I think the main purpose of reading the calendar view is to check your schedule, and it should be streamlined for this. This means in the month view, you only want the event name and the start time. In the week view, you also get the end time (visually), and optionally the location. The only icon slot I would keep would be for the multi-day icons because they are rare, but still needed to understand the start and end times. Everything else is visual and/or screen reader noise for this purpose.

Any other event information should be hidden, but easy to access (with the exception of the color of the event indicating the calendar, but only visual users benefit from this). For example, the user clicks a part of the event item to show a popup with the details of reminders, occurrences, location, etc. I think something similar is already planned for bug 1685007, based on https://bug1575195.bmoattachments.org/attachment.cgi?id=9139613

Whilst I think we shouldn't show icons by default, if some users would still like to see icons in the view, we could have a customization option to show the icons again. If this was done per-icon, then the same customization dialog could also act as a key to explain each icons meaning.

I would like to know what other people think. And how regularly the icons are useful to them, and whether the information hidden behind an extra click would be a hassle.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Regarding the other information that is "shown" in the view through styling, see the older bug 1711452 which has a summary of all the information we are currently trying to convey.