Date picker frustration

I don’t know if anyone else shares the same opinion as me, but I find a few things related to dealing with entering dates in SambaPOS frustrating, especially if using a touch screen.

Here are a few I noticed:

Reports

There is no date picker and therefore keyboard must be used to enter a date. Reports are normally used in situations where no keyboard would be connected so reliance of a keyboard is not ideal.

Ticket Lister

I find this date picker extremely frustrating to use on a touch screen (or even with a mouse for that fact). Changing up / down between values depends on either using the mouse wheel, which shouldn’t be assumed is available, or swiping up / down on the touch screen. Many resistive touch screens do not react well with swiping actions (in comparision to capacitive touch screens) and most dedicated POS touch screens are using resistive technology.

Also, selecting a date range is counter-productive - if I want to select all tickets from 3 May 2016 to 3 June 2016, my first step is to change the start date to 03/05/2016, however then the end date changes to be equal to the first, so I must then change the end date to 03/06/2016. I think it would be best if the end date didn’t change like this. Here is an example:

Account Details

Here we just get 2 blank boxes. It is not immediately noticeable to everyone these are for date input. There is no date picker and the date needs to be entered exactly in DD MM YYYY format (at least for me anyway) otherwise it isn’t accepted.

I also find the whole interface of selecting period, start and end dates on the account details screen quite frustrating because if I just want to simply enter a custom date range, I need to enter both dates and then I MUST move focus away from the end date field before I click Refresh (if I don’t, it ignores the end date and resets the dates entered).

Entity Screens

No date picker is shown to help entering dates. Again, like adding a new customer, this is likely to be entered using a touch screen.

I think possibly allowing us to specify if we want a custom field to have a date picker or not would be useful. Either via a specific Field Type or alternatively a Mask Type or Editing Format of Date field type. This would give the most flexibility here.

General

Many of the date fields, for me, expect a date to be entered in the format DD MM YYYY. I am unsure if this is partly due to regional settings, but the space separator is less common and if typing takes longer to enter (compared to / which would mean the whole date can be entered using the numeric keypad). I have also found users to be confused about entering a date like this.

Solution / Ideas

Would it be possible to have a consistent approach to date pickers that worked well with touch screens and didn’t require use of the keyboard to enter the date?

I suggest a calendar type date picker that has easy day selection and easy navigation between months and years. The font size probably just needs to be increased so it works ok with touch, but I’m sure there is a touch friendly component for .NET that can be used.

From a UI/UX perspective, it would be best to use the same consistent approach throughout the application as to how dates are entered and use the same date picker for all date fields.

It would also be good if text is entered into date fields that the field can intelligently work out what the user is entering. So instead of requiring 20 05 2016 it would accept 20052016 or 20/05/2016 (or other common separators like -, .) as same and auto format as necessary.

@emre

9 Likes

I agree and that’s why I use my own reports and automation for selecting dates and ranges. It also allows me to keep it all on a single screen.

2 Likes

^^^^^^^^^^^^
+1 to all of this

3 Likes

I agree with markjw suggestion that date picker should be Calendar style. and hope @emre should be think about it.

thanks

1 Like

Just so you are aware, this is an old topic and the date picker in ticket lister is already in calendar style now. But the others remain with no date picker.

2 Likes

I agree. I think i previously suggested something similar too

1 Like