DatePicker: Would a table or repeater be better for the month-at-a-glance view?

#1

Hi folks,
I’ve benefited from a lot of generous expert help and insights on this forum, to put my datepicker together.
I’ve got things working so it will always display your current month.

But I’m wondering if a seasoned Axure person would have built the month-at-a-glance view with a table or repeater instead 35-or-so widgets? If so, why?

I’m interested in making the clicking experience snappier, as my users seem to “deduct points” when my prototypes don’t give them the snappy experience they get from realworld datepickers. Regardless of how much I repeat “This is just a prototype.”

RP FILE: datePicker-widgeOrTableOrRepeater.rp (1.1 MB)

Screenshot:

Screen Shot 2018-04-29 at 4.26.06 PM.png1628×1274 127 KB

A secondary question is: I’d like to let the user tab out of the datepicker’s text field, and onto the next text field. But no matter where I apply onLostFocus and/or onKeyDown/ReturnKey, the text cursor refuses to move out and onto the adjacent text field.

Thanks in advance for the help!
-John

#2

I know it can be satisfying to build this sort of thing in Axure but, personally, I think you’re better off just changing the input type to date and letting the browser do the work. You end up with a datepicker that is localised in terms of format (dd/mm/yyyy vs mm/dd/yyyy, etc) and accessible as all the functions work using the keyboard.

Just my 2p worth

#3

Haha Yes it was satisfying to build, but I think I have a mild addiction. (I don’t know if anyone else runs into this.)

I was stunned for a few minutes after reading your suggestion (realizing that I spent days learning to build what was already built into browsers.)

Will definitely look into this once I get into the office. The only thing is we have a UI styleguide at work that stipulates the look and function of the date picker. So my labors may not have been comic-/tragically in vain.

Much appreciate your suggest!
-J

#4

Bear in mind that browser support for the date input type can by spotty so you may not want to completely rely on it for usability testing unless you can control what browser they’re using (remote versus in-person, for example).

https://caniuse.com/input-datetime

#5

Thanks for that resource link.

Most of my biz users/clients are on IE, EDGE, FF and CHROME, so without solid support acrosss these browsers, I’m gonna hafta keep my custom datepicker ticking.

Thanks again!

#6

Again: Any thoughts on whether a table or repeater would’ve been better suited than 6 rows of 7 text-widgets for the month’s dates?

#7

Yep. I think we’re all guilty of that. I think the prototype has to be completely faithful to the end product - at least as far as being able to recreate the journeys that need to be tested. Any deviation runs the risk of confusing the user, even if you can tell them to ignore it, and might affect the results.

My recent prototypes include a search mechanism that has predictive functionality with over 600 real records, and another form that has proper UK postcode lookup functionality for addresses to be picked automatically.

Personally, in your case, I think the repeater would probably be more appropriate. Without doing some real digging, I can’t say why. I generally work on the assumption that if I’m asking the question over whether a repeater would be better then the answer is usually ‘yes’.

Anyway, have fun with the build!

Cheers
Andy

#8

Thanks Andy.
For me it’s always a fine line to walk between good-enough, and knock-their-socks-off. Or I just need to get a life. :wink:

Any chance you might share a bit or some tips on that search mechanism or post look-up? I’m trying to get into js injections and I’m wondering if you’re doing some of that?

Thanks.

unlisted #9