Chapter 1: The Case Against Strict Date Formats

Recently, I came across an insightful post by Mark Wyner, a skilled expert in user experience design. He highlights a crucial aspect of date input in forms, emphasizing the need for flexibility.

To illustrate his point, he presents a comparison between two input methods:

In the first example, the date format is indicated as a placeholder that disappears when the user begins typing. In contrast, the second example places the date format above the input field, ensuring it remains visible at all times. This approach, as Mark suggests, enhances user experience significantly. I completely agree with his insights, and I would further recommend placing the format either directly under the input or in a distinct line above it. This is especially important since text length can vary depending on the language.

Another pertinent example is the password field. It’s ineffective to highlight issues one by one, such as:

• Missing a number
• Missing a special character
• Password too short
• Password too long

Displaying one error at a time is far from ideal. Instead, all requirements should be clearly visible even before the user starts typing their password. These examples illustrate the importance of ensuring that requirements are evident from the outset.

Mark does an excellent job of explaining these concepts. However, my intention is not to reiterate his points but to expand on the date input issue. In 2023, we have the opportunity to rethink how we handle date entry altogether.

MM/DD/YYYY is not a universally accepted format! Take a look at this map:

The map illustrates that while 339 million people use MM/DD/YYYY, a staggering 4.6 billion do not. Many others utilize various date formats. It is time to recognize that enforcing a specific date format is no longer necessary.

Historically, enforcing date formats stemmed from the need for standardization in official paper forms, aimed at minimizing errors during processing. This practice was merely transferred to digital forms and has persisted for over two decades. In the early days of technology, it was indeed convenient due to the limitations of legacy systems.

Fast forward to 2023, and technology has advanced significantly, allowing us to recognize user-specific date formats. While it may not be entirely straightforward, it is certainly feasible. In cases where the format cannot be determined, we can revert to a default option.

Moreover, we can parse and validate dates using the user's preferred format, ensuring consistent data handling across APIs and applications. This means users should be able to enter dates in the format they are accustomed to. While I would still advise providing reminders about the expected format, this approach can greatly enhance the experience for international and multilingual users.

Discussion

In this section, I want to share some initial thoughts regarding my proposal. Determining a user's preferred date format is achievable, as JavaScript can format dates according to user preferences. However, currently, the Intl object lacks a direct method for retrieving this format, which is a limitation that should be addressed.

While some may hesitate to adopt this method due to its complexity, I believe that a polyfill library and functions available in popular date handling libraries would make it manageable and reliable for implementation.

Another challenge lies in the mindset of designers and product owners who continue to impose a single date format. This presents an opportunity for education, either now or in the future, to reduce user friction by embracing flexibility.

Additionally, some developers might find this approach too complex. However, allowing users to input values in their familiar format is not unprecedented; for instance, users can already use different decimal separators.

For applications that already manage such settings, integrating preferred date formats should be a straightforward sell to stakeholders who might be resistant to browser-imposed restrictions.

Some may argue that the benefits are minimal compared to the implementation costs. However, I've witnessed situations where teams obsess over trivial sizes of data transfer, so I find it hard to accept that the costs are prohibitive. Ultimately, we must prioritize user-centric considerations.

While I agree that this change may not be revolutionary, it offers a path to enhance user experience, especially for those seeking improvements.

Update

Interestingly, the standard HTML input field for dates already accommodates user-friendly formats out of the box.

If you're interested in more articles on coding and user experience, please clap, subscribe, and share!