Select and Select Date

This is a blog post about the design of EmberUI. Haven’t heard about EmberUI? Read an introduction.

Select

The select element functions similarly to its HTML counterpart. The biggest improvement is the ability to style it with CSS and control its size without hideous aesthetics.

Its aesthetic matches that of the button design. Similar to the button you can choose which color the element should be with custom colors being very simple to add.

The select window will be scaled automatically to match up to 80% of the viewport’s height while making sure it plays nice with your markup. You should be able to place a select inside an element with overflow: hidden; set and not have to worry about the window getting cut off.

There will also be support for placeholder text, something badly needed in the HTML version.

Of course, error handling is also supported in the same fashion as other form elements.

Date Selector

Instead of going the traditional route of binding a calendar widget to a text input we instead base its aesthetics on the select. Conceptually it makes more sense to have it represented as a select and usability wise it is much simpler to understand. You are, after all, selecting a date.

The current date is highlighted in red, the current selection is highlighted in the same fashion as the select element’s hover.

We show two months at the same time to make it easier to navigate through time. Showing only one month at a time makes it feel very claustrophobic.

Allowing for manual input just creates a lot of questions in the users mind around which date format the date should be entered in. It also takes more cognitive energy to figure out what number corresponds to what month and the whole thing is prone to user error. If you do need to allow for the manual entry of a date (in the case of a date really far in the past such as birthday) we have the date input as covered in a previous post.

A good date selector needs to be very flexible and customizable. Date pickers are notoriously bad because it is a very difficult problem to solve. I want to change that by ensuring great usability is maintained while allowing for a variety of use cases.

When the field is set to required we remove the option to clear the date selection.

Besides controlling which days the user is allowed to select, you can also allow for selecting a date range (and lock the start or end date), make the field required, and require a past or future date.

The PSDs for these designs are available on Github under an MIT license. Feel free to use them as you see fit.