Closed Bug 397939 Opened 17 years ago Closed 11 years ago

[Today Pane] Allow more ways to navigate between the days

Categories

(Calendar :: Lightning Only, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Fallen, Assigned: bv1578)

Details

Attachments

(3 files, 4 obsolete files)

Ahh oops, itchy trigger fingers. I think there should be more ways to navigate in the miniday. Having more than one way makes it better to adapt to different types of users. The following could (all) be implemented: * Click, drag left or right, days switch faster the more the mouse is away from the today dot. * Use the mouse wheel in the mini day header. * Click on the next/previous buttons, but don't release. After a certain timeout, start advancing days and increase speed.
Also, it would be nice if double click would provoke an action: * On Day Number: Open calendar day view on that day * On Month/Year: Open calendar month view on that month * On CW: Open week view showing that week. I admit the latter two would be quite hidden features, but since they don't do any harm I'd still vote for taking them.
Severity: normal → enhancement
Attached patch patch - v1 (obsolete) β€” β€” Splinter Review
Philipp, I did this patch almost a year ago, but there was always something more important to do about Lightning (and the rapid release cycle doesn't help). At the end I've decided to update the patch and propose it for feedback, so you can decide yourself when, and if, you have time to take a look at it. The patch implements all the features requested in the previous comments. The automatic days switching on the navigation buttons and the days switching by dragging the day label, need to be verified in the usability. Maybe the part related to the drag feature needs to be written differently. Let me know.
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #583517 - Flags: feedback?(philipp)
Comment on attachment 583517 [details] [diff] [review] patch - v1 On a code level this patch looks very nice, I'd r+ that part. Leaving this in my feedback queue to give the patch a test.
Comment on attachment 583517 [details] [diff] [review] patch - v1 From testing this feels very good. The only thing I had trouble with, the click on the date number and dragging starts to late for my taste. I first thought it wasn't working and only later noticed I had to go far enough away.Also, I'd make it accelerate much faster, so that the numbers just fly by when you hit the right border of the today pane. Also, since the numbers move in steps of 2 at some point but the change rate is still slow, it feels flaky. If you could make it work just as smooth as the click-and-hold-leftright-arrows feature, that would be swell. Aside from that, r=philipp fully. Let me know if you want to fix that or if I should push this as is.
Attachment #583517 - Flags: review+
Attachment #583517 - Flags: feedback?(philipp)
Attachment #583517 - Flags: feedback+
Attached patch patch - v2 (obsolete) β€” β€” Splinter Review
Now the switching with drag starts with a minimum mouse movement (2 pixels) and it doesn't need to go far from the starting point to rapidly increase the speed, moreover the days switch with steps of 1. Give it a try. You can also change the parameters (400, 8, and 100 in the line #113) in order to find a better usability. Do you think it's worth adding a switch by month (or week) with the mouse wheel on the month/year label (or current week label)? At the moment the mouse wheel switches by day in every point of the miniday. Anyway this might be done in another bug.
Attachment #583517 - Attachment is obsolete: true
Attachment #591314 - Flags: review?(philipp)
Attached patch patch - v3 (obsolete) β€” β€” Splinter Review
Yes, much better. I've taken the liberty to make some slight modifications, like using constants for the numeric values. I've increased the initial area to 4 pixels instead of 2. Could you check to make sure the constants have correct names and that I found all useful places to use constants? Also, one last request, it would be nice if after starting the drag, you can return to the middle to temporarily stop the movement. I tried to implement this and it initially works, but after a few dragging left and right it seems that this is no longer the case. Maybe you know what I'm doing wrong and can fix it.
Attachment #591314 - Attachment is obsolete: true
Attachment #592521 - Flags: review?(bv1578)
Attachment #591314 - Flags: review?(philipp)
Attached patch patch - v4 (obsolete) β€” β€” Splinter Review
Oops, forgot to refresh the patch. This performs better
Attachment #592521 - Attachment is obsolete: true
Attachment #592522 - Flags: review?(bv1578)
Attachment #592521 - Flags: review?(bv1578)
Attached patch patch - v5 β€” β€” Splinter Review
(In reply to Philipp Kewisch [:Fallen] from comment #7) > Could you check to make sure the constants have correct names and that I > found all useful places to use constants? They are fine. I've only changed one of them because it comes to me the idea to set directly the time interval instead of the relation with another time interval. > Also, one last request, it would be nice if after starting the drag, you can > return to the middle to temporarily stop the movement. .... > .... To make that working smoothly, it needs a little change in the position of the date in the miniday because the actual center of the day's label depends on the number of digits (one or two). When the date changes, the center gets moved to the right or to the left according to the number of digits, so there isn't a static "middle" where return the cursor to temporarily stop the days switching. I've changed the miniday a bit so the width of the date label stays the same with one or two digits and the label's center is always in the same position. Once the drag has started, the reference point becomes the center of the date label that is a fixed point. I've also added an image that appears over the day label when the user starts to drag (see the screenshot) which globally gives somehow the indication that a drag operation is in course. The circle identifies the precise zone where the user can place the cursor in order to stop days switching (it physically displays the "middle" you requested in the previous comment), moreover the "+" and "-" give to the user an indication of what happens by dragging to the right or to the left. If you think it's a madness, I will remove it ;-) I'm aware of the issue with onDOMMouseScroll. If it's not a problem I will do a patch when I will figure out how the "wheel" event works.
Attachment #592522 - Attachment is obsolete: true
Attachment #592522 - Flags: review?(bv1578)
Attachment #666296 - Flags: review?(philipp)
Attached image drag-center image β€”
Image that appears over the day label when the user drag over it.
Comment on attachment 666296 [details] [diff] [review] patch - v5 Looks good, r=philipp I like the new icon, I just hope its not too distracting since its right on the number. OTOH, if placed elsewhere then it might not be obvious what it means. If you think its good as it is, go ahead and check in, otherwise ask :andreasn for ui-review.
Attachment #666296 - Flags: review?(philipp) → review+
Attached image drag-center images β€”
(In reply to Philipp Kewisch [:Fallen] from comment #11) > I like the new icon, I just hope its not too distracting since its right on > the number. OTOH, if placed elsewhere then it might not be obvious what it > means. > > If you think its good as it is, go ahead and check in, otherwise ask > :andreasn for ui-review. OK, asking for UI review. Please Andreas, read comment 9 for the meaning and the usefulness of the image. If it's matter of being a bit distracting, it could be made thinner as showed in the screenshot.
Attachment #688983 - Flags: ui-review?(bugs)
Andreas, any news on this UI-review? Since the required changes are minimal, maybe I could push the patch as it is and doing possible changes later. Just let me know.
Comment on attachment 688983 [details] drag-center images I'm taking the Andreas's ui-r I think the image isn't distracting the number to much. The number is always readable and making it thinner makes the image less discoverable. Only one thing: when I scroll the mouse wheel up (away from me) then the date goes down. Is it only me who expects the date should then increase?
Attachment #688983 - Flags: ui-review?(bugs) → ui-review+
Thanks for the review Richard. The direction of the scroll with the mouse wheel should be right because it is the standard behavior of every scrollable element with a date in Lightning. When you scroll the mouse wheel up (away from you) e.g. on any minimonth or on any view, you always get decreasing dates (scrolling up you want to see the past relatively to the date currently showed). I think that doing the opposite only for the miniday would be odd, but we can listen to others opinions too.
(In reply to Decathlon from comment #15) > I think that doing the opposite only for the miniday would be odd, but we > can listen to others opinions too. Since the patch has got all the reviews, I think we can push it in the repository in order to allow someone to use it and evaluate the issue of the scroll direction related to the increasing/decreasing of the dates (as mentioned in comment 14). The scroll can be easily changed if someone reports an unexpected behavior. Maybe we can open a new bug with a "qawanted" or other keyword for this issue. Pushed to comm-central changeset: https://hg.mozilla.org/comm-central/rev/e7774f78ffde
I set qawanted in the keywords in order to get feedback about the question in comment #14: > Only one thing: when I scroll the mouse wheel up (away from me) then the > date goes down. Is it only me who expects the date should then increase?
Keywords: qawanted
Since this enhancement should go into comm-beta soon, and since the issue in comment 14 does not prevent the use, I change the status to Fixed and I remove the qawanted keyword. If it's OK I will wait for possible bug reports to consider the issue in comment 14.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → FIXED
Target Milestone: --- → 3.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: