Date Time Picker Paper Prototype User Testing - Round 2 Results
Summary
- 4 of 5 realized they could type or use the mouse to pick a date and time. One user didn't think to type at all, since the calendar popped up right away.
- 5 of 5 knew they could just click outside the calendar or time picker to close it
- 4 of 5 of the users commented that the time picker was intuitive or very straight-forward or (even) pleasing
- 2 of 5 users wanted to be able to enter fewer things in the time picker when it had no defaults (e.g. it should assume :00 or PM)
- 3 of 5 users thought Accept Until Date should change to at least match Due Date
- 3 of 5 users clicked on the calendar icon when it was available. They didn't feel the icon was necessary, as long as the calendar pops up when they click inside the field.
- 2 of 5 users preferred the combined date and time picker to the separated picker.
Demographics
User Number |
Location |
Gender |
Age |
Role |
Tech-savvy |
Do you own a personal computer? |
---|---|---|---|---|---|---|
User 1 (EK) |
Berkeley |
Male |
41-50 |
Staff |
Medium-high |
Yes, Mac & PC |
User 2 (BW) |
Berkeley |
Male |
35-40 |
Student |
Medium |
Yes, MacBook Pro |
User 3 (TA) |
Toronto |
Male |
19-24 |
Student |
Medium |
Yes, Windows Laptop |
User 4 (JL) |
Toronto |
Male |
31-35 |
Staff (researcher) |
Medium |
Yes, Windows Laptop |
User 5 (LH) |
Berkeley |
Female |
51-60 |
Faculty |
Medium-Low |
Yes, Mac Power PC Laptop |
Do you do any of the following and if so how often?
User |
Checking email |
Instant message |
Shop online |
Online banking |
Internet research |
Take class online |
Social networking |
---|---|---|---|---|---|---|---|
User 1 |
All the time |
Hardly Ever |
All the time |
A few times a week |
Never |
A few times a month |
A few times a month |
User 2 |
All the time |
A few times a week |
A few times a week |
All the time |
All the time |
Hardly Ever |
A few times a week |
User 3 |
All the time |
Hardly Ever |
Hardly Ever |
A few times a week |
All the time |
Never |
A few times a week |
User 4 |
All the time |
All the time |
A few times a month |
A few times a week |
A few times a week |
A few times a month |
A few times a week |
User 5 |
All the time |
Never |
A few times a week |
A few times a month |
A few tunes a week |
Never |
All the time |
Do you upload files on the web and if so how often?
User |
Pictures |
Media |
Docs to course site |
Docs to soc. ntwkg |
File to email |
---|---|---|---|---|---|
User 1 |
A few times a month |
A few times a week |
A few times a week |
Hardly Ever |
All the time |
User 2 |
A few times a week |
Hardly Ever |
A few times a month |
A few times a week |
A few times a week |
User 3 |
n/a |
n/a |
n/a |
n/a |
n/a |
User 4 |
n/a |
n/a |
n/a |
n/a |
n/a |
User 5 |
Hardly Ever |
Hardly Ever |
A few times a week |
Never |
A few times a week |
Interaction Notes
User |
Scenario 1 - Enter an Assignment into Learning Management system. (separate date & time picker with default date and time) |
Scenario 2 - Enter Course Modules into Learning Management System (combined date & time picker with no default date or time) |
Post-test questions (if recorded separately) |
---|---|---|---|
User 1 |
|
|
|
User 2 |
|
|
|
User 3 |
|
|
|
User 4 |
|
|
|
User 5 |
|
|
|
High-level summaries/findings by user
#1
- Is a combined date-time field better? Should design pattern recommend a combined date-time field because it is more efficient for users and requires only one required field label instead of two (if date & time are both required)?
- Consider using contexts people aren't familiar with for user testing of components so they don't get caught up in details about the apps we aren't trying to test.
- would like the time to default to :00 - he says he'd understand he could change it
- is the yellow highlight even needed? He didn't notice that the highlight changed. Is the gray background too inactive looking?
- should the active tab be white instead of gray?
- he's annoyed at applications that just put in the current time (e.g. 4:12) - make sure to recommend good defaults and remember that context matters in terms of how this would work
- said the time-picker was very straight-forward
- he said he's a typer (instead of a clicker--but he actually did all clicking except for the :59), and would tab between fields
- suggested having noon and midnight in parentheses
#2
- Thinks the 5 minute increments are very natural - his Palm won't even let him do anything else
- Would skip entering PM because he'd hope it would be filled in (this was when there were defaults and it was already filled in)
- He suggests that accept until date should be automatically set to not be sooner than due date after due date is set (because that wouldn't make sense).
- He would like to use the 10 key number pad which has no colon, so he'd like to be able to type the time without a colon
- He would like the system to recognize/parse any date format
- he wanted styling of the dates on the pop-up calendar to tell him when there are two different events on the same day - suggested a border. When asked, he also commented that there was no color key to tell him what the colors meant.
- he didn't see the close "X" but says he'd click outside the box to close it
- noticed both the >> and the months drop-down, and when scrolling to the very next month he wanted to use >>
- at first thought the gray box representing the selected date should remain when he switched the calendar to a new year, then changed his mind.
#3
- Would click on the calendar icon
- There should be more an option in the "time slot" where you can pick either 24 or 12 hr clock
- Recognized the different treatments for today's date and previously selected date
- When presented with date/time separate (without calendar icon), the user was confused and didn't know how to open the calendar
- Calendar appeared when the user clicked on the field. User commented that both of the designs should have the calendar icons or both not have them. He would be okay without the calendar icons, if the calendar just popped up as soon as he clicked on the field. "The only reason I clicked on it was because it was there."
- Preferred the date and time pickers combined in one field. With the separate fields, he assumed it would "take me to the time thing" when he finished picking the date. When he saw that the calendar just closed and did not take him to the time field, he was disappointed. "I guess it's not automated"
- When asked to pick 11:59, he commented "there is no option for 59. I would probably pick 55." He thought 59 was "too specific"
- He prefers to use the mouse than to type. "If it gives me [fluid:the date and time picker] as soon as I click, I'm more inclined to pick than to type."
#4
- Was presented with the design with date and time in separate fields first
- Would type inside the date field. Would be "super frustrated" without the example. Would type it in the format suggested by the example. Would've expected to type in digits for the months.
- User is told the calendar pops up right when he clicks inside the field. He would click the date instead of typing, since it's already presented to him.
- Would then click on the time field, and pick the hour, minute (00), and AM.
- Would do the same (picking using mouse) for the rest.
#5
- users says she would type but may type or click depending on efficiency of interaction
- the date picker is consistent - it's a known metaphor that she's familiar with from sites like Travelocity
- user had an injury to her thumb which made her not want to click - she now wants to type as much as she can
- thinks she would be prepared with modules' dates before going to Sakai, and would just want to enter (not analyze) them. She does think she may find the ability to see visually how far apart dates are helpful though.
- she liked that the calendar display would change based on what she's typing. She says,'that's comforting.'
- thinks it would be very helpful to drag the calendar
- one possible feature: connected date pickers remember the month you were on and use it to figure out where to start the next date picker (this helps with entering a lot of related dates - e.g. for the semester - prior to when they occur)
- she was able to figure out what the aqua border on a day meant when she say the color mapping to "Today is" at the bottom of the calendar. It might have been easier for her to figure it out though if she really knew what today was (we didn't say in the scenario).
Post-test Questionnaire Responses
User |
Selecting a date |
Selecting a time |
Recognizing option groups in time picker |
Recognizing selected dates and times |
Tabs |
Changing previously selected date |
---|---|---|---|---|---|---|
User 1 |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
User 2 |
Easy |
Very easy |
Very easy |
Easy |
Easy |
Easy |
User 3 |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
Easy |
User 4 |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
User 5 |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
Very easy |
Potential Design Improvements (based on testing)
- Make whether or not a calendar icon appears a config option. The default is to not have the icon. When a calendar does appear, it should be inside the text field and toggle the calendar open & closed like the one on Kayak.com.
- Change prototype/storyboard so that dates which cannot be selected are gray. Use same or similar gray for numbers in the previous month, but don't show a mouseover highlight because it isn't clickable.
- Add "noon" or "midnight" above the text field when it is 12am/pm.
- Remove yellow highlight from time picker except when it's empty. Ask for feedback from design team whether it should be removed when it's empty as well if it makes users think they have to fill in every piece when they really don't.
- Remove close X.
- Allow defaulting to :00 if the user only types, e.g., "5pm" or picks 5 and PM.
- Change the active tab to white instead of gray so it looks more connected to the content area. Inactive tab should be changed to a flat gray.
- Ensure that date/time picker updates with as things are changed in the text field and vice versa.
- Add a configuration option as to whether date picker only goes forward in years in drop down or whether it can go into past as well - erin to spec out how this would work
- Date picker should be "smart" and change dates in other related fields (e.g. Due On should be = or before Accept Until).
- Consider a feature where implementers can connect date pickers in an app, so they remember the month you were on last and use it to figure out where to start the next date picker.
- If user testing is done in the future, test adding the border back when two fields have the same date to indicate this.
- Design pattern:
- Ensure important information isn't hidden when the date picker pops up
- recommend good defaults, and remember that context matters in terms of how this would work
- recommend when to use a combined date-time field – often better because it is more efficient for users as they don't have to move from a date to a time field, it's simpler, and requires only one required field label instead of two (if date & time are both required). A reason to separate them would be if date or time is required and the other isn't.
- talk about when calendar toggle should appear in the text field
- Consider using contexts people aren't familiar with for user testing of components so they don't get caught up in details about the apps we aren't trying to test.