Closed Bug 1685007 Opened 4 years ago Closed 3 years ago

Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly - implement pref `calendar.events.defaultActionEdit`

Categories

(Calendar :: Calendar Frontend, enhancement, P1)

Product:
Calendar
Component:
Calendar Frontend
Version:
Thunderbird 85
Type:
enhancement

Tracking

(thunderbird_esr91 affected, thunderbird_esr102+ fixed, thunderbird105 fixed)

Status:
RESOLVED FIXED
Milestone:
105 Branch
Tracking Flags:
Tracking Status
thunderbird_esr91 --- affected
thunderbird_esr102 + fixed
thunderbird105 --- fixed

People

(Reporter: ronjouch, Assigned: thomas8)

References

(Blocks 1 open bug)

Details

(Keywords: ux-consistency, ux-efficiency, Whiteboard: [current status and instructions: comment 142][key summary: comment 75])

User Story

# Please read comment 75 before commenting #

Workaround: Press `Enter` after double-click, which will edit the event.

Attachments

(7 files)

thunderbird-useless-window-on-doubleclicking-calendar-event.png
27.07 KB, image/png
Details
1_google-calendar-double-click-on-event-brings-to-edit-screen.gif
170.81 KB, image/gif
Details
2_yahoo-calendar-double-click-on-event-brings-to-edit-screen.gif
161.69 KB, image/gif
Details
3_evolution-double-click-on-event-brings-to-edit-screen.gif
236.51 KB, image/gif
Details
outlook-preview-item-readonly-summary.png
8.82 KB, image/png
Details
autoconfig.zip
1.01 KB, application/x-zip-compressed
Details
Bug 1685007 - Add pref `calendar.events.defaultActionEdit` for editing events on double-click. r=aleca
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-esr102+
Details | Review

Steps to reproduce

See attached screenshot:

  1. Double-click an event in the Today Pane

Actual results

An intermediate window appears, showing a useless-to-me read-only view of the event.

From here, I have to click its Edit button to reach the actual Edit Event screen/tab I was looking for in the first place when I double-clicked on the event.

Expected results

Until recently (somewhere at the end of 2020), Thunderbird did the right thing: it opened the Edit Event screen for the event double-clicked.

Extra information and questions

  • Thunderbird 85.0b3 20201230181703
  • Linux/X11
  • Event is from a CalDAV Google Calendar
  • I read bugmail and am available for extra discussion / details

Is this expected behavior / what's the purpose of this intermediate screen?

Am I missing anything? Is there a pref to disable this screen that is useless to me and restore previous behavior or opening the Edit Event screen?

Ronan, this was implemented as a new feature in bug 1673654.

(In reply to Martin Schröder [:mschroeder] from comment #1)

Ronan, this was implemented as a new feature in bug 1673654.

Thanks for the fast reply, Martin!

Bug 1673654 doesn't make sense to me. In it, Magnus says:

For the Today pane, bug 1575195 is still not implemented - we should do the same there: open the summary pane instead of editing dialog. I think for the today pane it's even more likely you'd want to check the event details so that you know where to go, which meeting link to open and such.

I disagree. The Today Pane generally offers all the information I generally need about an event: time, description. On rare occasions, I want to peek at rsvps, location or recurring-ness, but for my use cases, 90% of the time, when I double click an event, I actually do it to edit the event.

As a consequence, to me, this new "summary window" adds friction, by requiring an extra click :-/ .

Also, Markus says in original bug 575195:

Quite often I need to check the details of an event to check description, location, and rsvp statuses. If it's an editable event that always pops up the Edit Event dialog.

Markus, how sure are you of this "Quite often"? Maybe it's true for you, but it's not true for my personal experience. Can we have a preference to disable the Event Summary screen?

A better flow for this would be to open the event summary and have an edit event button in there (since editing is a secondary action for an existing event).

Editing is a primary action for an existing event for me, and the secondary action for me (looking for some bit of event information) is possible from the Edit Event screen, so I prefer being brought directly to the Edit Event screen, which fits my primary use case (editing the event), and my secondary too (occasionally peeking at some event metadata).

This is also similar to how e.g. Google Calendar and others work.

True but I don't think it's good UX inspiration. If Google could be talked to, I'd have filed a bug on Google Calendar to ask them to reconsider this.

Flags: needinfo?(mkmelin+mozilla)

One more thing:

  • For Markus professional usage, it's common to want to look at event details (location, meeting link, attendees rsvp, etc).
  • Whereas my usage of Calendar is personal: for 90% of my events, location is known to me, there's no meeting link, no attendees. So, I rarely need to view event metadata apart from time/duration/title, which are visible in the Today Pane. Thus, my frustration about this extra screen that, for my use cases, is useless.

Could Calendar discern between both types of usages, and offer the intermediate step only to users like Markus? I mentioned above an extra preference, but maybe there's something better?

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

Flags: needinfo?(mkmelin+mozilla)

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

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

That's not my experience. Here are a few edits I made the last few days, that motivated me to chime in here:

  • I receive a message informing me the delivery date of my weekly veggie basket changed.
    → Okay, I update the event that reminds me to go grab it.
  • A friend tells me she won't be available for a meeting we had planned.
    → We decide a new date, and I update the event.
  • Finally, a family member warns he won't be back home today, and asks I feed his dog once more.
    → Alright, I update the recurring event to postpone by one day the Until field.

Your professional experience is to want the summary view 8 times a day, before each meeting, to know your meeting URL, and you rarely edit events. Thus, you like the new summary view.

Whereas my experience in a personal-life context is to never need more than time & description, and to frequently edit events. Thus, to me the summary view is only extra friction with no benefits.

→ We do have different needs.

  • What about a preference?
  • Alternatively, what about an Edit Event right-click / context menu that would let me go directly to the Edit Event screen? (Same number of clicks as clicking the Edit button of the summary window, but at least it would skip the intermediate window).

Thanks for the explanation. However, that shows these are exceptions: Usually the veggie basket gets delivered on time, usually (I'd assume) the fiend will be available as expected etc. So in summary it's an unusual activity to have to open the event at all for you.

I'm not strictly opposed to making it configurable, maybe through double-click or something. But it's a lot of code to change (!) so I don't think we'd want to pursue it atm.

To consolidate discussion, Bug 1685550 offers moving viewing events behind a single click in a popover (like Google Calendar does), preserving the current doubleclick-to-edit and avoiding the current changed behavior that

is causing two many clicks and is anti-productive for those constantly editing calendar items

I'd like this a lot too. It's been a few weeks since this change landed, and like the author of Bug 1685550, I too feel that

After a few beta upgrades, the brain muscle still does not adjust to the new TB behaviour

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

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

You may not understand it because it isn't your workflow, but it does not mean it is not relevant, needed or used, end-users out there do edit a lot of events per day (I know I am one of them) that are not Exceptions and the removal of double click an event to allow direct editing of it like it was before, does not make sense and is counter productive for those editing existing events all the time.

You simply make an assumption that an event is created and then only read (eg meeting create then join a meeting) but that is not the only usage for a calendar (eveny or tasks). Basically your assumption is read often, edit rarely.

But that is a wrong assumption, and by your own choice you reduce the freedom of end-users by forcing them into a specific workflow by design which was recently introduced.

Editing should have an equal weight with reading especially in some workflow you may need to edit items more often that just once upon creation. To change any field (Title, Timing, Description, etc) at anytime as environment changes... a meeting may be rescheduled, more participants added, description changed to add point to talk at the meeting, take minuttes during a meeting, create a small report after a meeting of key point addressed, those are only few example.

My personal view is that edit windows is sufficient to read and edit... it could have been enhanced to allow clickable links and some advanced formatting similarly way the compose recipients feature was re-designed... instead of creating something new that hinder workflow...

Now if you want to keep two views one for View one for Edit event at least allow simple paradigme:

  • single click to view,
  • double click to edit (directly) to avoid multiple click required to edit an event.

The double click was already in place historically to edit event/task there were really no need to remove that feature... no one asked to have it removed.

Yet, when I ask for why, I don't get any examples...

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

Yet, when I ask for why, I don't get any examples...

Magnus, I provided three examples in comment #5, which you discarded as "exceptions", choosing to only focus on your own use case and ignore other users'. Again, that a UX change is an improvement for you doesn't magically address the fact that it's a regression for other use cases. The fact is that your redesign adds convenience on one hand for some users, but at the cost of annoying other users on the other hand. Then, as you you ponder the minuses, you stay biased by your own use case, and quickly declare the minuses negligible, because you don't want to reconsider. To us complaining here, it's a clear annoyance, and it feels bitter to be ignored when we attempt to communicate the problem with your design. So, everybody gets predictably annoyed :-/ .

As a UX designer, it is your responsibility to understand the various use cases, to be able to produce interaction redesigns that are a net improvement for everyone. In this issue I see you 1. avoid this responsibility, in order to 2. be done with the damn thing already.

Can you engage in honest discussion and try to see a point of view that isn't your prior?

I didn't discard them, though I still think they are exceptions. Exceptions are of course valid too in their own way.

I'll again bring up the comparison to how calendars work for both phones, and well, any other calendars I know - both on the web and desktop. You get the "view" first, then you can edit from there.

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

I didn't discard them, though I still think they are exceptions. Exceptions are of course valid too in their own way.

But they are not exceptions in my use case! The real exception in my use case is the need to view an event! (Since I usually have all the information from Event {Date, Title}). You may view "editing 5 times / week" in absolute terms as "exceptional", but it's still much more frequent than my need to view an event:

View Event Edit Event View / Edit ratio
Magnus 25 times / week 1 time / week 25
Ronan 1 time / week(*) 5 times / week 0.2

(*) More often than not it's 0, but let's say 1/week to have non-zero numbers.

The "View Event" screen fixes your 25 times / week use case, but adds friction to my 5 times / week use case! You're judging "exceptional" based on A. your high 25 ratio and B. your personal judgement as "5 times a week" = "exceptional", neglecting my 0.2 ratio and neglecting that, frequent or not for me, you objectively made my experience a bit more annoying.

Let's picture an example with similar frequencies.

  • I work at a local shop, and every day I must create a new timesheet entry. I do this by clicking on "Create Timesheet", which brings me to the Create Timesheet screen, which takes a long time to load, because Enterprise Software Is Slow.
  • Enters Alice, my manager. She complains to you, UX designer of the timesheet app, that the "Create button" is next to the "Report" button, and she frequently mis-clicks Create instead of Report. As a result, the slow "Create Timesheet" opens, is slow, and she has to wait a long time for it to open before she can close it and get her report.
  • You arrive, look at Alice's use case exclusively, and add a "Are you sure you want to create a timesheet" intermediate screen after clicking the "Create Timesheet" button.

By doing that, you fixed Alice's problem, but you added a constant annoyance for me. That I do it "exceptionally" as "only once a day" is meaningless and disrespectful of my experience: you did make my situation objectively worse. You Made Me Think.

A better solution would have been to add a bit of padding between both buttons (no more accidental clicks, and I don't have the extra useless screen), or to make the Create Timesheet screen faster!

I'll again bring up the comparison to how calendars work for both phones, and well, any other calendars I know - both on the web and desktop. You get the "view" first, then you can edit from there.

Not true. (My excuses for the typo in your name in the GIFs, I don't want to re-do them)

  1. Not true for Google Calendar; see attached GIF 1: on single click there is a popover to view the event details (which is fine and which I'd totally like in Tb/Lightning too), but double-click works as expected and brings me directly to the "Edit Event" screen.
  2. Not true either for Yahoo Calendar; see attached GIF 2. Same thing as in GCal: popover on single click, then double-click edits.
  3. Not true either for Evolution; see attached GIF 3: this time on mouseover rather than single-click (okay why not, since this app is clearly desktop/mouse-centric) there is a popover (again, all good), but double-clicking works as expected and brings me directly to the "Edit Event" screen.
  4. I don't have a copy of Outlook here, but last time I used it, double-clicking an event opened the Edit Event Screen.

Finally, rejecting your "on phones" argument. Of course phone UX is different! We shouldn't model desktop interactions after phone interactions, they're different beasts with different constraints.

Flags: needinfo?(mkmelin+mozilla)

Again, why remove an existing feature that nobody asked to remove in the first place!

I have really hard time to believe we have to put so much efforts here to convince you of something that should be self explanatory and really not rock science!

Simple paradigm:

  • Single click => View (+Edit button if you want to, it may have its use case) - Recently implemented
  • Double click => Edit directly (which is a different, relevant and still valid use case) - Was already implemented in TB, but recently removed (regression)

Valid for all interface: Dekstop and Mobile

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

I didn't discard them, though I still think they are exceptions. Exceptions are of course valid too in their own way.

And we are trying (but failing obviously) to tell you they aren't just exceptions but real valid use case out there, so you should re-think about it!
If you could clarify what sort of examples other than those already provided you are expecting to be convinced maybe that could help us clarify better.

Try yourself, what is faster and less hindering your action between:

  • double click and event and be able to edit it directly = one click required

and

  • double click to view event first (irrelevant if the intention of end-user is to edit the event), move the mouse towards an Edit button, click again to edit the event = two to three clicks required
    In the worth case of a recurring event clicking edit would not even be sufficient you would still need to move the mouse to select the correct option in a selection menu that would open...

Now, for each option above, do it 20 times in a row, which option is faster in terms of performance (and least nuisance)?
The first option is definitely a shorter way to achieve result...

Allowing only the second option is completely counter performant as you create extra steps (that brain muscle do not adjust to) that were non-existent previously in TB so again by our own thought and choice you hinder performance of end-users and create usability clutter!
It does not mean the Edit option is irrelevant in the View event windows, but keep the first option (that was already existing) in parallel to allow direct editing as it is needed. One does not prevent the other. They are not mutually exclusive.

All that is asked here, is to fix a regression recently introduced in TB that currently prevent to directly edit an event by double click on it.
It would not prevent in parallel to keep what you see as an improvement to be able to read an item to more easily access an online meeting via a link... simply make it readable via a single click instead... and keep double click to allow direct edit of the event like before... there were really no need to remove this existing feature.

If I understand correctly from Alessandro, this is not technically impossible to achieve... what I suggest as a balanced and acceptable compromise...
It may require though to remove the inline editing of Title of event, but if you can double click an event to do so easily then that shall not be an issue... indeed if you think double clicking an event to Edit is an exception then single click an event to inline edit Title would even be more exceptional than that so shall not be an issue for you to consider :-)

I'll again bring up the comparison to how calendars work for both phones, and well, any other calendars I know - both on the web and desktop. You get the "view" first, then you can edit from there.

Comparing with mobile interface seems ill-advised:

  • They are mainly designed to consume data (aka read data) and not necessarily to edit numeric data in a performant manner, especially on mobile devices (apart from messaging perhaps) which provide only small screen area.
  • Most people still use primarily a fully fledge computer to edit numeric data, aren't you?
  • The paradigm single click to read, double click to edit/write is still valid on a mobile device interface, one does not prevent the other. TB could introduce it in its own mobile app once it is out; to add on the wish list :-)
  • Thunderbird being mainly a Desktop software at the moment, it does not need to mimic mobile interfaces that are not necessarily the grail of UI in term of performance and rapidity to achieve repetitive tasks.

In the future, please consider minimising the number of clicks (and keyboard shortcuts) required to achieve tasks at all time when re-designing TB UI, that shall give you an answer to your own question: Less clicks = always better (especially in repetitive actions)

Thanks for the research.
Anyway, the point I'm trying to make is, you either A) don't click the event open at all much, or then B) they click it open to get the details.
For case A, how it opens doesn't make any difference. For case B, you want reading mode.
I'm not opposed to finding a way to open in reading mode, but not sure what that way would be. A web page is a bit different than what we usually do with selections and clicks (we usually don't open things by single click, that's for selection).

Flags: needinfo?(mkmelin+mozilla)

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

Anyway, the point I'm trying to make is, you either A) don't click the event open at all much,

I am not sure to understand your point A) are you refering to mouse over the event without click?

or then B) they click it open to get the details.

