Bugzilla – Full Text Bug Listing
| Summary: | [activity] [i18n] Date chooser: allow week to start on Mondays | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Gerd Castan <eclipse> | ||||
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | jeremyd | ||||
| Version: | 0.6 | ||||||
| Target Milestone: | 3.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 173809, 227901 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Gerd Castan
The idea of the work week starting on Monday is alos part of Mylar's planning support, so this should be the default presentation. Generally configurable work weeks would be another enhancement request, but could overly complicate the UI. Rob, as part of this change you should consider showing this and the next month, getting rid of the month combo, and just adding "<" and ">" buttons to go back and forward between months. The date picker will be overhauled as part of the ui review for 1.0. We will address this problem then. By the way, can we see two months in the date picker? Current one is really inconvenient at the end of the month. Would the Mylar team benefit from having someone else carry the burden of the date picker/chooser widget? Nebula has voted in the one I have been working on and it will be uploaded to their repository within the next few weeks. In the mean time, it can be seen at its current home: http://www.aspencloud.com/widgets.php?detail=cdatepicker (it is i18n'ed and should also take care of https://bugs.eclipse.org/bugs/show_bug.cgi?id=135930) (In reply to comment #3) > By the way, can we see two months in the date picker? Current one is really > inconvenient at the end of the month. I should also mention that although the CDatepicker, mentioned in comment #4, does not show two months, it does scroll vertically by week to eliminate this "end-of-month boundary" problem. Excellent! It looks great and I'm looking forward to integrating it. It would be great if we could reuse the date picker from Nebula and we have always hoped that the responsibility of maintaining this widget would eventually fall elsewhere since it is needed by so many. Jeremy: we would need to redistribute Nebula with our download. For the short term it probably makes sense for us to do redistribute it in binary form rather than creating an update site dependency. Could you please point us to the download once it becomes available? (In reply to comment #7) > Could you please point us to the > download once it becomes available? Just as an update - the widget is in IpZilla right now; I'll definitely let you all know when it is actually uploaded to Nebula. It will need a bit of refining I'm sure, but making a binary for distribution with Mylar should not be a problem. cheers Is this the same that is described in bug 19945 or are these two different implementations? Gerd (In reply to comment #9) > Is this the same that is described in bug 19945 or are these two different > implementations? These are two different implementations - the SWT widget (included in 3.3M3) will be using native components where available and emulated ones where they are not. My widget (CDateTime once it hits Nebula) is be completely emulated. Unlike the SWT widget, CDateTime is primarily focused on providing the best possible UI for a task related date/time selection (it was initially created for a contact manager I'm working on). I jumped into bug 19945 with comment #20 to try and coordinate the api with SWT's, but this has been unsuccessful. With Mylar's general philosophy of always decreasing the number of clicks required to get stuff done, we have the important requirement that most of the time the dialog should not require more than 2 clicks to pick a date and time, and rarely require more than 4 (year, month, day, hour). This is why we currently inline the month and hour selection and make the dialog so large. Jeremy: could you attach a screenshot of your widget? I'd us to think through how many clicks scheduling will take. Created attachment 53907 [details]
Screenshots of the CDateTime widget on Linux GTK
Please note that these are of the graphical selection portion of the CDateTime widget. It can also be used a textual-only widget (with a spinner for inc/dec) as well as a drop_down combo, in which case the graphical portion shown will drop down when the button is pressed.
(In reply to comment #11) > Jeremy: could you attach a screenshot of your widget? I'd us to think through > how many clicks scheduling will take. The analog clock has the ability to have an increment set so that it "snap" to, say, 15 minute increments. This has not been completed for the discrete clock, but may improve it some, especially if 1 hour granularity is all that's needed. Additionally, the discrete clock may benefit from a 2x12 hour format for locales which are not using the 24 hour format (thoughts?). Overall, I want to stress that this widget is *emulated*, meaning that although it is important for it to feel native (native colors, buttons, menus, etc) it is not bound by any platform's implementation and can be modified to suit the needs of time/task management applications - if there's a better way I'll be glad to implement it (and if people want to help with that implementation then so much the better! :)) We will look at adopting this new widget post 1.0. I don't really fancy analog representation. And discrete representation is imho not quite intuitive. I also wonder how friendly these widgets to the mouseless navigation? (In reply to comment #15) > I also wonder how friendly these widgets to the mouseless navigation? I've tried to clarify this more on the website: http://www.eclipse.org/nebula/widgets/cdatetime/cdatetime.php?page=operation. CDateTime is intended to function fully with either a keyboard, mouse, or pen. If a case is found to be lacking, please file a bug. > I don't really fancy analog representation. And discrete representation is > imho not quite intuitive. What time representation do you fancy? (this is custom and open to suggestions) Jeremy: I would like us to improve the date/time selection for Mylar 2.0 and I definitely like the idea of using Nebula for that. The thing that we always try to do with the Mylar UI is minimize the number of clicks as much as possible. For time/date selection we try to keep it down to two clicks, and three if the month has to be changed. That's why we have been shying away from drop-downs and analog clocks. My main problems with our current dialog are: * The vertical month chooser should never have a scroll bar, since there can only ever be 12 things in it. * The day chooser should be the current Nebula widget since it is considerably better. * The hour chooser should start on the work-day start hour, not at 12am. * The resulting date should be editable as text within the dialog itself (e.g. for choosing minutes) So I'm wondering, is this a direction that you would consider for the Nebula widget, or should we be trying to make a hybrid Mylar/Nebula chooser? (In reply to comment #17) > So I'm wondering, is this a direction that you would consider for the Nebula > widget, or should we be trying to make a hybrid Mylar/Nebula chooser? Mik, After some thought, I think that this would be a good addition to CDateTime - it presently has a 'COMPACT' style which takes it in the opposite direction (small visual footprint, but more clicks required), and I think the addition of a 'VERBOSE' style may work well for the requirements you have described (fewer clicks, with less concern about visual footprint). > ... analog clocks. Just to mention it: analog clocks are great for viewing time - relative time - and not so much for selecting it. Likewise, I also wouldn't expect to see Mylar make much use of it. > * The hour chooser should start on the work-day start hour, not at 12am. How would the user set the work day? And how would they select times that are not during the work day? As a user, this feature has always caused me problems - especially if I'm using the app for working on open source (after hours) projects. > * The resulting date should be editable as text within the dialog itself (e.g. > for choosing minutes) I don't understand this concern - if a user is setting a date/time via the mouse, and has the option of setting minutes, they shouldn't be required to switch input devices. Also, it seemed that the date/time selector is always opened from a text widget - couldn't they set the minutes there rather than opening another shell? Perhaps I missed where this is necessary? Finally, with the modular design of CDateTime, the most difficult part is deciding how this selector should be laid out - if anyone has suggestions please attach a drawing/picture. cheers! (In reply to comment #18) > How would the user set the work day? And how would they select times that are > not during the work day? As a user, this feature has always caused me problems > - especially if I'm using the app for working on open source (after hours) > projects. Mylar has a preference for workday start and end and uses this to facilitate scheduling. If someone works on other projects on evenings, they can just set the length of their workday accordingly. Not to mention that there's no big problem with working "afterhours" from the Task List's point of view, other than the fact that things that didn't get done today but were supposed to go red. The bottom line is that it would be helpful if this widget could take a workdayStart parameter so that it could be scrolled to the appropriate time. > > * The resulting date should be editable as text within the dialog itself (e.g. > > for choosing minutes) > I don't understand this concern - if a user is setting a date/time via the > mouse, and has the option of setting minutes, they shouldn't be required to > switch input devices. Also, it seemed that the date/time selector is always > opened from a text widget - couldn't they set the minutes there rather than > opening another shell? Perhaps I missed where this is necessary? I was suggesting that the UI retain our current property of not providing a quick way to set minutes. Nobody has every complained about the fact that we don't support this, because it is such a rare operation, and they know that they can manually edit the date in the corresponding field editor. So what I'm suggesting is taking that text field editor and putting it in the widget itself. This has two benefits, and the cost of only one row: * A human readable date shows in the widget (e.g. at the bottom). * The full date can be edited directly (e.g. to set minutes) or copied as text. > Finally, with the modular design of CDateTime, the most difficult part is > deciding how this selector should be laid out - if anyone has suggestions please > attach a drawing/picture. The layout I was suggesting is our current date chooser, but with the changes described above (e.g. right-click on task -> Schedule -> Choose Date...). Let me know if you'd like me to attach a screenshot. Mylyn has adopted the DateTime SWT widget that uses OS native date time calendar widgetry. The start day will now be correct if your OS locale settings are set appropriately. |