Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve usability and design of the current date picker calendar #680

Closed
mattab opened this issue Apr 27, 2009 · 15 comments
Closed

Improve usability and design of the current date picker calendar #680

mattab opened this issue Apr 27, 2009 · 15 comments
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.

Comments

@mattab
Copy link
Member

mattab commented Apr 27, 2009

Current date picker doesn't have a good UI. It is not clear what dates are currently selected, what is clickable, and design is not eye candy.

Here is a proposal for improving the date picker:

See attached file for proposed mockup of general look n feel (Marcin mockup modified by Matthieu)
See current Piwik calendar on the demo: piwik.org/demo - click on the date to show the calendar.

Definitions

* By "Changing state" I mean "firing a callback to update the date of the report".
* By "active" I mean "the day(s) are highlighted in the calendar to show that the currently displayed report covers these days.

Specs

* set a minimum date: the minimum date is the first date in the calendar on which the user can click on (first date for which we have data). Days before minimum dates have different CSS styles and are not clickable.
* Dates in the future are not clickable - have custom CSS style with light color (same as days before minimum date).
* by default the selector shows "MONTH YEAR", ie. "August 2008", "September 2008". It does not have two selectors, one for month and one for year.
* all dates assumptions must be server based; for example, the minimum date and "today" are generated and fed to the calendar object, not read directly in Javascript; this is because the reports could be set in different time zone from the users' browser.

Notion of "period": user can select day, week, month, or year period.

* if day is selected, only one day is active. Clicking on the selector to change the month doesn't change state (simply updates calendar to show days in the selected month). Clicking on a new day in calendar changes state. The "Date Range" shows "Monday 15 August 2009".
* if week is selected, all days in the week of the current day are active; weeks can go over two different months; If week overlaps between two months, when changing month in the JS calendar, days of the selected week are active. Clicking on the selector to change the month doesn't change state. The "Date Range" shows "Week 30 Dec - 6 Jan 2009"
* if month is selected, all days in month are active. Clicking on the selector to change the month changes state: the new selected month is applied to the report. The "Date Range" shows "August 2009"
* if year is selected, all days in all months are active. The selector then shows years rather than month, ie. "2008" rather than "September 2008"/"October 2008" etc. (when day/week/month period is selected, the selector shows one entry per month). The "Date Range" shows "Year 2009".

Notes:

* when month or year is selected, and changing to a sub period, date defaults to the selected period starting at beginning of the current date. Example: if August 2009 is selected and user changes to week or day, it will select "Week 2 Aug - 9 Aug 2009" and "Monday 1st August 2009".
* a click on any of the period changes state directly, and collapse period selector; the user doesn't need to see the calendar, because he has feedback of currently selected period in the explicit "Date Range" string.
* calendar doesn't shows days from previous and next month. cells are left blank
* all period strings would be generated in Javascript, which means that JS has knowledge of how to build these strings; calendar would get i18n strings with format, for example: days-> "%D %j %F %Y", week -> "Week %j1 %M1 - %j2 %M2 %Y2", etc.
* clicking anywhere on the closed calendar div opens the calendar. clicking anywhere outside the calendar div closes the calendar.

* in the future, Piwik may support "custom date range" reports, so I think we would have a new entry below "year": "Custom range", and on the left two or three calendars would be displayed to allow selection of a wider date range. However this is not a requirement now.
@mattab
Copy link
Member Author

mattab commented Apr 27, 2009

Attachment: mockup of the proposed date picker
date+picker.jpg

@robocoder
Copy link
Contributor

jqueryui datepicker on steroids: !http://keith-wood.name/datepick.html

@robocoder
Copy link
Contributor

Duplicate date bug reported in forum: http://forum.piwik.org/index.php?showtopic=1602

@robocoder
Copy link
Contributor

Re: the duplicate date bug, there's a loop in jquery-calendar.js that simply increments the date by 1 day on each iteration.

for (var row = 0; row < numRows; row++) { // create calendar rows
...
    for (var dow = 0; dow < 7; dow++) { // create calendar days
...
        (unselectable ? printDate.getDate() : '<a>' + printDate.getDate() + '</a>')) + '</td>'; // display for this month
        printDate.setDate(printDate.getDate() + 1);
    }
...
}

@robocoder
Copy link
Contributor

Replying to vipsoft:

  • jquery-ui datepicker contains a new internal function, _daylightSavingAdjust(), presumably to correct this problem

@robocoder
Copy link
Contributor

In [1587], refs #680 - improve usability of datepicker

  • updated from jquery calendar 2.7 to jquery-ui datepicker 1.7.2
  • contains a DST-related fix that might solve an issue of duplicate days reported by some users
  • fixes regression in UI where clicking on calendar icon would not collapse the calendar
  • implements some of the style changes shown in the mockup
  • updated the calendar text translations from the jquery-ui i18n

@robocoder
Copy link
Contributor

In [1598], date picker (calendar): revert back to Monday start date for week

@robocoder
Copy link
Contributor

In [1602], remove styling on today's date

I don't recommend switching to Keith's jquery.datepick 3.7.2. It is not a drop-in replacement. Its ability to highlight weeks onHover is limited to adding bold to the numerals displayed. Bug: text is truncated in the month selector.

@robocoder
Copy link
Contributor

In [1603], restore highlighting of current period; jquery.calendar's customDate hook was renamed to beforeShowDay in datepicker

@mattab
Copy link
Member Author

mattab commented Dec 17, 2009

Moving to after piwik 1.0 as the current design is OK for now - some work will be done on it soon as the period compare mode is being implemented by a third party developer.

@mattab
Copy link
Member Author

mattab commented Dec 17, 2009

@mattab
Copy link
Member Author

mattab commented Mar 21, 2010

Not sure why I reopened it in the first place, looks like usability of the calendar is fine as of now!

@robocoder
Copy link
Contributor

Actually, Maciej made some improvements that I think we should adopt:

  • ability to highlight a week.
  • using a popup instead of the accordion effect when opening/closing the datepicker.

@mattab
Copy link
Member Author

mattab commented Mar 22, 2010

sounds good, reopening

however, let's wait until #291 is fixed as there are some changes in the calendar in the branch and it would get messy if we did the changes in trunk too.

@mattab
Copy link
Member Author

mattab commented Jul 29, 2010

This was implemented in the new design. http://piwik.org/blog/2010/07/new-piwik-design-screenshots/

@mattab mattab added this to the Future releases milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

2 participants