Here you meant single click or double click because there is a difference...

there is a C) case where you click to edit the details, this is another intent or action altogether.

In previous TB version double click (the same action) had two intents:

  • read details
  • edit details
    both done in one and uniq view

Now that those have been split into two different views you need to distinguish the two intents via two separate actions.

For case A, how it opens doesn't make any difference. For case B, you want reading mode.

For case C) you would want directly the writing mode

I'm not opposed to finding a way to open in reading mode, but not sure what that way would be.

I would say mouse over the event (but maybe too cluttering if not the intent, also not mobile friendly) or single click which may be the obvious and already implemented elsewhere... while a double click could allow editing it.

This could apply to all calendar views where relevant, including today's pane.

If I am not mistaking a double click allow to edit a Pill in the newly designed compose window for emails.

Similarly a double click on a Contact in addressbiok could allow direct editing of the contact.

(we usually don't open things by single click, that's for selection).

That is not entirely true:

  • if you select an email msg it loads it in the preview pane in read mode.
  • If you single click select a contact it would load info about it in a preview pane... that is my understanding from mickup I have seen about adressbiik design revamp...

...so that would be same paradigme for most editable objects... including Calendar event/task...

In the Today Pane you won't select items I suppose, you may just click on one to view details or double click to edit.

In the Calendar view you would select items but a single click could both select the event and preview its detaila in read mode, while double click could allow direct editing without extra click on an Edit button in read view window.

If the intent is to move event in calendar then the read view of event could simply disapear upon move and pave the way to the floating selection relocation witout clutter. Similarly if CTRL or SHIFT pressed for multi selection via single clicks... the read view window could disapear by itself (or not appears in that case).

When an email msg is clicked two things occur:

  • msg content is loaded in preview pan
    and
  • msg is selected for further action (drag&drop, delete)

Same could happen for Addressbook Contact and Calendar Event/Taskany or any editable item in TB.

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

I'm not opposed to finding a way to open in reading mode, but not sure what that way would be.

After weeks of using the new way in TB beta, I am still annoyed by the fact when I open an item in calendar to edit it, it is in view mode only and I have to move the mouse to the Edit button and click the button. When you edit a lot of item per day that remain of a great annoyance! Nothing to do with being old school, I am just saying that from an efficiency point of you...

While my preference would remain the double click as per experience and research above, what about the following options:

Option1:

  • When you mouse over the item - some summary detail appears in read only mode next to it (like Outlook does see attached) - allowing you to click a location link if it is a meeting to join
  • If you double click the item - it open in Edit mode like it was before.

Option2:

  • allow middle click to directly edit the items - currently when I middle click an item nothing happens but it could open item directly in Edit mode - this may be an acceptable compromise perhaps - still not ideal because it requires end-users to know how to middle click - which is not as simple as left click or right click and require a learning curve (possibly some additional settings in some environment for it to work) - but at least there would be an easy quick way to do it. But no other calendar app behave this way so may still looks odd to end-users.

In addition with any options you could also allow:

  • pressing the E key when item is selected to trigger the Edit action (could be indicated as a shortcut in context menu)
    -- the same way you may press O key to trigger Open (to be consistent)

It would really be great if this issue could be reviewed once more and possibly addressed prior 91.x ESR is out... or shortly after...

While it is appreciable to be able to view an item and be able to click a link to join a meeting, it is really annoying not to be able to quickly edit an item in calendar via a simple double click.

In Outlook if you double click an item it opens in Edit mode... so as it is likely the main competitor app to Thunderbird, it may be judicious to ease migration for Outlook users to Thunderbird by allowing them to use it in a similar way... at least on this particular simple feature...

Surely there should be room for improvement here...
Any chances?

Flags: needinfo?(alessandro)

I think we can explore some improvements in this area.
I agree with Magnus that always opening an event for editing is not "the common approach", but I also understand how some users (or even a lot of users) might want that as the default workflow as they don't find a summary dialog useful at all.

I think we can find a solution that could accommodate both use cases.

Originally, I proposed to implement the following approach:

  • 1 click to open a doorhanger (inline popup) with the event summary. old mock-up here: https:// bug1575195.bmoattachments.org/attachment.cgi?id=9139613
  • 2 clicks to open the editing dialog/tab.

This solution was postponed for timing and technical reason, but maybe now we could explore this type of solution?
This is also sort of related to bug 1724075.

Flags: needinfo?(alessandro)

