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.

Features

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-US starts on Sunday while an app with locale fr starts 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 en-US is MM/DD/YYYY but in locale de is 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.

Month Picker — locale: en-US

Month Picker — locale: de

2. Accessibility:

• The Date Picker component has full accessibility for the keyboard. The calendar icon 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.

3. Themeable

We support both the light and dark versions of the Date Picker.

Light Theme

Dark Theme

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.

API

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:

<clr-date-container class="date-container">
    <input clrdate="" type="text" placeholder="MM/DD/YYYY">
    <button class="datepicker-trigger" type="button">
        <clr-icon shape="calendar"></clr-icon>
    </button>
    <clr-datepicker-view-manager>
       ...
    </clr-datepicker-view-manager>
</clr-date-container>

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 string using the Angular Forms API or as a Javascript Date object by adding a two-way binding on clrDate.

Mobile Support

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:

1. Most mobile browsers provide built-in date pickers which are optimized for mobile devices.
2. Future enhancements, like the datetime picker will be even wider and will take up most of real estate available on smaller screens.

Challenges

We encountered several challenges while the Date Picker was going through the design and implementation iterations. Two major challenges that are worth noting are:

1. Internationalization

Scott Mathis and I looked at Internationalization APIs that were readily available for Javascript applications and also at how other libraries approached internationalization. Most solutions had missing or inconsistent data. We found that:

• 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.

Scroll Snapping

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.

Arrows

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.

Upcoming Features

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 <input type="datetime">

For more details about the upcoming features, please take a look at this Github issue.