Building the Clarity Date Picker: Achievements and Challenges
Clarity recently released the Date Picker component. The Date Picker component allows the user to type a date or select one from the Date Picker. This article takes you through the features in the initial version of the Date Picker. It also highlights the challenges we faced while it was in development.
1. Internationalization Support:
Date Picker uses CLDR locale data extracted by Angular for internationalization. You can see the list of locale identifiers supported by Angular here. All the user has to do is set the locale of the app at build time and the locale data is automatically imported for them by Angular. More details about this can be found in the Angular Internationalization Guide.
Using the locale data, we can achieve the following things:
- Build the Calendar based on the first day of the week in that locale.
For example, an app with locale
en-USstarts on Sunday while an app with locale
frstarts on Monday.
- Generate the placeholder for the Date Picker input in a format that is familiar for users in any locale. For example, placeholder for the input in locale
MM/DD/YYYYbut in locale
DD.MM.YYYY. These placeholders are generated using the Date Format that Angular extracted from CLDR for each locale.
- Month and Day Names are displayed in the locale language.
- The Date Picker component has full accessibility for the keyboard. The
calendaricon button, next to the input field, opens the Date Picker and initializes focus on the date selected by the users (if date is not selected, the focus defaults to today’s date). Users can then navigate across the Calendar with the arrow keys.
- All colors combinations used in the Date Picker meet WCAG AA compliance.
We support both the light and dark versions of the Date Picker.
4. Enhanced Experience
Our UX research found that having separate month and year pickers gives users greater control when picking a date. Having the ability to choose month and year separately, instead of navigating one month at a time, makes date selection easier. Navigating to the current date is another common user action and this is provided to enhance the user experience.
5. Browser Support
The Date Picker component is supported on IE11, Edge, Chrome, Firefox and Safari.
All of the above features are achieved using a simple API:
<input type=”date” clrDate/>
This API can be achieved with a technique written by Eudes Petonnet that allows us to wrap the host element on which the directive was added with a container component. The container component projects the host element inside of it and adds any additional markup right next to the host element. This additional markup remains internal to the implementation.
For example, The Date Picker markup:
<input type=”date” clrDate/>
is actually rendered on the page as:
<input clrdate="" type="text" placeholder="MM/DD/YYYY">
<button class="datepicker-trigger" type="button">
This technique simplifies the API and cuts down on the markup needed by the user to activate a feature.
In addition, for the Date Picker, this API allows the user to access the date as a
Date object by adding a two-way binding on
Clarity Date Picker is disabled on mobile devices. The breakpoint for disabling the Date Picker is at screen width below 768px. We decided to do this because of two main reasons:
- Most mobile browsers provide built-in date pickers which are optimized for mobile devices.
- Future enhancements, like the
datetimepicker will be even wider and will take up most of real estate available on smaller screens.
We encountered several challenges while the Date Picker was going through the design and implementation iterations. Two major challenges that are worth noting are:
- Some libraries maintained locale data on their own which the users could consume easily. However, the data was being maintained by these libraries, wasn’t standardized and had inconsistencies.
- Some libraries asked the users to initialize the locale data on their end.
- Some libraries did not worry about internationalization at all.
We took our research back to our internationalization team at VMware and they had similar findings. They recommended that we take a look at CLDR. CLDR is a project maintained by the Unicode Consortium. It is used by many companies for internationalization and localization. Of all the data sources we looked at, it is the most compliant. After validating our use cases against the data from CLDR, we wrote a script which extracted this data for Clarity.
Extracting the CLDR data ourselves had to be done to make sure that we had access to consistent locale data but this was not a popular decision because maintaining and testing this data was something that we were not expecting to undertake when we initially started working on the Date Picker.
Fortunately for us, we learned that Angular was dropping the Intl API to use CLDR instead too. Although we lost a month on the research and data extraction, Angular supporting CLDR data was a huge indicator that we were headed in the right direction. We decided to use the data directly from Angular instead of extracting and maintaining it on our own. Big thanks to Olivier Combe from the Angular team, who let us know which fields they were extracting from the CLDR data.
We chose to spend extra time on internationalization because the Date Picker is the first component in Clarity that utilizes locale data. We wanted to make sure that the research was in-depth so that other components in Clarity that would use this data would benefit from it.
2. Scroll Snapping
After covering the internationalization part, we built the Calendar, Month Picker and Year Picker and tested them against the CLDR locale data but faced a major issue with navigating to the previous and next months.
Our initial design for previous/next month navigation included scroll snapping that animated the months into view.
We invested a lot of time trying to make this work on different browsers and across different devices. We ran into many issues that slowed development while they were researched and addressed. Late in the dev cycle we learned that Mozilla discourages scroll snapping and any other kind of scroll-linked effect.
Implementing scroll snapping when one of the major browsers was in the process of deprecating it is something that we didn’t want to do. We went back to the drawing board and decided to use arrows to move to the previous and next month.
Looking back, we spent a lot of design and implementation time researching and trying to implement scroll snapping. Hindsight makes it clear that previous/next arrow buttons provide us with a good user experience without the overhead scroll snapping has. As a team, we have added checkpoints to our design/dev process so we can time-box issues like this in the future.
Now that we have tackled the above challenges, we have many interesting new features that we plan to add to the Date Picker. A few of them are listed below:
- Disabled Dates
- Min/Max Dates
- Date Range Picker
We also plan to build and include the Time Picker component with the Date Picker to support
For more details about the upcoming features, please take a look at this Github issue.