(In reply to Alessandro Castellani [:aleca] from comment #21)

I think we can explore some improvements in this area.

We really should! This has a high potential of backfiring big time for users who frequently need to edit their events.

I agree with Magnus that always opening an event for editing is not "the common approach", but I also understand how some users (or even a lot of users) might want that as the default workflow as they don't find a summary dialog useful at all.

I think we can find a solution that could accommodate both use cases.

We really should! Different users have different needs - it's important to consider this always. Thunderbird has been successful because it works well for different kinds of users with different scenarios. There's absolutely nothing special about frequently having to edit events, and there's a thousand reasons to do that beyond just changing time and location. E.g. I imagine that in a busy enterprise, events may get reshuffled all the time, or relevant information added.

Originally, I proposed to implement the following approach:

  • 1 click to open a doorhanger (inline popup) with the event summary. old mock-up here: https:// bug1575195.bmoattachments.org/attachment.cgi?id=9139613
  • 2 clicks to open the editing dialog/tab.

Sounds good if we are able to figure out some of the details.
The mockup in Bug 1575195 Comment 4, attachment 9139613 [details] looks great.

  • We must ensure that we have sufficient space to show the preview where we want to show it. Preview location must auto-adjust even for events which are currently shown closer to the edges of the calendar pane.
  • Check how this scales to week/month/multi-month views.
  • Please note that single click can also be used to select an event, including multiple selection with Ctrl or Shift - you need to define your single-click preview behaviour for that. In message reader, we show summary preview - maybe that could work here, too (at least to say that 3 events are selected, maybe to add minimal detail). Otherwise, perhaps you could just show preview of the last focused&selected event, which could also be useful (e.g. to check if I'm really selecting the right events for deletion).
  • There is no conflict between single-click-preview and single-click-edit-label because single-click-edit-label requires two single clicks with an explicit pause. You can only single-click-edit-label on an event which you have already selected and previewed with your first single-click. I don't see any problems here and I find second single-click to edit label convenient and intuitive.
  • Please keep the tooltip (at least) for quick, non-stick preview. I do not want to click on every item just to have quick glance at the details. Tooltip goes away when clicking on an item, so it does not interfere with single-click-to-preview.

(In reply to Alessandro Castellani [:aleca] from comment #21)

Originally, I proposed to implement the following approach:

  • 1 click to open a doorhanger (inline popup) with the event summary. old mock-up here: https:// bug1575195.bmoattachments.org/attachment.cgi?id=9139613

You could also explore/experiment with mouse over +1-2sec wait prior showing doorhanger as alternative to single click (that could be kept for selection)... but maybe less mobile friendly...

See Also: → 1724075

(In reply to Richard Leger from comment #23)

(In reply to Alessandro Castellani [:aleca] from comment #21)

Originally, I proposed to implement the following approach:

  • 1 click to open a doorhanger (inline popup) with the event summary. old mock-up here: https:// bug1575195.bmoattachments.org/attachment.cgi?id=9139613

You could also explore/experiment with mouse over +1-2sec wait prior showing doorhanger as alternative to single click (that could be kept for selection)... but maybe less mobile friendly...

Another possibility could be to have a preview pane for calendar items in a similar way to email preview pane, but maybe not enough view space area to allow it in calendar view. I don't know if that has been considered/experimented with... I think it was mentionned somewhere... so I put it here for reference... Doorhanger may remain best compromised though...

I just updated to Thunderbird 91, and immediately ran into this issue.
I use calendar as an assistive tool to keep track of things I can't reliably remember anymore. I have a "Diary" event each day, that I edit multiple times a day to add things.

An example entry for a day is:
9:00 Did this
10:00 Took Medication A
12:00 Did that
13:00 Took Medication B
15:00 Met with Person X

I've been doing this since 2009 now, and it has helped my greatly in keeping track of my life. I often use the search feature to figure out my past and when I did certain things to compare it to what I can remember.

Calendar may not have been designed for this, but it was the easiest tool to set up for exactly what I needed, that wasn't some obscure smartphone app that would store all my most private data in the cloud.

I would get reminded how much I hate this change several times a day every day when I add some data to the entry.
If I just want to see the content of an event, I just hover it. I thought that's what everyone would do. Why open a popup for that?

I started using Mozilla software (Firefox and Thunderbird) almost 2 decades ago, since they were open source and highly customizable.
Sadly that changed to them being a certain way that caters to some imaginary group of users, and makes everyone else infuriated.
I enjoy tools that are productive, and suddenly after 13 years having to do an extra click every time for no reason, and being unable to undo it in a setting, makes me question what Mozilla is trying to achieve. Many things haven't aligned with me in a long time, but I endure them or look for workarounds, since there are no good alternatives, and I don't have the energy anymore to explore and evaluate other options, just because one more thing got worse.
It would be easier to just patch it and do my own builds in the future than finding something else and getting used to an even more different UI.

I do hope though that you reconsider this decision. It's one thing to have it like that from the start, but suddenly changing it with no way back seems arbitrary.

After updating to Thunderbird 91 not being able to edit an event with a double click is a major obstacle to using Thunderbird for me.
Since editing events is the most used features in the calendar I'm using, this affects me and I'm assuming others in a bad way.

Working in UX design and web development here's my 5 cents:

  1. Consistency
    This is probably the main reason the change feels like a regression to me. Double clicking an empty space does what I expect: It shows the create event popup.
    Double clicking an existing event does something different now. If we'd user test this, most users would probably expect double clicking to do the same thing in both cases.

  2. Google calendar does it too (double click to edit)
    I double checked, and what they do atm is single click opens a small popup similar to the current one in thunderbird and double clicking brings you directly to the edit screen.
    I'm confident they user tested this and "know" that most of their users think is workflow adds the least amount of friction.

  3. Looking at the 3 tickets there's quite some opposition to this change

  • 2nd comment in 1575195 (the original issue) by Stefan Sitter
  • Paul Morris' comments in 1575195 also describing the different approach of google (single click -> read only popup, double click -> editing)
  • Comments from Richard Leger in 1575195 and here
  • Comments + issue from Ronan Jouchet here
  • Comment from Thomas D.
  • Comment from djindb
  • My comment

Reading through these issues and comments i see different use cases we want to serve:

  • Editing existing events
  • Previewing event invites before accepting them

I strongly disagree with Magnus and Allesandro's assumption that editing events is a secondary action. The existing comments here prove otherwise.

Just as Thomas I also see this issue having the potential to cost Thunderbird users, which makes this a delicate issue.

Also I see the pain this change tries to alleviate and generally love the scratch your own itch thing!
Since Thunderbird has quite a large userbase compared to other projects UI/UX changes should allow for different workflows.

Why not implement the single / double click distinction?
Previewing would be very easily accessible, just as editing - and it would be consistent with the rest of the UI and other calendar UIs.

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

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

I fully disagree. Especially in case of recurring events, they need to be updated frequently rather than being viewed. But not only recurring events: I cannot imagine a use case where I want to view an event. I can view it in the calendar view. But when I double click it, I want to edit it, not viewing.
So I would greatly appreciate to have an option available which allows to disable the preview dialog.

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

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

Your lack of understanding is hard to comprehend. It's quite simple: my use case, and that of others who have posted here and elsewhere, is different than yours. While I can see why some might prefer this new UI/UX, to me (and others) it is extremely annoying and adds an unnecessary step to what was previously a simple process.

Looking for a use case?
Yesterday, I wanted to make a detailed week schedule in Thunderbird, including information from my spouse's agenda and mine.
This included editing tens of events. I can tell you ... not having the double-click edit function at my disposal, it was really bothersome.

The edit function has always been available via double-click in the Lightning calendar, so the new Summary Dialog adds unwanted extra steps.

I hope comment 21 / comment 22 can be implemented soon! Seems like the ideal solution to me.
In the meantime, is a (temporary) preference possible to go into edit mode through double-clicking?

Yet another plaintiff...

"...After double-clik on the rectangle of task or event in Calendar Tab, appear window, in witch we can not to edit description or title. We mast to press the button ”Edit”. It is not usability. We mast to do two action instead one. It is a bad decision. Please return the old behaviour..." - Alex B.

Source: https://thunderbird.topicbox.com/groups/ux/T2c64762cc85a00c5/the-task-and-event-in-the-calendar-tab-not-editable-by-the-singl-double-clik-tb-91-1-0-64-bit

I concur that it makes sense to open single events that the user created for himself (not a meeting with invitees) directly in the edit mode. Such personal, one-time events can be seen like a personal notebook, TODO list or similar, and are frequently edited in some work flows. I can see how disruptive this additional click would be for such use cases, and I think it makes sense to change this case back to default to edit mode.

The situation is different for meetings with invitees. A modification there will trigger an updated invitation to be sent out to all invitees, so frequent edits are undesirable and it makes sense to make an extra click for those.

For recurring events (including personal ones), the reason for the change was a technical necessity: We cannot know whether you want to edit the entire series or just this one instance. In this case, the Edit button has a fly-out menu that allows you to make that choice. This was not properly handled in older versions of Thunderbird.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All

(In reply to Ben Bucksch (:BenB) from comment #32)

The situation is different for meetings with invitees. A modification there will trigger an updated invitation to be sent out to all invitees, so frequent edits are undesirable and it makes sense to make an extra click for those.

This is a false good idea as you would then create inconsistances in TB and confuse end-users. Single click to read (doorhanger) and double click to edit all events/tasks is a much simpler paradigm and is consistant while fitting all use cases.
Meeting invite shall be editable to change reminder or a description to be able to add agenda or questions we may want to ask during meeting or take notes perhaps... add attachnents... that would be a much better improvement that could be made accessible via double click (edit).

As for reccurent events, the current behaviour of TB to just ask upon saving if changes shall be applied to the serie is the current event make sense and works just fine. I do help a lot of people with TB and I never heard any end-users being unhappy with that behaviour. Have you ever had end users complaining on forums or in bug reports about it? I doubt so... so why trying to change something that just works...

(In reply to Richard Leger from comment #33)

This is a false good idea as you would then create inconsistances in TB and confuse end-users. Single click to read (doorhanger) and double click to edit all events/tasks is a much simpler paradigm and is consistant while fitting all use cases.

I am pro consistency, so single click shouldn't be used for anything other than selecting the event/task.
Double click to edit is efficient and expected behavior, and I would prefer it.

I can however also see how the editable view may be too cluttered for people who just want to read the event/task, so there is an argument for a simpler view.

We already have hovering as a mechanism for reading, which I very much prefer. It also makes more sense than clicking if you just want to read. If you have a month worth of events you can just quickly hover through them without opening window after window.

Is there any way hovering can be improved, so that it shows all content that's in the read window and fulfills all of its purposes?
Then double click would be free for editing.

Only issue I see with that is that the hover vanishes when the mouse moves, so links in the event/task can not be clicked. Some clever solution would be needed for that. Turning the hover into the reading window in some way that doesn't involve double clicking the event and is discoverable would solve that, or it could be accepted that clicking links requires opening the edit window.

Regarding invites being sent out on accidental modifications, there could be a simple dialog asking if you want to "Save and send invites" or "Undo modifications".
Instead of Edit requiring an extra click every time, this would only require an extra click when it matters.

Double clicking to open the item, instead of editing it, is consistent with the behaviour in the calendar views. So the new behaviour makes sense.

I feel like an easy solution here would be to add "Edit" to the context menu, since:

  • we already have a context menu for the Today items; and
  • the calendar view context menu already contains "Edit", so this would be a further consistency.

For my personal flow "Edit" in the context menu would not help. As someone already mentioned since the first release of Sunbird the expected behavior when double clicking on a event was to open in edit mode. As much as I don't like to use Outlook as a comparison. There it is the same, double click opens edit mode.
If you need to implement it like this. Then give the users the possibility to the change the behavior in preferences. At the moment it looks like only developers prefer the new solution and users request to turn this off again.

I think I have an elegant solution, that would actually improve the user experience for both consumers and producers of calendar entries.

We already have a read-only setting on a per calendar basis which might have slightly different semantics (disallowing edits entirely), so I am suggesting an Edit/View Mode toggle setting per calendar.

Edit Mode => Double click means Edit in that calendar.
View Mode => Double click means View in that calendar, and Edits require pressing the Edit Button. The ability to edit on a button press is an important difference to the read-only setting, that correctly doesn't show the Edit button.

That way people could set their calendars up as they need in a flexible, safe and efficient way.

Business calendars could be set to "View mode" by consumers to avoid accidental changes, and "Edit mode" by producers who have to input all those entries on a regular basis.
Private calendars could be in edit mode permanently, for efficient editing.

Ultimately this issue is not about whether people are consumers or producers as we initially tried to differentiate to decide for or against this change. Their role can actually differ based on each calendar.

To be honest, I don't understand all these discussions here about such a trivial topic. Why can't it simply stay as it was before? I don't think that users complained that double-clicking opens the edit mode.
Like in any other software, a single click should select the item.
A double click should open it for editing.
I'm a professional software developer and I know from my experience that customers might have a different opinion about usability than me. But I cannot simply implement it in the way how I like it. I have to listen to what customers request. Here in this discussion, I read that lots of users complain about the new behaviour. So why can't it simply be implemented so that user of thunderbird like it like they liked before?

I share Richard's sentiments in Comment 33.

Double-clicking for editing has been the default behavior in Lightning for years, without anyone complaining about it.
Frictionless, consistent and efficient. The same behavior is found in MS Outlook, the industry standard.
When double-clicking a recurring event, a small context menu (not an intermediate window!) lets you choose between editing the instance, or the whole chain.
And why the fear of inadvertently editing events? That takes at least a double-click and pressing the Save button?

Introducing a simplified reading view (on hovering or single-clicking) is a welcome change, as long as it doesn't stand in the way of the double-click edit behavior. I hope that part of the change in TB 90 gets reverted soon (can this bug get an assignment please?). Thanks!

Adding my 2 penny's worth to the argument that the implementation of the summary window is an unessesary and indeed pointless feature

Looking at the age of this bug entry it appears that this "feature" has been around for a number of months but my installation of Thunderbird has only recently exibited the problem so I don't know if it's something that being gradually activated to guage user respose but if so please take this user's response to it as totally negative

I've only skimmed through the first few posts on this thread where it seems the author(?) of the feature is dismmissing anyone who says the feature isn't right\needed as being outliers which comes across almost as bad as the infamous "you're holding it wrong" comment that Apple made when user's were reporting reception problems with one of the newly launched iPhones back in the day, is he implying that all the users who don't like the feature are using Thunderbird wrong and only his way is right?

From my perspective I would say the need\desire to have a separate summary screen is an outlier use when compared to going directly to the edit window which is what the vast majority of users across multiple different calendar tools are used to and expect

Anyway

From my perspective the summary screen serves no useful purpose what so ever and I can't envision a situation where I would ever make use of it so to have it forced on me with no ability to disable it is somewhat annoying to say the least

The argument that it's "useful" to have a summary screen appear makes absolutely zero sense when the full summary for a calendar entry can be seen just by hovering the cursor over the entry in the calendar

It's also possible to read the full summary in the edit window so why would anyone think there would need to be a separate window to show the summary especially one that forces an additional step for anyone wanting to actually edit the entry?

A question that has also been asked is "how often are people editing calendar entries"

For me I'd say every single calendar entry I make gets edited at least once and possibly multiple times

Why every single entry?

My workflow for creating a calendar entry is to drag out a selection box covering the duration of the entry, this creates an empty entry that I then double click to open the edit window where I can populate the entry with the needed info or at least that was the workflow until recently as now that double click on the new entry opens a nearly empty summary window where I have to click edit to actually get to the window I actually want to use

I also regularly edit calendar entries to add info or maybe fine tune the times for entries where I only had a rough idea of the times (yes I also use the ability to drag the entry around to make adjustments but sometimes I need finer control of the times than the main interface provides which requires me to edit the entry)

My workflow is one that has served me well across numerous different calendar applications\versions for the best part of a quarter of a century but now someone has decided to break that workflow because they've decided forcing the display of an additional useless window is a good idea

A Compromise Suggestion

I'm sure both sides could continue to make their aguments for and against the summary window and one side or the other (or perhaps both) isn't going to be happy with whatever is decided so as a compromise I'd suggest keeping the summary window but make it optional by providing a setting where user's can chose what happens when they double click on an entry, that way people who want it can have it, those who don't want it banish it never to be seen again

Like djndb described in post 25, I use the calendar as a notepad to help me organize my life. Some entries are real events but many are notes to myself. Examples: what I intend to make for a meal, medical notes, check cat supplies, etc. The vast majority of the time when I open an event I want to change it, either to add information or to note progress on whatever it is.

For me the summary window is a nuisance. Please make it possible to restore the old behavior.

Thank you

I agree with all those who think that clicking on an event should go to the edit window. Many of us do edit events frequently, and the intermediate summary window is a nuisance. Please either get rid of it, or provide a configuration setting to go directly to the edit window.

Whether it's the right work flow or not, I think people - including me - have been conditioned to expect a double-click to open the edit window. I also think it's natural and intuitive that way which is why it stuck with a lot of us.

So I agree with the rest of the detractors that an intermediate window is neither useful, nor intuitive. I can do the following right now

With a click-and-drag:

  1. Move the event around - (intuitive)
  2. Shorten or lengthen the event by modifying the start time or the end time - (intuitive)

With a mouse-hover:

see a tool-tip of the event with a truncated summary/description - (okay but not visually friendly - no highlights or contrasts to help make important information stand out)

With a Single-click: ???

(I don't understand what the function of this is)

Right-click:

  • Shows edit right there - intuitive
  • Shows "open" - (NOT intuitive - for reasons described above. Edit window should also serve as the view window)
  • Cut-copy-paste-delete - ( okay ; I've personally never used this; DEL key works for delete usually. I don't know if anybody else does. Its existence does not bother me )

===

The change I'd find useful is

  1. Make single-click show the tool-tip like the new mockup shows.
  2. Make double-click open edit window
  • Make changes within the edit window undo-able (CTRL+Z) + allow discard of unintended changes in the edit window

-Y-

Thanks for your proposal how to fix this issue.
Let me explain you the need of a "Single-click". In my workflow, I use it in order to delete an event, like I use it in any other application to delete something. How? I select the item using the mouse (right hand uses the mouse), the left hand uses the keyboard by pressing the "Delete" key. This workflow is faster than right-clicking an item and searching for something like "delete" in the context menu. And it is faster than opening an event and clicking the button "delete" there. My perfect workflow is fast, and I cannot imagine of a faster workflow in this situation than using mouse with one hand and keyboard with another one.
It is ok if single-click shows the tool-tip, but like in any other application, a single click should select an item. It should not just show a tooltip.

Double-click should definitely open the edit window.
The rest of your explanation sounds good.

Actually, now that you say it, I see that I was being an idiot. I delete my calendar events exactly the same way. I click on it once and then hit delete. I do get why single-click select is useful now.

I agree with you that a single click should select the item and probably also show a tool-tip. Hitting DEL should bring up the confirmation window for delete.

I was also pleasantly surprised to find that I can hold down CTRL and select multiple events and DEL them at once. So yes single-click == useful and intuitive.

Don't worry, we all are humans, so sometimes we need someone to tell us how we work, only then we recognize that we do it intuitively exactly like that. I believe that you are definitely not an idiot. Thanks for your reply and for your understanding.

I just created an account here, after literally 10+ years of using Thunderbird for all my mail accounts + calender, just to say, that double click should DEFINITELY bring up the event EDIT window! :) as it always has been! Hope they devs 'fix' this very soon! <3

Another user here who edits events on a regular basis and finds the Summary window now popping up since 91.2.0 (on Mac OS) a nuisance. I think the compromise suggested by @maniax in comment 40 above is a good resolution.

I also just created an account for this after using TB for 15+ years, not much to add to the general sentiments, only that it's now inconsistent with other behaviour like opening a task - there double click opens the task and not just some extra summary window. Additionally this is widely used outside Thunderbird's Calendar and hence expected behaviour. Just imagine opening a .txt file and then getting a summary of what's inside.
In all honesty, I'm either rolling back to a previous version or switching to a different software if that stays and I'm not able to change it in settings like it has been suggested in comment 40.

(In reply to karhima from comment #50)

I also just created an account for this after using TB for 15+ years, not much to add to the general sentiments, only that it's now inconsistent with other behaviour like opening a task - there double click opens the task and not just some extra summary window. Additionally this is widely used outside Thunderbird's Calendar and hence expected behaviour. Just imagine opening a .txt file and then getting a summary of what's inside.
In all honesty, I'm either rolling back to a previous version or switching to a different software if that stays and I'm not able to change it in settings like it has been suggested in comment 40.

Your comparion with a txt file made me simle. It's an excellent example where a previous also wouldn't help a user.
I would really like to understand why the developer implemented that new "feature". Normally, developers don't simply implement something without a need or without a benefit for the users. Was there a request from users to add the preview window? Is there any benefit for the users to see a preview of a calendar item?

(In reply to BernieStn from comment #51)

(In reply to karhima from comment #50)

I also just created an account for this after using TB for 15+ years, not much to add to the general sentiments, only that it's now inconsistent with other behaviour like opening a task - there double click opens the task and not just some extra summary window. Additionally this is widely used outside Thunderbird's Calendar and hence expected behaviour. Just imagine opening a .txt file and then getting a summary of what's inside.
In all honesty, I'm either rolling back to a previous version or switching to a different software if that stays and I'm not able to change it in settings like it has been suggested in comment 40.

Your comparison with a txt file made me smile. It's an excellent example where a preview also wouldn't help a user.
I would really like to understand why the developer implemented that new "feature". Normally, developers don't simply implement something without a need or without a benefit for the users. Was there a request from users to add the preview window? Is there any benefit for the users to see a preview of a calendar item?

(In reply to BernieStn from comment #51)

(In reply to karhima from comment #50)

I also just created an account for this after using TB for 15+ years, not much to add to the general sentiments, only that it's now inconsistent with other behaviour like opening a task - there double click opens the task and not just some extra summary window. Additionally this is widely used outside Thunderbird's Calendar and hence expected behaviour. Just imagine opening a .txt file and then getting a summary of what's inside.
In all honesty, I'm either rolling back to a previous version or switching to a different software if that stays and I'm not able to change it in settings like it has been suggested in comment 40.

Your comparion with a txt file made me simle. It's an excellent example where a previous also wouldn't help a user.
I would really like to understand why the developer implemented that new "feature". Normally, developers don't simply implement something without a need or without a benefit for the users. Was there a request from users to add the preview window? Is there any benefit for the users to see a preview of a calendar item?

The only benefit I see is the feature prevents a user from accidentally editing an event.

I just right-click on the event and use the Edit context menu item.

(In reply to WaltS48 [:walts48] from comment #53)

(In reply to BernieStn from comment #51)

(In reply to karhima from comment #50)

I also just created an account for this after using TB for 15+ years, not much to add to the general sentiments, only that it's now inconsistent with other behaviour like opening a task - there double click opens the task and not just some extra summary window. Additionally this is widely used outside Thunderbird's Calendar and hence expected behaviour. Just imagine opening a .txt file and then getting a summary of what's inside.
In all honesty, I'm either rolling back to a previous version or switching to a different software if that stays and I'm not able to change it in settings like it has been suggested in comment 40.

Your comparion with a txt file made me simle. It's an excellent example where a previous also wouldn't help a user.
I would really like to understand why the developer implemented that new "feature". Normally, developers don't simply implement something without a need or without a benefit for the users. Was there a request from users to add the preview window? Is there any benefit for the users to see a preview of a calendar item?

The only benefit I see is the feature prevents a user from accidentally editing an event.

I just right-click on the event and use the Edit context menu item.

You are right, right-clicking the event and using the "Edit" contect menu item is a possible option, but it's slow, because it requires multiple manual steps: 1) right-click the event 2) locate the "Edit" entry in the menu 3) move the mouse to the "Edit" entry 4) click it.
Double-clicking is much faster. If editing is something what I do once per week, this wouldn't be a problem. But I edit events daily, multiple times per day. In that case, it is frustrating to not be able to simply open the item for editing.
And regarding your statement "prevents a user from accidentally editing an event": I don't think this is a valid point. If someone accidentally opens an event for editing, he can still close the dialog before accidentally editing the event, of not save (=cancel) the acidentally made changes in the event.

(In reply to WaltS48 [:walts48] from comment #53)

I just right-click on the event and use the Edit context menu item.
For me, Edit on the context menu is greyed out. No idea why.

Can someone tell me which is the latest version that doesn't have view-not-edit-feature?

(In reply to WaltS48 [:walts48] from comment #53)

I just right-click on the event and use the Edit context menu item.

My last comment quoted the OP's post along with my comment. I can't figure out a way to edit or delete the comment so I am duplicating it. What I meant to say was:

For me, Edit on the context menu is greyed out. No idea why.

Can someone tell me which is the latest version that doesn't have view-not-edit-feature?

(In reply to BernieStn from comment #54)

(In reply to WaltS48 [:walts48] from comment #53)

(In reply to BernieStn from comment #51)

(In reply to karhima from comment #50)

The only benefit I see is the feature prevents a user from accidentally editing an event.

One if the major benefit is able to get a quick summary and quickly connect to an online meeting (Teams, Ziom,etc) when the event is an accepteted invite by joining meeting with a click on an active link. That was rekevant because Location and Description of event are a text field by protocol so when opening event via Edit you could not just click the invite meeting link directly. You had to select it, copy it and psdtevit in a web browser. Now that Description may become displayed soon as html where applicable that may become less relevant...bur may not apply yet to the Edit field.

I think having summary of event is not a bad thing but it should not be accessed via double click. A simple click shall suffice to select event (for drsg/drop) and show summary. Freeing double click for old previous behsviour: direct Edit

I just right-click on the event and use the Edit context menu item.

This is a nice addition as a quick work around to the current situation but cannot be considered as a final solution to this bug! not intuitive nor convenient for frequent edits. The alternative being click the Edit button in the preview... also not convenient for frequent edits.

You are right, right-clicking the event and using the "Edit" contect menu item is a possible option, but it's slow, because it requires multiple manual steps: 1) right-click the event 2) locate the "Edit" entry in the menu 3) move the mouse to the "Edit" entry 4) click it.
Double-clicking is much faster.

+1. Agreed.

And regarding your statement "prevents a user from accidentally editing an event": I don't think this is a valid point. If someone accidentally opens an event for editing, he can still close the dialog before accidentally editing the event, of not save (=cancel) the acidentally made changes in the event.

+1. Agreed.

I just want to point out that there is a Thunderbird UX mailing list where these decisions can be discussed instead of on bugzilla.
https://thunderbird.topicbox.com/groups/ux

When comments here get too deep into feedback and support it makes it difficult for developers to keep up with the actual issue (if any). Also titling the bug with "useless intermediate window" is a little provoking.

That said, I want to make a few points here:

  1. As comment 21 states, the implementation of this was not complete. There is more work to be done in this area but there were other priorities.
  2. Many parts of the calendar code base are tightly coupled and changes in one area tends to affect others. When this change was made, I don't think the today pane workflow was considered, at least not by me.
  3. Now that I have a better understanding of the Thunderbird codebase, I can safely say bugs like these are due to our disconnected UI experience. Something that should improve in time but making isolated changes without the bigger picture in mind will probably make things worse. Reverting changes before they are finished or hiding the old way behind a pref is also not the answer. That increases technical debt and in the case of the prefs, can make testing harder.

To me TB is not primarily a data entry tool and if there is a class of users that have to edit events frequently, then it suggests to me an area for enhancement. For example, the scenarios described in comment 5 are the kind of thing I want to follow up bug 1612170 with. Idea being TB is able to prompt you to make those edits automatically.

Hi Lasana, nice to see feedback from someone at Thunderbird; thanks for chiming in :)

(In reply to Lasana Murray from comment #58)

To me TB is not primarily a data entry tool and if there is a class of users that have to edit events frequently, then it suggests to me an area for enhancement. For example, the scenarios described in comment 5 are the kind of thing I want to follow up bug 1612170 with. Idea being TB is able to prompt you to make those edits automatically.

Yes, it has become clear that there are (in the context of this bug) two kinds of calendar users: those who view events a lot (e.g. in professional context where you want to peek at Zoom events multiple times a day to click a link), and those who edit events more. We who reject this change are users who edit more, and we reject the change because for us it adds more friction than benefits. See also comment 13 where I attempt to quantify the regression.

there is a Thunderbird UX mailing list where these decisions can be discussed instead of on bugzilla. https://thunderbird.topicbox.com/groups/ux

I, reporter of this bug, will not take time to bring this discussion to the mailing list. I think the case has already been made well enough here, and the amount of comments is proof that it's a sentiment shared by many users. Also, to me this is a bug (and a precise species of bug: a regression), so it makes sense for bug discussion to live in your bug tracking tool. Also, I'm unsure what the mailing list would add to Bugzilla; Bugzilla has everything we need to discuss this thing: text, replies and images, we good, no need to fragment across several tools. That being said, if any of the commenters are willing to discuss further on the mailing list, great.

Cheers, hope this gets improved.

Oh, one thing I forgot to comment on. Sorry for the double-post.

(In reply to Lasana Murray from comment #58)

Reverting changes before they are finished or hiding the old way behind a pref is also not the answer. That increases technical debt and in the case of the prefs, can make testing harder.

  • I understand your wish to avoid hiding the old way behind a pref, for maintainability and testability...
  • ... but why do you flat-out exclude reverting this change? Maybe it was a bad decision, and there's no shame or ego melt in "we made an mistake and are rolling it back", in many situations it is a good answer. Experiments are made, some succeed, some don't.

(In reply to C Haley from comment #56)

(In reply to WaltS48 [:walts48] from comment #53)

I just right-click on the event and use the Edit context menu item.

My last comment quoted the OP's post along with my comment. I can't figure out a way to edit or delete the comment so I am duplicating it. What I meant to say was:

For me, Edit on the context menu is greyed out. No idea why.

It would be disabled if the calendar is read-only.

If not a read-only calendar, I would also have no idea why.

(In reply to WaltS48 [:walts48] from comment #61)

(In reply to C Haley from comment #56)

For me, Edit on the context menu is greyed out. No idea why.

It would be disabled if the calendar is read-only.

If not a read-only calendar, I would also have no idea why.

It isn't read-only but it is a network calendar using "Provider for Google Calendar". I just checked: all my Google calendars have "Edit" in the context menu greyed out. My one local calendar does not.

(In reply to C Haley from comment #62)

(In reply to WaltS48 [:walts48] from comment #61)

(In reply to C Haley from comment #56)

For me, Edit on the context menu is greyed out. No idea why.

It would be disabled if the calendar is read-only.

If not a read-only calendar, I would also have no idea why.

It isn't read-only but it is a network calendar using "Provider for Google Calendar". I just checked: all my Google calendars have "Edit" in the context menu greyed out. My one local calendar does not.

Then, if the Edit button works, the issue is with the extension or another extension, and not related to this issue. Try Help > Troubleshoot Mode.

Hi Lasana,

(In reply to Lasana Murray from comment #58)

Thank you for your feedback but this issue has already been reported and discussed quite a lot already, this bug shall be sufficient :-)
It may be time for the dev team to just act upon it perhaps...

The change was clearly a conscious and deliberate decision from the dev team to the detriment of end-users that at very early stage of implementation (view improvement) warned about the side effect (edit deterioration) that could have been corrected since then (just this bug was opened 10 months ago!), well before they landed in the ESR, but it was not. Comment 21 arrived very late already in the process... and just mark the start of awareness/consideration from the dev team that improvement may be necessary, but then other priority took over.

Bug title and numerous comment here are largely sufficient to understand what the issue is! Comment 21 confirms the dev team understand it...
Before it was possible to directly edit an event by double click on it (Today Pane, Calendar views, etc...), now it is no longer possible. People want this feature back! A single click could allow selection and preview of the event instead.
So no need to completely revert back the changes, or implement new preferences, just improve the current design so preview via door-hanger does not prevent editing via double click... both should be technically possible, no?

View and Edit data shall have an equal foot print in TB, and both be intuitive and fast to do!

Again hearing "TB is not primarily a data entry tool" is really misunderstanding your user base and how they use the tool you develop... that may be your view and possibly the view form the dev team (thinking mobile experience) but that is clearly not the view of all your user base out there. Especially when using TB on a computer (desktop experience).
Numerous comments in this bug showed that a lot of people use it to edit calendar events multiple times a day, not just to view them! Those Comments here are just the tip of the iceberg :-)

Alessandro proposal in Comment 21 make sense but has still to be implemented yet for testing... and there were not much follow up from the dev team on the issue since then (yes I know other priorities :-). I don't think any recent announcement or beta or 95 version even start to cover any improvement in this area. Correct me if I am wrong...

We are kind of kept in the dark on what the plan and timetable foreseen to resolve this issue that started more than 10 months ago, which is really a daily real practical annoyance for any end-users editing events all day long! No brain muscle does not adjust :-) I wish you would understand it...

Resolution of such issue shall take priority over developing new feature (e.g the Spaces bar for example) because it is a real regression already out there, and pressure will only keep increasing to sort it out quickly as people start to be migrated automatically over to 91.x ESR soon...

But in the end it is the dev team call, they know best. The questions remain: Is the team really willing to make the necessary change to improve the situation? If yes, when?

The sooner the better, but your dev, your pace, just please would you keep us posted on the plan/progress...

Regards,

(In reply to Richard Leger from comment #64)

We are kind of kept in the dark on what the plan and timetable foreseen to resolve this issue that started more than 10 months ago, which is really a daily real practical annoyance for any end-users editing events all day long! No brain muscle does not adjust :-)

FWIW, this bug/regression is mentioned as a potential fix in the roadmap for the next release (v103 I think): https://developer.thunderbird.net/planning/roadmap#calendar

(In reply to YG from comment #65)

FWIW, this bug/regression is mentioned as a potential fix in the roadmap for the next release (v103 I think): https://developer.thunderbird.net/planning/roadmap#calendar

Thanks! The UX shown in the roadmap's screenshot looks great:

  • The old UI needed a double-click to edit, and annoyed heavy viewers.
  • The new regressed UI needs a double-click to edit to view, and annoys heavy editors.
  • The proposed UI gives viewers what they need on single-click (showing the doorhanger), then editors are one Edit button click away from editing.

Excellent stuff. Hope this lands soon.

(In reply to Ronan Jouchet from comment #66)

(In reply to YG from comment #65)

FWIW, this bug/regression is mentioned as a potential fix in the roadmap for the next release (v103 I think): https://developer.thunderbird.net/planning/roadmap#calendar

Thanks! The UX shown in the roadmap's screenshot looks great:

  • The old UI needed a double-click to edit, and annoyed heavy viewers.
  • The new regressed UI needs a double-click to edit to view, and annoys heavy editors.
  • The proposed UI gives viewers what they need on single-click (showing the doorhanger), then editors are one Edit button click away from editing.

Excellent stuff. Hope this lands soon.

Not meaning to be overly negative but how is this better than what we have today? The difference between a single click and a double click is minimal; the mouse is already where it needs to be. The original UI was move-the-mouse, double-click, then edit. The "regressed" UI is move-the-mouse, double-click to view, move the mouse, then single click to edit. The proposed UI is move-the-mouse, single-click to view, move the mouse, then single click to edit, which for me is the same as the regressed UI. In addition, the new UI might regress even further -- I might lose the ability to single-click to select then drag the event to a new day, something I do frequently.

Of course I am speculating. The plans may deal with my objections.

(In reply to C Haley from comment #67)

Not meaning to be overly negative but how is this better than what we have today? The difference between a single click and a double click is minimal; the mouse is already where it needs to be. The original UI was move-the-mouse, double-click, then edit. The "regressed" UI is move-the-mouse, double-click to view, move the mouse, then single click to edit. The proposed UI is move-the-mouse, single-click to view, move the mouse, then single click to edit, which for me is the same as the regressed UI. In addition, the new UI might regress even further -- I might lose the ability to single-click to select then drag the event to a new day, something I do frequently.

Of course I am speculating. The plans may deal with my objections.

100% agree with this.

Now I'm confused.

https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c67 writes: "The proposed UI is move-the-mouse, single-click to view, move the mouse, then single click to edit, which for me is the same as the regressed UI". But as I already described in https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c54, it is important to have a workflow which is as quick as possible. Not too many mouse movements, not too many mouse clicks. Therefore, double clicking the item should open the item for editing. https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c67 would require 4 manual steps: 1) move-the-mouse 2) single-click to view 3) move the mouse 4) then single click to edit. Double-click is much faster, especially when editing an item is a frequently used operation (multiple times per day).

I understood that was the solution as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c44 (Make single-click show the tool-tip like the new mockup shows. Make double-click open edit window). This is what other comments here also request (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c48: "double click should DEFINITELY bring up the event EDIT window" or the "+1 Agreed" in https://bugzilla.mozilla.org/show_bug.cgi?id=1685007#c57).

(In reply to C Haley from comment #67)

how is this better than what we have today? The difference between a single click and a double click is minimal; the mouse is already where it needs to be. The original UI was move-the-mouse, double-click, then edit. The "regressed" UI is move-the-mouse, double-click to view, move the mouse, then single click to edit. The proposed UI is move-the-mouse, single-click to view, move the mouse, then single click to edit, which for me is the same as the regressed UI.

The difference is that the mockup UI doesn't go through a jarring intermediate window that might display anywhere on your screen. It uses a "doorhanger" that 1. only needs a single click, and 2. always opens conveniently near where your cursor is. So, the mockup is:

  1. Not as good for me (part of the "heavy event editors" group) as the old UI, since {dblclick} is easier than {click + slight move + click}...
  2. ... but yes it is clearly better than the regressed UI, and I feel {click + slight move + click} is reasonable ...
  3. ... and of course it is better than both the old and regressed UI for "heavy event viewers", since "viewing" is fast and only needs a single click.

TL;DR: IMHO a good UX trade-off satisfying needs of both groups, at the tiny cost of a bit of extra mouse movement for "heavy editors". Personally, I'm happy with this trade-off.

... but yes it is clearly better than the regressed UI, and I feel {click + slight move + click} is reasonable ...

I personally would like to restore the double click to edit after the doorhanger is implemented.
So, 1 click to open the overview (doorhanger), and 2 clicks to edit. Since the doorhanger in most cases will not open above the clicked event, even an accidental single click won't necessarily force the user to move the mouse on top of the edit button.

This seems to be a solution that isn't 100% what both types of users would prefer. Why not give me the option in settings to choose which version I'd like?

(In reply to Ronan Jouchet from comment #70)

(In reply to C Haley from comment #67)
TL;DR: IMHO a good UX trade-off satisfying needs of both groups, at the tiny cost of a bit of extra mouse movement for "heavy editors". Personally, I'm happy with this trade-off.

I am of an age where my eye-hand coordination is failing. I often 'miss' by a bit when moving the mouse. Usually I notice and correct but sometimes I click, invoking behavior I don't want. For example, 3 or 4 times per week I sort the message list by some column instead of selecting the top message. For me any "extra mouse movement" is more than a tiny cost. If I am already there then another click or even a non-mouse-hand key press is preferable. I currently use Alt-E to edit instead of moving the mouse again. It would be easier if F2 worked to edit a selected event. And easiest if double-click edited the event.

(In reply to Alessandro Castellani [:aleca] from comment #71)

I personally would like to restore the double click to edit after the doorhanger is implemented.
So, 1 click to open the overview (doorhanger), and 2 clicks to edit.

Worthwhile proposal, should try this!

Please remember that Ctrl+single-click can also be used to select multiple events (not sure why Shift isn't implemented, maybe ux-error-prevention). So we also need to examine how the single-click doorhanger interacts with Ctrl+single-click selection. Maybe it's just fine, or we could suppress the doorhanger when Ctrl modifier is used to select events.

Since the doorhanger in most cases will not open above the clicked event...

I hope the doorhanger will have some inbuilt flexibility to open to the appropriate side of the event where there's sufficient space to show it, and we should carefully test all edge cases (event at far-right, far-left, very top, very bottom, center-screen, small window, today pane etc.). Ideally, it should never cover the clicked event.

Current status of this ticket - read this before commenting

  • Known usability issue for certain users - different users have different needs!
  • Workaround: press Enter on event summary dialog
  • TB devs will iterate on this in due time, preferred solution identified.
  • Kindly refrain from me too comments, use Vote button in details section on top instead.
  • Otherwise pls keep solution-focused comments to a minimum.

I would like to thank everyone on this bug for their valuable input of describing their real-life workflows and exploring improvements over the status quo, which is appreciated! Thank you for discussing this usability issue with Thunderbird developers in search of better solutions.

I believe by now the developer team including Alex [:aleca], our UX lead, has a pretty good understanding of this usability issue and the possibilities of addressing it (see Alex' comments on this bug). I suggest that we should refrain from adding more comments, especially me toocomments, for which you should use the Vote button in the Details section on top of this bug instead. Too many comments will make this bug harder to act on, which is counter-productive. If you feel that you still have important information to add for solving this issue, please keep it as short as possible (using bullet points often helps with that).

In TB 78, double-click on an event used to open the Edit Event dialog directly.
For TB 91, Bug 1575195 and bug 1673654 implemented a change to better support viewing an event without the bells and whistles of editing, and decided to attach the new event summary dialog to the double-click, hence effectively overriding the previous double-click-edit behaviour.
It's important to note the difference between:

  • the new event summary dialog itself (as new UI)
  • vs. how to hook that up in the UI (currently via double-click)

The new event summary dialog will be useful for many users for checking their events out and clicking on links in the invitation, which is much harder in edit mode. Also, for certain types of invites and repeated events, the intermediate event summary window is useful or required (see Ben's Comment 32). However, there's ample evidence on this bug that for a notable number of users, overriding the existing double-click-edit behaviour is annoying because in their workflows, editing occurs more frequently than viewing, so it forces them into an extra step for each edit (plus editing sort of includes viewing). I would like to apologize to the users affected by this inconvenience. It's a usability issue, meaning the current design is inconvenient, but not broken.

Btw, as a workaround, after double-clicking the event, you can just press Enter in the event summary dialog, which will take you to the Edit event dialog (for editable events).

So clearly, this looks like a case of "different users have different needs", and imho, taking this into account is key for the reception and success of Thunderbird. That said, accommodating different needs is often non-trivial and it typically comes at a cost in code, resources for implementation, and support.

The currently favored solution is:

  • Single-click on event to show a doorhanger event summary panel with an Edit button (without affecting Ctrl+click to select multiple events).
  • Double-click on event to show Edit Event dialog/tab directly (as in TB 78).

A possible alternative solution might be:

  • Implement a preference with UI to choose the default action (Open event summary vs. Edit event) when double-clicking on an event.
    While this might look like an easy fix, it probably isn't, and we do try to avoid adding prefs if we can. Perhaps if someone wants to pursue this, it should be filed as a new bug which focuses on exploring the feasibility of that particular solution.

I can't comment much on the time frame, but unfortunately, the currently favored solution (due to new UI, strings etc.) could only land for the next release, TB 103. Also, there's a lot on everyone's plate, so we can't work on everything at the same time. I hope that the workaround may somewhat alleviate the usability pain in the mean time. Thank you for your patience, and again, thank you for your input!

Severity: -- → S3
Type: defect → enhancement
Depends on: 1575195, 1673654
Keywords: ux-efficiency
Priority: -- → P2
See Also: → 1700110
Summary: Double-clicking an event in the Today Pane goes through a useless intermediate window rather than opening the "Edit Event" screen/tab → Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly
Whiteboard: [read comment 75 before commenting]

Per comment 14 ff, screencasts of attachment 9197621 [details] ff, the current implementation (double-click-open) is also inconsistent with other calendar implementations out there (Google, Yahoo, Evolution), which makes this a case of external ux-consistency.

Keywords: ux-consistency

As per your "voting" section at the top, it is unclear of what each vote option is for.

But in the midst of the arguments listed above, I still don't see how reverting back to an Edit mode is going to be at all useful in my case.

  • The overwhelming majority of the calendar entries in my usage is team meetings, which I don't even have the ability to edit anyway. In an edit-default mode, when I need to look at the details, then close the window, it then prompts me to save, cancel, etc. This is an interruption in my workflow just as having to click "Edit" is for yours. Many others are notices for company conferences, trade show information, etc.

  • Even when I am scheduling a meeting myself, it's generally being done through Google Meet, so as far as Thunderbird is concerned it would be a read-only event as well.

  • Often the descriptions in the meeting events I'm getting are long entries (considering how Google Meet, WebEx, etc format their meeting notices). I could easily need 30 lines of text just to get to the URL/link that lets me connect to the meeting. I don't see that the popup notices are going to give me anywhere enough lines of text to make it usable.

  • Even for the popups that had been in TB previously, there was no way to scroll the text, which would be necessary to make it usable.

An edit-only option, with miniscule popups like had been done in the past, would make Thunderbird/Lightning unusable for my purposes.

Perhaps the solution here should be a modifier, like is done with delete. So Ctrl+ double click opens the edit window. Double click opens the summary and perhaps a pref to toggle the two, so everyone is happy with "their" solution.

It is very annoying that since V 91.0 the click on an existing calendar item opens only an information pop-up. I mostly need to EDIT an item when I click on it. This is now 2 clicks instead of 1 click as it was before.
Most reasons for me is my wish to edit when I click on a calendar item.
regular use cases are:

  1. somebody changed the time of the event
  2. additional information need to be added to an event (such as topics, such as URL for a video meeting which usually are sent out after the svae-the-date was sent out)
  3. I take notes of or for the event

please offer a quick edit-option for editing calendar events!!!!

This is so annoying for me that i took the effort to even create my bugzilla account!
Thank you developers!

Same for me. It is very annoying that since V 91.0 the click on an existing calendar item opens only an information pop-up. I mostly need to EDIT an item when I click on it. This is now 2 clicks instead of 1 click as it was before.
I want the old behavior (double click opens edit window) back.

The new behaviour is so annoying for me that i took the effort to even create my bugzilla account!
Thank you developers!

It's really a matter of your use case. For my work account, I'm almost never going to be creating/editing calendar entries in Thunderbird. The vast majority of calendar entries on mine will be meetings/talks & the like, most of which are created in Google Calendar/Google Meet (and TBird can't edit those even if they were my own entries). But being created in the Googleverse means they're going to be wordy and long, and the usual popup in Thunderbird will barely get past the title/header.

So this has to be readily and clearly configurable (which means not burying it somewhere down in the 'about:config' settings).

(In reply to James E. LaBarre from comment #83)

are created in Google Calendar/Google Meet (and TBird can't edit those even if they were my own entries). But being created in the Googleverse means they're going to be wordy and long, and the usual popup in Thunderbird will barely get past the title/header.

You seem to generalise too much. TB ≤ 78 was able to edit Google calendar with an addon and from TB 91 directly, your own or the shared ones.
Also, there is no need for them to be long, it’s just your use case, not necessarily everyone’s.

This use case shows how ridiculous this new “Edit” by default is:

In the calendar daily view, add an event stub by clicking and dragging between the starting hour and the end hour.
Once the hours are set, you double click on this stub to open it and add all the necessary information.
By default, now Thunderbird won’t let you directly edit it, unless you click on an additional Modify button. TB created an event that contains no data but two hours. It’s obvious that you need to edit it rather than view when there is nothing extra to view.

(In reply to maison from comment #85)

This use case shows how ridiculous this new “Edit” by default is:

In the calendar daily view, add an event stub by clicking and dragging between the starting hour and the end hour.
Once the hours are set, you double click on this stub to open it and add all the necessary information.
By default, now Thunderbird won’t let you directly edit it, unless you click on an additional Modify button. TB created an event that contains no data but two hours. It’s obvious that you need to edit it rather than view when there is nothing extra to view.

Actually the user can type the Event title into that empty block, giving it some data.

The date and time is also data in that so-called empty event.

(In reply to WaltS48 [:walts48] from comment #86)

(In reply to maison from comment #85)

This use case shows how ridiculous this new “Edit” by default is:

In the calendar daily view, add an event stub by clicking and dragging between the starting hour and the end hour.
Once the hours are set, you double click on this stub to open it and add all the necessary information.
By default, now Thunderbird won’t let you directly edit it, unless you click on an additional Modify button. TB created an event that contains no data but two hours. It’s obvious that you need to edit it rather than view when there is nothing extra to view.

Actually the user can type the Event title into that empty block, giving it some data.

The date and time is also data in that so-called empty event.

Sure, you can hurry to add the title (and only that), but it doesn’t change the fact that TB 91 allows the user to view an empty calendar event rather than edit it, which interrupts the workflow.

Actually, it's not MY choice for the GCal events to be long, it's how they are by default at work. And as I have REPEATEDLY said, the overwhelming percentage of calendar entries I have are NOT mine, therefore I cannot edit them, nor would I want to. So having the calendar entries coming up in Edit mode is an interruption to MY workflow, especially since Lightning insists that merely looking at a calendar entry is equivalent to editing it, and then tells me I haven't saved my changes (even though I haven't done any edits). I haven't seen this behavior of Looking==Editing since MSWin95.

Reverting the calendar to "Opening==Editing" would therefore make Lightning unusable for my purposes.

(In reply to James E. LaBarre from comment #88)

especially since Lightning insists that merely looking at a calendar entry is equivalent to editing it, and then tells me I haven't saved my changes (even though I haven't done any edits).

Maybe this is a bug and you should report it elsewhere with all the details. In my opinion, it’s not the object of this bug report.

I haven't seen this behavior of Looking==Editing since MSWin95.
Reverting the calendar to "Opening==Editing" would therefore make Lightning unusable for my purposes.

FYI, the edit mode on calendar has been the default on Microsoft Outlook and on Android, including the latest versions.
I’ve never seen a calendar manager that makes you take extra steps to edit what is in YOUR agenda.

As a matter of fact, people who want the old behaviour just say that the extra Edit button is a useless annoyance, although usable; but in your case you say that without the Edit button you won’t use it any more! Your statements are still so dichotomous.

Since you are so vehement about the Edit mode making your calendar usage impossible, did you only start using TB recently from version 91? Otherwise please let us know how you used it for years in versions ≤ 78.

Actually, yes, the prior versions of the calendar were unusable because of the Edit mode. I had found the newer versions with the read-mode calendar view made it possible to start using Lightning rather than having to keep a browser tab open to the web-view of the calendar; preferably using Firefox, as if I had the calendar open in Google Chrome (either regular browser window or a PWA view) it would open any links in Chrome as well (and I avoid using Chrome if at all possible).

Granted, there were some other bugs in Lightning that had also been a problem, such as it bringing up all the prior/past meetings of a repeating event in the notification window, which couldn't be dismissed in bulk.

For me, the new intermediate window is rather annoying.

It's just more complicated now. In the old edit window I had all data of the calendar entry. Further, there's the mouseover.

For me, there's simply no extra value of the intermediate window - and to have to click a second time to enter the edit mode. In most cases I "open" a calendar entry, I want to edit it.

Just today, I had to adjust the time of about 30 calendar entries (no serial, but individual entries). And the intermediate window annoyed me every time...

(In reply to Patkul from comment #91)

For me, the new intermediate window is rather annoying.

It's just more complicated now. In the old edit window I had all data of the calendar entry. Further, there's the mouseover.

For me, there's simply no extra value of the intermediate window - and to have to click a second time to enter the edit mode. In most cases I "open" a calendar entry, I want to edit it.

Just today, I had to adjust the time of about 30 calendar entries (no serial, but individual entries). And the intermediate window annoyed me every time...

Then bypass it by right-clicking on the event and use the Edit context menu item.

Please read comment 75 before commenting

May I remind everyone that there's no need to defend your use case - both use cases are legitimate and well understood, and we'll try to implement a balanced solution. Let's keep comments to a minimum please.

User Story: (updated)
Summary: Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly → Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly (read comment 75 before commenting)
Summary: Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly (read comment 75 before commenting) → Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly (pls read comment 75 before commenting)

(In reply to James E. LaBarre from comment #88)

Actually, it's not MY choice for the GCal events to be long, it's how they are by default at work.

It’s hard to believe that one can accommodate to read long calendar descriptions in such a small visualisation window. To make things worse, even if you make the window bigger, the new size is not remembered and the next event will still be shown in a wee window.

(In reply to WaltS48 [:walts48] from comment #86)

(In reply to maison from comment #85)

This use case shows how ridiculous this new “Edit” by default is:

In the calendar daily view, add an event stub by clicking and dragging between the starting hour and the end hour.
Once the hours are set, you double click on this stub to open it and add all the necessary information.
By default, now Thunderbird won’t let you directly edit it, unless you click on an additional Modify button. TB created an event that contains no data but two hours. It’s obvious that you need to edit it rather than view when there is nothing extra to view.

Actually the user can type the Event title into that empty block, giving it some data.

Well, that’s also a problem, because you can only type. I copy a lot of my events from public information on the Internet. Therefore I can’t drag my text as an event title and anyway the little text box loses its focus forever if you attempt to do anything between the creation and typing.

To modify it yourself:

  1. extract omni.ja in thunderbird directory with any zip extractor
  2. edit chrome\calendar\content\calendar-views-utils.js
  3. change openEventDialogForViewing(occurrence); in viewOccurrence (line 53 in TB 91.3.1) to modifyEventWithDialog(occurrence, true);
  4. repack the files as zip with compression = store and replace the previous omni.ja

On the workaround suggestion of hitting Enter to edit the event, I'd like to add:
This works fine for simple events for me, but when I have repeating appointments, I'd like to be able to be able to choose whether to edit the current instance or the series of the event. When I hit Enter the window just closes.

(In reply to peacech from comment #96)

To modify it yourself:
3. change openEventDialogForViewing(occurrence); in viewOccurrence (line 53 in TB 91.3.1) to modifyEventWithDialog(occurrence, true);

This worked with 91.3.1, but seems to no longer work with 91.3.2.

(In reply to Robert Dahlem from comment #98)

(In reply to peacech from comment #96)

To modify it yourself:
3. change openEventDialogForViewing(occurrence); in viewOccurrence (line 53 in TB 91.3.1) to modifyEventWithDialog(occurrence, true);

This worked with 91.3.1, but seems to no longer work with 91.3.2.

You could also try replacing this.calendarView.controller.viewOccurrence(item); in chrome\calendar\content\calendar-editable-item.js with this.calendarView.controller.modifyOccurrence(item);.

Source: https://hg.mozilla.org/comm-central/file/tip/calendar/base/content/calendar-editable-item.js#l89

(In reply to Robert Dahlem from comment #98)

(In reply to peacech from comment #96)

To modify it yourself:
3. change openEventDialogForViewing(occurrence); in viewOccurrence (line 53 in TB 91.3.1) to modifyEventWithDialog(occurrence, true);

This worked with 91.3.1, but seems to no longer work with 91.3.2.

Just to make sure, when you upgraded to 91.3.2, did you re-modify the omni.js?

(In reply to peacech from comment #99)

You could also try replacing this.calendarView.controller.viewOccurrence(item); in chrome\calendar\content\calendar-editable-item.js with this.calendarView.controller.modifyOccurrence(item);.

That worked with 91.3.2, thank you!

And yes, I did re-modify omni.ja (not omni.js).

THANK YOU so much, @peacech !!!! Not been able to modify this behaviour was really annoying for my case of use of the calendar, on an intense daily basis...

(In reply to Martin Schröder [:mschroeder] from comment #1)

Ronan, this was implemented as a new feature in bug 1673654.

Unfortunately this new feature is not being well received in Support Forum as it is totally unecessary.
Whether you see the 'General' info or the Edit version of info, is completely irrelevant - you still see info.
Hover over also displays info - so quite often the reason for quick access- double clicking to open is to Edit.

Seeing information as it currently exists is not a problem and does not need fixing or modifying.
The 'new feature' means if you want to Edit then there are additional hoops. which are inconvenient and waste time causing frustration.

Fortunately, a right click and select 'Edit' gets around the problem, but this only works in the 'Home' default calendar. It does not work in eg: Google calendar because Edit is greyed out.

To make things worse, even if you make the window bigger, the new size is not remembered and the next event will still be shown in a wee window.

This is also being reported as a serious headache, but if that 'General' window was just completely removed then that problem is mute.

re: re-modify omni.ja - The workaround suggested is handy, but not something an average user is capable of performing.

The current implementation is not great in terms of usability and doesn't server our users right.
I'll take this and lay down a strategy to fix and improve this area.

Assignee: nobody → alessandro

I also find the current state of things annoying and miss the previous, simpler use (that was also conforming with other clients). I tried to get used to it for months (or hoped that it would be fixed), but it keeps being a major nuisance. Eventually it caused me to create an account just for adding another vote for changing it back.

I tried to apply the modifications mentioned above, but unfortunately that had no effect. Might not apply to 91.5 anymore - or is there another step required so it uses the modified omni.ja?

Hi guys,
I also find the editing of single events more difficult this way, and wish I could just click one time and edit the event.
It happens often that I create an event, and need to move the date, time or add a category.
please go back to the easy editing!
thanks
nils

No. If anything it should be a selectable option. In MY use case I an not editing the caslendar entries, and having it constantly think it's editing a calendar entry (ESPECIALLY) ones I don't even have the ability to edit is a hinderance on MY workflow.

Forcing a one-click-and-edit as the ONLY setting makes Lightning too much trouble to continue using. At which point I would want to see it as an UNinstallable option, because there would be no sense in having it there when it's unusable.

As it is, if I have to try clicking on "dismiss" or "sleep" a few times on a non-editable entry, it STILL thinks I'm trying to edit it and asks if I want to overwrite it. When I didn't change anything on it.

(In reply to James E. LaBarre from comment #107)

No. If anything it should be a selectable option. In MY use case I an not editing the caslendar entries, and having it constantly think it's editing a calendar entry (ESPECIALLY) ones I don't even have the ability to edit is a hinderance on MY workflow.

James, I don’t understand why you are so vehement that you have to state your case again every other comment. What most people are asking here is basically that TB reverts to the old behaviour that worked for years where you can read or edit at the same time if you want. You don’t type anything and that means Read. But you are free to type directly if you want and that means Edit. Just don’t type and you will be satisfied.

If I double click a Task, I get to edit it. If I double-click an Event I just get to see, in a separate dialog, what I saw when the cursor momentarily hovered over the event. Is this consistency in interface design? Not in any of the ergonomics or Human–computer interaction design material I've worked through. Can we start to take account of the science of interaction and not go down routes defined by someone's off-the-cuff whim.

  • Old Guit

I do not recall anyone complaining that double click always opened the Edit mode - after all whether just viewing info or editing that 'Edit' screen offers both requirements.

I do not recall people asking to implement a double action passing through two separate windows in order to Edit - that would be impracticable - yet the new design chooses to go down that route.

Do I understand from the comments that the new design was created by people who do not use the 'Edit' functionality very often?

Since the update, workflow is impacted, people are complaining in Support Forum. The modification has not added anything useful nor an improvement to the design. It is just a change and it's only impact would be perceived negatively because it adversely effects workflow.

I feel that user input on how this particular change impacts workflow and expectation is valuable and needds to be taken very seriously.

It is irrelevant if user does not edit many events as the original design and new design have no impact.
The important effect is for those who do edit for many reasons and for those users, who use the edit functionality, the new design has a bad impact.

So the question is, why design something which only adversely effects those who need to edit?

The fact that there is a negative impact means this needs to be reviewed and the original design be used again.
There was nothing wrong with trying something out after all most people do not like change even when it is a good improvement. However, that does not apply in this case.

Can we please move forward and realise that the original design was a preferable solution as it provided equally for all users and offer information on when this can be updated to next release ?

(In reply to Anje from comment #110)

I do not recall anyone complaining that double click always opened the Edit mode - after all whether just viewing info or editing that 'Edit' screen offers both requirements.

Then you haven't read through everything, because I have complained about it NUMEROUS times

I do not recall people asking to implement a double action passing through two separate windows in order to Edit - that would be impracticable - yet the new design chooses to go down that route.

The PROPER solution would be to make it a configurable option, whether double-click goes to Edit or Detail View.

Do I understand from the comments that the new design was created by people who do not use the 'Edit' functionality very often?

The problem is whether the vast majority of entries on your calendar are created by you, or are from team calendars, groups you are a member of, or are otherwise non-editable by you.

Since the update, workflow is impacted, people are complaining in Support Forum. The modification has not added anything useful nor an improvement to the design. It is just a change and it's only impact would be perceived negatively because it adversely effects workflow.

Having the calendar decide it wants to try and edit non-editable entries, interferes with MY workflow. In fact, the calendaring can getr so confused that telling the notification to sleep or dismiss the notice will make the application ask if I want to save an edit. For something I never edited it the first place! And even for entries you created and can edit you may not always want to edit them, but rather just look at the details.

It is irrelevant if user does not edit many events as the original design and new design have no impact.

If I have to keep dealing with unwanted/unneeded popups, especially since they often show up behind other windows on a different monitor, that's a serious nuisance

The important effect is for those who do edit for many reasons and for those users, who use the edit functionality, the new design has a bad impact.
So the question is, why design something which only adversely effects those who need to edit?

Because there are a LOT of people who for the vast majority of the time are NOT editing every single time they open a calendar entry. The problem with the calendaring is that you can't see the details of a calendar entry that takes up more than two lines. If you need to see details such as a meeting link or call information, the entry on the calendar page itself tells you little more than time and date. The popup likely doesn't show enough details, the popup is non-scrollable, and you cannot select text on the popup because it will immediately go away when you move your cursor.

The fact that there is a negative impact means this needs to be reviewed and the original design be used again.

If we are talking about returning to an "original design", then the logical choice is to REMOVE Lightning as a built-in component, and return it to it's original state as an OPTIONAL extension. That way people who find it unusable as it exists can avoid having it in the application, and that opens the possibility of alternatives that fit our own particular usecases.

(In reply to James E. LaBarre from comment #111)

I do not recall people asking to implement a double action passing through two separate windows in order to Edit - that would be impracticable - yet the new design chooses to go down that route.

The PROPER solution would be to make it a configurable option, whether double-click goes to Edit or Detail View.

If it is really necessary, then this would be the right solution. But I have to agree with the previous speakers: the edit option also offers a view option. So why drag along two options, two Dialogues, two more sources of error?

Do I understand from the comments that the new design was created by people who do not use the 'Edit' functionality very often?

The problem is whether the vast majority of entries on your calendar are created by you, or are from team calendars, groups you are a member of, or are otherwise non-editable by you.

And this is an argument for implementing a more complicated workflow? I don't understand that.
The way I see it, if I want to see more details of my appointment, I click on it twice. Then I have both options: View and Edit. If I haven't edited anything, I leave the appointment again with Cancel or ESC.

Since the update, workflow is impacted, people are complaining in Support Forum. The modification has not added anything useful nor an improvement to the design. It is just a change and it's only impact would be perceived negatively because it adversely effects workflow.

Having the calendar decide it wants to try and edit non-editable entries, interferes with MY workflow. In fact, the calendaring can getr so confused that telling the notification to sleep or dismiss the notice will make the application ask if I want to save an edit. For something I never edited it the first place! And even for entries you created and can edit you may not always want to edit them, but rather just look at the details.

Why should the calendar decide this? What is stored in the calendar is that the calendar is not writable. This means, for example, that the display of the appointments can be adjusted. For example, with greyed-out dialogue windows. This makes the whole situation even more intuitive.

It is irrelevant if user does not edit many events as the original design and new design have no impact.

If I have to keep dealing with unwanted/unneeded popups, especially since they often show up behind other windows on a different monitor, that's a serious nuisance

The important effect is for those who do edit for many reasons and for those users, who use the edit functionality, the new design has a bad impact.
So the question is, why design something which only adversely effects those who need to edit?

Because there are a LOT of people who for the vast majority of the time are NOT editing every single time they open a calendar entry. The problem with the calendaring is that you can't see the details of a calendar entry that takes up more than two lines. If you need to see details such as a meeting link or call information, the entry on the calendar page itself tells you little more than time and date. The popup likely doesn't show enough details, the popup is non-scrollable, and you cannot select text on the popup because it will immediately go away when you move your cursor.

Yes, but these people are also confused about a different display in view mode. This looks completely different from the edit mode. So you have to look for the fields in other places.

The fact that there is a negative impact means this needs to be reviewed and the original design be used again.

If we are talking about returning to an "original design", then the logical choice is to REMOVE Lightning as a built-in component, and return it to it's original state as an OPTIONAL extension. That way people who find it unusable as it exists can avoid having it in the application, and that opens the possibility of alternatives that fit our own particular usecases.

That is absolute nonsense. The old design was also implemented in Thunderbird. It was only a logical step to integrate Lightning and Thunderbird so that you have everything in one application.

(In reply to James E. LaBarre from comment #111)

(In reply to Anje from comment #110)
Because there are a LOT of people who for the vast majority of the time are NOT editing every single time they open a calendar entry.

I personally do not know how many people want to double click only view details or how many double click expecting to edit.
I had no idea this sort of data was available. But I do k now that people do not expect the generic methodology to be messed up for just the Events.

I'm wanting to draw attention to the generic methodology used in Thunderbird and how this bug points out why the changes have the wrong expectation and do not conform to the generic use of double click.

Examples:
If you double click a Task it opens Edit.
If you right click on Task and select 'Open' it opens Task window to allow edit.
In the same way if you double click on a draft or template email, it opens to Edit the 'Write' window contents.
Double click on a contact in Address Book and it opens the 'Edit contact' window.
In Message Filters - double click on a filter and it open the 'Filter Rules' window allowing Edit.

So you would expect...
The 'Event' double click should use the same method - opens Edit.
The right click and select 'Open' should open the 'Edit Event' window.

Instead:
Double click is just a view.
Right click offers 'Open' but is just a view of Event details. However, I would have expected 'Open' to offer the 'Edit' because it is opening the event window and a 'View' option (which is missing) to offer viewing details - so that right click menu is confusing as well.
The Right click should offer 'View' to view details and allow 'Open' to do the same as others - open to edit.

See Also: → 1768137
Summary: Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly (pls read comment 75 before commenting) → Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly - implement pref (pls read comment 75 before commenting)

(In reply to s.grossberndt from comment #116)

  • on Thunderbird 91.10.0 neither the code changes from comment 95 nor comment 99 work to re-enable the old behaviour.

I just updated to 91.10.0 and the change in comment 99 still works.

Alternative way without editing omni.js using autoconfig:

Create these two files in the TB installation directory:

Note: disabling sandbox in autoconfig is a security risk, make sure you understand the risk. Also the override code is done in a crude way. It works though.

default/prefs/autoconfig-prefs.js

pref('general.config.filename', 'autoconfig.js');
pref('general.config.obscure_value', 0);
pref('general.config.sandbox_enabled', false);

autoconfig.js

// IMPORTANT: Start your code on the 2nd line
{
  const Cc = Components.classes;
  const Ci = Components.interfaces;
  let wm = Cc['@mozilla.org/appshell/window-mediator;1'].getService(Ci.nsIWindowMediator);
  let timer = Cc['@mozilla.org/timer;1'].createInstance(Ci.nsITimer);

  timer.initWithCallback(
    {
      notify: function () {
        for (const win of wm.getEnumerator('mail:3pane')) {
          win.calendarViewController.viewOccurrence = win.calendarViewController.modifyOccurrence;
        }
      },
    },
    5000,
    Ci.nsITimer.TYPE_ONE_SHOT
  );
}
Attached file autoconfig.zip —

Autoconfig scripts.

(In reply to differix5 from comment #123)

Me, too. With every TB update, with every comment posted, I am full of hope that, finally, a choice to bring back old and new behavior would be offered - to saisfy diverse users' needs.
I am not a techie, I cannot do work-arounds, do not understand autoconfig handling etc.
Please , friends, do offer us a chance for allowing direct change of an event when clicking an event.
Would be sooo appreciated!

It's easy to do. No need to be a specialist.

  1. Download the .zip-file (from comment #122 above your last post): https://bugzilla.mozilla.org/attachment.cgi?id=9279794
  2. Make sure Thunderbird is closed
  3. Open .zip-file and copy (drag-and-drop) content to your thunderbird folder ( usually C:\Program Files\Mozilla Thunderbird\ )
  4. Be happy and enjoy event editing on double-click 🤓

Another idea:

  1. install tbkeys-lite addon from https://addons.thunderbird.net/en-US/thunderbird/addon/tbkeys-lite/

  2. open the addon options page, set the Main key bindings to

{
    "j": "cmd:cmd_nextMsg",
    "k": "cmd:cmd_previousMsg",
    "o": "cmd:cmd_openMessage",
    "f": "cmd:cmd_forward",
    "#": "cmd:cmd_delete",
    "r": "cmd:cmd_reply",
    "a": "cmd:cmd_replyall",
    "x": "cmd:cmd_archive",
    "c": "func:MsgNewMessage",
    "u": "tbkeys:closeMessageAndRefresh",
    "e": "cmd:calendar_modify_event_command"
}

  1. Select any event and press e to open the edit dialog. You can change the e shortcut to any (unused) key. See the key format here https://craig.is/killing/mice. For example to use Alt+e replace "e" with "alt+e". To use space to open the edit dialog replace "e" with "space".

  2. You can add other shortcuts to your preference, for example to add new event by pressing n

{
    "j": "cmd:cmd_nextMsg",
    "k": "cmd:cmd_previousMsg",
    "o": "cmd:cmd_openMessage",
    "f": "cmd:cmd_forward",
    "#": "cmd:cmd_delete",
    "r": "cmd:cmd_reply",
    "a": "cmd:cmd_replyall",
    "x": "cmd:cmd_archive",
    "c": "func:MsgNewMessage",
    "u": "tbkeys:closeMessageAndRefresh",
    "e": "cmd:calendar_modify_event_command",
    "n": "cmd:calendar_new_event_command"
}

List of commands you can set for the calendar view, see here:
https://github.com/mozilla/releases-comm-central/blob/master/calendar/base/content/calendar-command-controller.js#L30

On Windows you can use autohotkey to bind Middle click or XButton1/XButton2 to the shortcut key so can open the edit dialog with a single click.

Before my comment gets flagged as “Comment hidden (abuse)” like Barnoid’s and account disabled or whatever (in spite of having contributed to several bugs), I hope at least that developers and forum moderators understand the difference between bugs — which are annoying — and bug reporters, which are constructive people that take time to create an account, go through the bugs or create another duplicate and try to contribute in their way.

I find myself more and more dragged to following bugs that shouldn’t have been there if user voices and more thorough testing had been done first.

It’s just that people are tired of waiting 2 or even 13 years(!) and debating endlessly about a bug with hundreds of comments.

User Story: (updated)
Keywords: pm-triage-needed

Comments such as other products and rants about developers are not constructive, and far afield of the purpose of this bugzilla report - the purpose here (as everything in bugzilla) is specificially how to fix this bug. Therefore comments are now restricted.

Restrict Comments: true

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

I don't understand why you would constantly be editing the events. Once you add it, personal or professional, it's usually "done".

Example :
I have a lot of Events all relating to F1 (Formula 1) dates. All the various Practise (3), Qualifying and Race. That's five per F1 location x number of races in a season - this year there are 23.
Each year I edit all of them as event name and location is identical but date/time will be different.

The generic methodology in Thunderbird is a double click - as used in eg: Tasks but there is a long list.
It is out of character and practise in Thunderbird to not offer a double click to edit an event.

There are lots of comments from people with genuine grievances who find this location via the the Support Forum information, so this location is seen as the place to voice their objections directly to developers - other than just a load of TB users. They may not be contributing to a solution but they are contributing to what the solution should offer. This is still good information, so developers know/understand what users expect.

Fixing this for 102 uplift with the current solution:

  • Add a boolean pref called calendar.events.defaultEditDialog.
  • If the pref is true, double clicking on the event should open the edit dialog (accounting for repeated events which should open the "edit only this or all event" choice.
  • If the pres if false, show the intermediate "view" dialog like we have right now.

No new strings added for this and the pref will only be editable in the about:config for 102, so we can have a quick uplift.

Lasana, can you take care of this as top most priority?

Assignee: alessandro → lasana
status-thunderbird_esr102: --- → affected
tracking-thunderbird_esr102: --- → ?
Flags: needinfo?(lasana)
Priority: P2 → P1

(In reply to Alessandro Castellani [:aleca] from comment #136)

Fixing this for 102 uplift with the current solution:

  • Add a boolean pref called calendar.events.defaultEditDialog.
  • If the pref is true, double clicking on the event should open the edit dialog (accounting for repeated events which should open the "edit only this or all event" choice.
  • If the pres if false, show the intermediate "view" dialog like we have right now.

No new strings added for this and the pref will only be editable in the about:config for 102, so we can have a quick uplift.

Lasana, can you take care of this as top most priority?

If I recall correctly there was hesitation to having a pref for this?
I read some of the above comments and I sympathize with the users affected by this but it also feels like being bullied into a solution.
The calendar UI is scheduled to be reviewed and I think the re-design (with user feedback included) should be given priority instead.

Assignee: lasana → nobody
Flags: needinfo?(lasana)

I have a working patch.

Assignee: nobody → bugzilla2007
Status: NEW → ASSIGNED

(In reply to Thomas D. (:thomas8) from comment #138)

I have a working patch.

Reviewed, complemented, tried and nitfixed - now ready to land :-))

Keywords: pm-triage-needed → checkin-needed-tb
tracking-thunderbird_esr102: ? → +
Target Milestone: --- → 105 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/54957c3ec9ad
Add pref calendar.events.defaultActionEdit for editing events on double-click. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

Status update [2022-08-20]:

  • The new hidden preference calendar.events.defaultActionEdit (default: false, i.e. double-click opens event preview) is now available and functional on the development/alpha version of Thunderbird (available from www.thunderbird.net, Daily channel in the bottom right corner). There's no dedicated UI for the pref because we don't add strings (translations) between major versions. Please refer to the instruction further down in this comment.
  • Within a few days, it will be available on Thunderbird Beta channel for testing.
  • If there are no problems, we'll uplift this to a point release of Thunderbird 102.2.* ESR (release channel) - you'll see this when the thunderbird_esr102 flag on top of this bug changes from affected to fixed (and then it may still take a little for the build to be public). So it should now be a matter of weeks for the fix to go live.

On releases where the fix is present:
How to restore double-click for Edit event

  1. ≡ > Settings > General > [Config Editor...] to open Advanced Preferences tab (aka about:config).
  2. Type calendar.events.defaultActionEdit into the Search preference name input.
  3. Double-click on the pref entry or use the ⇄ toggle button to toggle the pref from false to true.
  4. Double-click on events will then open the Edit Event dialog/tab as in TB 91. Enjoy!
status-thunderbird105: --- → fixed
status-thunderbird_esr91: --- → affected
Summary: Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly - implement pref (pls read comment 75 before commenting) → Double-clicking an event now shows an unwanted intermediate event summary window rather than opening the "Edit Event" dialog/tab directly - implement pref `calendar.events.defaultActionEdit`
Whiteboard: [read comment 75 before commenting] → [current status and instructions: comment 142][key summary: comment 75]

Comment on attachment 9289694 [details]
Bug 1685007 - Add pref calendar.events.defaultActionEdit for editing events on double-click. r=aleca

[Approval Request Comment]
Regression caused by (bug #): bug 1575195, bug 1673654
User impact if declined: Depending on users' workflows/scenarios, recurring frustration about unneeded interim step every time they need to edit an event (affects ux-efficiency).
Testing completed (on c-c, etc.): Yes. Tested working flawlessly on Daily 106.0a1 (2022-09-01) (64-bit) and 105.0b2 (64-bit).
Risk to taking this patch (and alternatives if risky): Very low. We just check the new pref to switch between the legacy and the new behaviour.

Attachment #9289694 - Flags: approval-comm-esr102?

Comment on attachment 9289694 [details]
Bug 1685007 - Add pref calendar.events.defaultActionEdit for editing events on double-click. r=aleca

[Triage Comment]
Approved for esr102

Attachment #9289694 - Flags: approval-comm-esr102? → approval-comm-esr102+
Blocks: 1789312

Many thanks to everyone who came up with a solution.
Preference: calendar.events.defaultActionEdit = True
Confirm this works in 102.2.2
Double opens Event in Edit mode.

Thomas,

Thank you for making this happen in the end :-)

May I ask what's gonna happen with the original plan as per Comment 21?
Is it gonna be worked on in the year to come for next stable as to find a common ground and balance for those that read and edit events?

I am the first one to appreciate ability to Edit quickly event, no more annoyance... thanks god! Thanks Thomas! ... but I think it would still be worth to have an ability to read items in parallel with one click and two click to edit it... it would make sense from a usability point of view (at least on Desktop but Mobile as well) and depending on the user wish... eg. joining a meeting (read), versus modifying a meeting (write) which are not exclusive but depending on users, one might be more frequent than other but should not be either or... all users shall be able to read and write easily items in an intuitive way... Hope that make sense...

If there is already some discussion going on about it somewhere else feel free to share... I am conscious that this original bug is now fixed... short term... but long term more discussion/development may be needed I would think to refine and implement a fit all case solution... something like Comment 21... was a good starting point...

Thank again from your (and the teams) effort so far :-)

Regards,

(In reply to Richard Leger from comment #148)

May I ask what's gonna happen with the original plan as per Comment 21?
Is it gonna be worked on in the year to come for next stable as to find a common ground and balance for those that read and edit events?

Yes, that improvement requires more time and better exploration. But it's planned before the next ESR, alongside a visual refresh of the calendar UI.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: