(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 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 screen. - 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 - 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, you could just show preview of the last focused&selected event. - 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 single-click to edit label convenient and intuitive.
Bug 1685007 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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 screen. - 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 - 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, you could just show preview of the last focused&selected event. - 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 single-click to edit label convenient and intuitive.
(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 - 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, you could just show preview of the last focused&selected event. - 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 single-click to edit label convenient and intuitive.
(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, you could just show preview of the last focused&selected event. - 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 single-click to edit label convenient and intuitive.
(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 single-click to edit label convenient and intuitive.
(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 single-click to edit label of an already selected item convenient and intuitive.
(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.
(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.
(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.
(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.