3

What is the most efficient way for users to enter a hh:mm time in a web interface and a mobile interface? In this case users would be entering time more than 40 x per hour.

Context: This is for scheduling and task tracking. A manager will create weekly schedules for 100s of employees. They will enter in and out times for employees. Task tracking will involve daily task completion with time and reassignment with due date/time.

  • 4
    Sounds horrendous, what's the use case? – DarrylGodden Apr 27 '15 at 14:55
  • More information about the use case would be helpful, this is one problem but i don't think its the only problem with the system. And maybe solving a bigger problem can ease this one. – Frank Visaggio Apr 27 '15 at 15:05
  • We need a whole lot more information here. What kind of time? What's the context? Is this a time sheet? Multiple time entries at a time or just one? What are they accessing 40 times an hour? – DA01 Apr 27 '15 at 15:39
  • This is for scheduling and task tracking. A manager will create weekly schedules for 100s of employees. They will enter in and out times for employees. Task Tracking will involve daily task completion with time and reassignment with due date/time. – stephenz Apr 27 '15 at 16:09
  • Is it more efficient to enter time on a keyboard and tab thru the fields or use some kind of a time picker (or both) on the web on a desktop? Is a time picker more efficient on mobile? In both cases I am talking about a web app (in a browser) and not a native mobile app. – stephenz Apr 27 '15 at 16:18
3

You are describing a use case for an expert interface

  • Expert interfaces are specialized to accomplish a particular task effectively. The UX trades off intuitiveness in favor of productivity/accuracy/speed.

  • Here's an example of an expert interface, a stock trading keyboard:

    enter image description here

Unfortunately, expert interfaces are so specialized that they aren't very well suited for Q&A type sites.

You have to provide a lot more information (for example, are you willing to sacrifice learnability in favor of speed? do you have the budget to develop a custom tablet or mobile keyboard for the data entry?).

Here are some approaches (they also show the performance-cost tradeoff)...


Desktop

  • Require users to have a number pad on their desktop, and allow all fields to be completed via number pad (checkout counters at supermarkets adopt this approach for speed and accuracy).
    • e.g. allow times to be entered using the 0 to 9 keys, the + key toggles AM/PM, and Enter moves onto the next field.
  • Use a masked input field to avoid users needing to type the : character.
  • Automatically move to the next field when user presses Enter or Tab, and autocomplete the field to :00 (the most common minutes format).
    • You may also want to repurpose a button like Tab to cycle through 00, 15, 30, 45 for rapid entry. Expert interface designers often sacrifice default key behavior in favor of speed.
  • Accept both 12- and 24- hour times. Autoconvert 24-hour inputs into 12-hour am/pm.

Tablet/Mobile

  • Use some of the desktop approaches above, plus...
  • Develop a custom keyboard to speed up entry, for example:

keyboard

  • Allow quick drag and drop to copy times:

    enter image description here


Hopefully these examples will illustrate that there are significant cost/learnability tradeoffs to consider, so only you can decide what combination of approach fits your budget/performance/learnability requirements.

| improve this answer | |
  • Thanks. I'm trying to convince people I work with that various graphic timepickers aren't efficient. I haven't seen manual entry combined with a timepicker working well. I was thinking manual entry for web and a timepicker for mobile. Tabbing on mobile keyboards is not well understood. – stephenz Apr 27 '15 at 22:12
  • Graphic timepickers can be more learnable for infrequent entry, but for rapid entry it's very hard to beat performance from a keyboard! Google's Android Calendar has a time widget that attempts to balance graphical vs keyboard input, but a pure keyboard input will still outperform this for multiple, fast entries – tohster Apr 27 '15 at 22:15
2

Use HTML type="tel". Read about it here

The Idea is to have something like this setup _ : _

So the amount of keypress/touches will be 4, ex. 12:45. I would try to make them go with always using 24-hours, to save space and bring some kind of consistency into it. Presets as mentioned @tohster is a good idea, like :15, :30 and :45 on buttons to save a press.

Note about presets: It highly depends on if they are doing mixed numbers all the time, it dosen't make sense to use the UI space for presets.

enter image description here

| improve this answer | |
  • iOS has tabs above keyboard (forward and back carets). Android has Next button in keyboard (no back) This is somewhat similar to desktop. I'm not sure how well tab is understood on mobile. When I talk to mobile users about tab majority is not aware of it. On mobile having to move back and forth between keyboard and form is slower than using some types of time pickers. – stephenz Apr 28 '15 at 14:39
0

I would first look at the workflows and possibly see if you can eliminate them entering the time so often. For example if a bunch of tasks come in at around the same time is it possible to group them all together under the same time?

Other things you can do to possibly make entering the time less troublesome.

  • Try to predict the time range they are going to enter. If the average time entered that day is roughly 45 mins out set that to the default value, if in the afternoon it changes to 15 minutes in the future change the defualt. Whatever you can do it make it a bit easier for them.
  • I would also use preformed chunks if you can get away with it ie (15 minute intervals so they have less clicks or less data to enter. Do you really need to be that precise with the time?

Lastly cant you get the time for them? Time.Now or some api call? its 2015 is it possible to find a time function or call an existing function to derive the time for them (or maybe put a button on their mobile device saying log time) that it saves the time of the event so they dont actually have to enter the time.

However in short by them entering the time 40 times an hour it seems like there may be a larger UX smell in this system.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.