Nitpicking DatePickers — An OnTrack Enhancement Study

Our enterprise product OnTrack combines location and social data to provide strategic insights to (restaurant) brands. Comparing the performance in different time-periods is normal and COVID only made it super important because it changed the way customers visited restaurants — like pre-Covid, post-first wave, post-second wave and so on. Hence, some brand managers of restaurants wanted to compare not just month on month or quarter on quarter, but two different date ranges that mattered to their brand during this tumultuous period. This post chronicles the seemingly simple enhancement we made bearing in mind that the user experience must be kept optimal.

To begin with we decided that we’d create a basic version of the DatePicker, which had one DatePicker and one selector to select a ‘previous’ time period to compare it to (previous week, month, quarter, etc.). For (power?) users who would like to dig in further, there would be an advanced version from the DatePicker itself, which would show 4 dates to pick the ranges the user needed.

DatePickers have been quite the meme/joke in the programming community, with posts and discussions ranging from different and ‘unique’ DatePickers to the frustrating logic of trying to get it to work to your specification.

A drop down date picker with date values instead of human readable dates. An extreme example, but there are countless bad date pickers that can be found on reddit.com/r/crappydesign

An example of a date input from the subreddit of CrappyDesign

Nonetheless it’s an important part of any application. With Affinity Answers’ OnTrack, dates and date ranges are a critical part of our offering and making sure that they work well and across all edge cases is essential for a smooth user experience.

The task was quite unique for many reasons, most applications require only one date picker, an example would be selecting a date to see all the events happening on that date, or two DatePickers, a very common use case is booking a round trip for any mode of transportation.

A demonstration of the features that are required so users can seamlessly transition between the two modes.

Most teams have a straightforward system for a start and an end date, but OnTrack has a total of 6 dates to manage, three sets of start and end dates and two of them have parts which need to be in sync.

Making changes to an already intricate system was not a straightforward task, here are some of the challenges.

Points of Potential Failure

• Overlap - The DatePicker handles 2 ranges with 4(6, technically) date pickers, making sure there was no overlap causing any issues was important. Making sure the dates ‘moved’ smoothly regardless of the advance option was selected or not.
• Boundary cases - Boundary cases are the biggest pain point of any application that deals with data and user input. Allowing the user to make any input they want and still return something that makes sense when they are close the boundaries of available data is a key part the selection of date ranges.
• Sync across views - OnTrack has a number of tabs that deals with the same dates and data. Keeping dates in sync across different the two different modes (basic and advanced), across the tabs while also handling unique boundary cases for each tab and the switching of tabs is not a straightforward task.

Handling Boundary Cases

Boundary cases being one of the most critical points, the sheer number of ways the user input could break the application is a lot and must be handled well. Here are some of the ways boundary/edge cases can be reached and how it’s handled.

• Changing Interval — Changing the interval on the application near a boundary date could bring the date into an undesirable range. Handling interval changes, meaning changing a range of a week to a range of a month around the boundary dates must be handled very carefully.
• Changing Previous Interval — Changing the previous interval on the any of the pages shouldn’t allow you select past a certain date range. The way it’s handled is by calling a function that always checks the validity of the date range. Once this is called, the menu will only be populated with options that are available, solving the issue.

• Handling selection of boundary dates - Boundary dates change with the change in the interval and because of the nature of the data we receive, the ‘weekly’ interval must be handled very differently to a ‘monthly’ interval. To handle these boundary dates and the selection of a previous interval, we have to code these specific options first.

• Handling sync changes with start-end and dashboard-start and dashboard-comparison-end.

Changing certain dates on the certain tabs on the dashboard needs to be in sync with dates on the dashboard.

Two date ranges have two parts that need to be in sync. The start date on some pages and the start date on the dashboard as well as the end date on certain pages and the end date of the dashboard comparison range. Maintaining these parts in sync while also dealing with changes in the basic and advance modes is critical to a smooth UX.

Some learning from this exercise

• Changing existing code and best ways of going about it - This was my first major modification for OnTrack, studying existing code and planning changes for it required a lot of iterations and a lot of failing. Making changes required a lot of testing and communicating to understand existing features and making sure there are no side effects when changes are made.
• Best ways of going about changed in code are mostly non technical. Maintaining clear lines of communication is the most important part of developing as a team and an exercise like this really helps build those cords for communicating.
• Using MomentJs - Using MomentJs, a JavaScript library build to deal with dates and date based calculation is a blessing for manipulating dates, it might seem very trivial at first, but it has saved the OnTrack team tonnes of time calculating and requesting specific date ranges.
• ‘User’ Testing is the ‘moment of truth’ — in enterprise products we may not be able to do a AB-test, so frequent check-ins with the Product Manager is absolutely necessary to prevent heavy re-work

As with many things, this task felt seemingly easy at first, but grew and became a great learning experience for dealing with edge cases. The things that you learn from dealing with many boundary cases is that you learn to think like the end user, constantly trying to make the input that the user would make to break the application might sound frustrating, but it’s the opposite. You learn to think like the user you are building this application for, that helps us deliver a much smoother experience and ultimately a better product which is a win for all.