Date Range Issues


#1

Hey all,

My company started a project a while back to redesign the reporting section of our tools that users were having issues with. Along the way, some assumptions were made to improve the functionality and interface and now we are having some internal debates figuring out what to proceed with.

One of the main issues that we are having internally is with the changes that we made to the date picker. Our original reports allowed the user to select their report range through two date pickers which are essentially the same as the jQuery date picker (https://jqueryui.com/datepicker/) except you cannot type in the dates; you have to click and select it from the calendar widget.

We updated this to one window (where the user clicks into one button, can see two calendars, has preset ranges and has the option to type the dates directly into input fields.

We’ve had a couple of internal comments that the new date picker is hard to use, but with no specific reasoning and we haven’t had any direct feedback on it from our beta users. We have done some user testing but our PO is saying that he doesn’t think it’s sufficient to warrant the changes so he’s wanting to revert them.

How would you go about getting stats that the changes have made an improvement to the user entry end? We do have stats that users are using the preset ranges, but in regards to the input date entry and the single date picker window.

Any advice or help is appreciated!


#2

hi @andrea_dyck

at the first glance, I was a little bit confused by the UI complexity of the date picker because, I guess, that:

  1. I have a default value for this control
  2. I can open the fly-out clicking on the calendar icon on the left
  3. In the fly-out, I have some links on the top (I don’t know if they’re links actually)
  4. I can select a value using the same component as a dropdown
  5. if I choose a custom range I will see the value in one single container
  6. If I am an advanced user I would try to write the value directly in the control

I listed 6 user interactions for a component within a web form.

I worked on a similar scenario with a date-picker in a complex web-form.
We did some A/B testing (qualitative) comparing different approaches and we discovered that for that specific task (booking an action for the stock market exchange) our users were more happy selecting a pre-defined value from date-pickers (eg next 30 days).
So we designed the date-picker in this way:

  1. as default status the date-picker is a dropdown with a list of pre-defined values
  2. clicking one of the pre-defined value the dropdown becomes a date-picker with two controls (from-to)
  3. as last value we delivered a “custom” option
  4. clicking the custom option the dropdown becomes a date-picker with two controls (from-to)
  5. once the dropdown is turned into a date-picker, users were able to type directly into the control with a client-side validation for the date format

Sorry, I was not able to find the mockup :frowning:


#3

Thanks for your feedback! :slight_smile:

We do know that from our saved and exported reports, only 20% of our users have selected a preset date range so I don’t know if completely the calendars and/or the inputs would be a good option, but I’m definitely seeing how the UI is too complex.

I’m trying to visualize how you built the date picker :stuck_out_tongue: . If I’m understanding this correctly, by default, there is only a dropdown which, on selection and in that same dropdown, displays two calendars, then the user can adjust as needed and then click Apply or off of it to close?


#4

Instead of two calendars, how about a single calendar icon, with two fields pre-selected with the current date.

Inline:
[Icon-Calendar] [06/05/2017] to [06/05/2017]

  1. Select first, date-picker opens.
  2. Select date to close
  3. Select end date-picker opens.
  4. Select date to close

or directly type in date,

  1. Select first date input field
  2. Type date
  3. Select end date input field
  4. Type date

Hope this helps a little.
-Jason


#5

I’m a bit confused I have to admit… what is year to date? What is month to date?
Just seems like alot of stuff.

Anyways my thoughts are this:
Remove the options for how to view calendar and just have monthly calendar (maybe have additional options in a dropdown if required?)
Remove the fields that have the start and end date. Only display the date when selected. Don’t make this selectable. And make it ‘Jan 1st, 2017 to Mar 28, 2017’


#6

I think that while others are trying to fix the UX/UI, the biggest problem to me seems to be that you’re making changes without enough data to back them up.

I can understand that your PO wants to revert the changes, but I’d hold tight for a bit until you’ve had a chance to do some research. A few routes to consider:

A/B Testing - with users who are familiar with the old design, the new design, and neither design.

Direct User Testing - Get some users to walk you through using the system to perform the date picking task in terms of a real-world scenario, asking them to go through what they like/don’t like about the tool. About 5 people usually gives you around 80% of your data.

Time to task completion. If you have the analytics capabilities to pull out the users who visited the page and actually completed the date picking task both before and after the change, you’ll have a good idea as to whether or not this actually speeding up the process.

Task abandonment (bounce rate). Again, this depends on your analytics capabilities, but if you have the means to look at how many users abandon the page without completing the task, you’ll have a basis for comparison to say whether or not the date picker positively or negatively impacts task completion.


#7

Thanks @dougcollins !

One of the issues, as you mentioned, is that it was built without getting or using any data. Going forward we are wanting to avoid doing the same thing so if we do find an issue based on testing, is there a way to test the impact of the solution without ‘trying’ / building each possible fix?


#8

hi @andrea2222
I fully agree with @dougcollins comment.
I suggest to follow a pragmatic approach and start to measure the UX KPIs for this widget.
I believe that Time to Accomplish the Task and Task Abandonment will give u a precise picture of the cognitive load for the users.

Anyway, I tried to rebuild a quick&dirty wireframe of the solution we implemented for our app.


#9

Thanks for doing up a wireframe of your solution! That makes it more clear.


#10

Thanks everyone! I really appreciate the help! :slight_smile:

@dopamino @dougcollins Unfortunately we don’t have in depth analytics in place - it is something that we are working on. I think that we’ll move forward with additional user testing with both the old and new date picker, measuring through those the task completion, success and error rates and I’ll also setup some calls to get users feedback directly.


#11

Hi, @andrea2222,

I think you’re on the right track using Time to Accomplish Task and Task Abandonment as @dougcollins suggested. As he also suggested, it will be helpful for your participants to use the date picker as part of a larger task flow, so they have an end in mind that’s more than just picking dates.

In my experience, you can get quality user feedback using mockups or wireframes like the ones that @dopamino posted above and that saves you both time and development resources. By all means, get the more detailed analytics, if you can, but in the meantime, put some sketches in front of actual users or potential users and get their feedback, too.

Hope this helps,
Katy


#12

Just stumbled across this