1748449 - [meta] Re-design invitation display for easier reading.

Status: RESOLVED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), enhancement)

Description

[Lasana Murray]

The current version provides the event data to the user in a table which can be difficult to figure out what's happening at a glance. There is also little interactivity beyond links and the table is displayed in a content <browser> mixed with the message contents.

There are various visual improvements that can made such as:

1. displaying the most important information as prominently as possible.
2. optionally display the timezone for the "When" part.
3. make it clear an event has been cancelled, especially when looking at previous messages.
4. display recurrence information in a friendlier manner.

I attached some mockups I drew.

Comment 1

[Lasana Murray]

Attachment: original.png

Comment 2

[Lasana Murray]

Attachment: improved.png

Comment 3

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

Comment on attachment 9257498 [details]
improved.png

I like the "Organizer" role being written as explicit text. It's much clearer than the current icons that combine the role with the type and status. I'm guessing the idea is to only show the role and type when they differ from "REQ-PARTICIPANT" and "INDIVIDUAL" respectively.

For the participation icon, how do you plan on showing "TENTATIVE" and "DELEGATED"?

Comment 4

[Lasana Murray]

(In reply to Henry Wilkes [:henry] from comment #3)

Comment on attachment 9257498 [details]
improved.png

I like the "Organizer" role being written as explicit text. It's much clearer than the current icons that combine the role with the type and status. I'm guessing the idea is to only show the role and type when they differ from "REQ-PARTICIPANT" and "INDIVIDUAL" respectively.

I'm willing to say the role type is not too important to display here but I'm leaning towards either text next to where "Organizer" is shown or a tooltip. It could also probably only be shown for the user's identity.

For the participation icon, how do you plan on showing "TENTATIVE" and "DELEGATED"?

Tentative will likely be a question mark icon. I don't think we have much visual support for delegation but we can come up with an icon.

Comment 5

[Lasana Murray]

Attachment: progress.png

Making some progress here. Uploading a screenshot of what I have so far.

Comment 6

[Magnus Melin [:mkmelin]]

Before you proceed further, you need to figure out if there is any feasibility of having buttons in the content. That is not likely a small project...
Please also add an event description (a longer one) for the event you test with. Showing the description is essential. Your current screenshot also doesn't show the time at all.

Comment 7

[Magnus Melin [:mkmelin]]

Attachment: (for inspiration) paperlesspost.png

For inspiration, from paperlesspost.

Comment 8

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

(In reply to Magnus Melin [:mkmelin] from comment #6)

Before you proceed further, you need to figure out if there is any feasibility of having buttons in the content. That is not likely a small project...

From the email discussion, I think the idea is to put the invite in a new and separate UI section (which would be a good idea, regardless of buttons), rather than the message <browser>.

Comment 9

[Magnus Melin [:mkmelin]]

Perhaps, but that it the issue: I think it requires rather significant surgery of the whole functionality.

Comment 10

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

(In reply to Magnus Melin [:mkmelin] from comment #9)

Perhaps, but that it the issue: I think it requires rather significant surgery of the whole functionality.

Yes it would require some reworking: no longer show the attachment invite "inline", and do something more like how we handle openPGP attachments. I.e. find an invite attachment => load it into the invite area.

But I think it is needed anyway. The way that the invite is inserted into the <browser> alongside the html already requires convoluted and asynchronous steps of:

• Creating the invite document (https://searchfox.org/comm-central/rev/4e02ce9fa250616e3a8091b8fea0990a339c0e63/calendar/base/src/CalMimeConverter.jsm#62) but then converting it to a string to be parsed into the <browser>.
• Mixing this with the actual email content inside the <browser> https://searchfox.org/comm-central/rev/4e02ce9fa250616e3a8091b8fea0990a339c0e63/calendar/base/content/imip-bar.js#130
• Modifying the <browser> invite using a found item https://searchfox.org/comm-central/rev/4e02ce9fa250616e3a8091b8fea0990a339c0e63/calendar/base/content/imip-bar.js#371

This would be much cleaner if the <browser> and the invite area were separate because they could be constructed and loaded independently.

@lasana is this what you had in mind?

Comment 11

[Alessandro Castellani [:aleca]]

Indeed, the final goal for this new invitation display is to live in the message header and replace the IMIP bar, and it will be collapsible.
It will require a lot of changes, but it's a much needed implementation.

For inspiration, from paperlesspost.

Uh, that is very nice. That's a popup that appears when you reply to an invitation, right?
Definitely something worth exploring after the new invite is done, great stuff.

Comment 12

[Magnus Melin [:mkmelin]]

It's a web based service, and when you go to the "reply" link, this popup kind of thing is on that page yes.

I do think we should also use human language, not Accept/Decline/Tentative. Yes/No/Maybe may not fit in all occasions - as it can "sound" wrong to not accept an invitation, if you wanted to go but could not. Will attend/Might attend/Will not attend like they have in that popup could be a good weigh-off.

Comment 13

[Lasana Murray]

(In reply to Magnus Melin [:mkmelin] from comment #6)

Before you proceed further, you need to figure out if there is any feasibility of having buttons in the content.

This isn't in content its in chrome.

Please also add an event description (a longer one) for the event you test with. Showing the description is essential. Your current screenshot also doesn't show the time at all.

I have not reached there yet. I'm likely not to display descriptions in this widget if they contain html. In that case they can be shown in the message pane as usual.

Comment 14

[Lasana Murray]

(In reply to Henry Wilkes [:henry] from comment #10)

This would be much cleaner if the <browser> and the invite area were separate because they could be constructed and loaded independently.

@lasana is this what you had in mind?

Yes.

Comment 15

[Lasana Murray]

Attachment: Bug 1748449 - Part 1: Introduce new widget for displaying invitations. r=aleca

Comment 16

[Lasana Murray]

This is the first step in re-designing the invitation display meant only to lay down the basic structure and give a taste of the new widget. There is
still much work to do but doing it in one go is counter-productive.

Some tasks outstanding include:

1. Detecting the stage of the invitation and showing the appropriate UI.
2. Support for recurring events.
3. Toggle the timezone displayed.
4. Hiding the fields we do not have values for.
5. Improve the formatting of the attendees list.
6. Allow the user to hide long attendee lists.
7. Hooking up the action buttons.

Known issues (not exhaustive):

1. When there is a lot of information, the message pane gets pushed out of view.
2. When there is a lot of information, the widget is not as neat.
3. There are two scrollbars.

To address 1,2,3 I intend to hide some information when too much, offering the user the option to display when needed. For the description, I am considering leaving that out all together in favor of the message body or keeping it really short, displaying the excess in a modal, popup etc.

Comment 17

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

Will the event summary part of the invite use the same structure and design as the new event summary that is being planned in the calendar view for bug 1685007? An earlier design is here https://bug1575195.bmoattachments.org/attachment.cgi?id=9139613

There's probably some context-relevant information that would be in one, but not the other, but I was wondering if they could share the same template and styling to make sure the calendar components have a consistent look.

Comment 18

[Lasana Murray]

That would be nice, where feasible. I tried to put as many parts as feasible into their own custom element so making them more general should not be too hard.

Comment 19

[Alessandro Castellani [:aleca]]

That would be nice indeed.
In order to do that we will first need to clean up our CSS a lot, in order to create reusable classes that are not specific to 1 element or 1 implementation only.
In general, reusing templates and keeping the style consistent across the application is the goal.

Comment 20

[Lasana Murray]

Attachment: Screenshot_2022-02-23_20-14-13.png

Latest screenshot for visual feedback. I moved the minidate to the top so it's more visible with longer invitations and removed the grey background.

Comment 21

[Lasana Murray]

I'm going to try having this "overlay" the message contents instead of pushing it down causing two scrollbars. It could be dismissed via an X button if the user wants to see the message contents instead.

Comment 22

[Alessandro Castellani [:aleca]]

Marking this to leave open so we can continue using this bug for the follow ups.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7f61b80c5d25
Introduce new widget for displaying invitations. r=aleca

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/daf7854eeb59
follow-up - fix css errors (making browser_parsable_css.js fail). rs=me

Comment 25

[Kai Engert [:KaiE:]]

I get an error on c-c which refers to ./calendar/base/themes/common/calendar-invitation-display.css which apparently you have just added yesterday.

Any idea why I get the failure described in bug 1760012 ?

Comment 27

[Lasana Murray]

Attachment: Bug 1748449 - Part 2: Fix crash caused by wrong css url. r=aleca

Also changes #calendarInvitationDisplay to <html:div/>.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/565c734957f3
Fix crash caused by wrong css url. r=aleca

Comment 29

[Lasana Murray]

Attachment: Bug 1748449 - Part 3: Follow up use separate translations for calendar-invitation-partstat-summary. r=aleca

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/45dc671d6ed8
Follow up use separate translations for calendar-invitation-partstat-summary. r=aleca

Comment 31

[Lasana Murray]

Attachment: Bug 1748449 - Part 4: Hide invitation display when switching tabs or folders. r=aleca

Also hides the message body when the invitation display is shown.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f6baa37ea7ae
Part 4: Hide invitation display when switching tabs or folders. r=aleca

Comment 33

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/comm-central/rev/85bd743b131d
Backed out changeset f6baa37ea7ae which landed with a broken test.

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e6a22bcf5488
Part 4: Hide invitation display when switching tabs or folders. r=aleca

Comment 35

[Lasana Murray]

Attachment: Bug 1748449 - Part 5: Detect existing events, updates and cancellations. r=#thunderbird-reviewers

Comment 36

[Lasana Murray]

Attachment: Bug 1748449 - Part 4: Follow-up - Move invitation display to own container. r=#thunderbird-reviewers

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6dac3bcf57e6
Part 4: Follow-up - Move invitation display to own container. r=aleca

Comment 38

[Alessandro Castellani [:aleca]]

Moving forward, mark this as a meta bug and create child bugs blocking this one for the following parts.
No more multiple patches on the same bug.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a3595b3e889e
Part 5: Detect existing events, updates and cancellations. r=aleca