Poor usability for time entry

When I enter a time in a calendar appointment or task, the quickest way for me is to type in four-digit 24-hour time using the number pad on my keyboard. However, em Client doesn’t support this; I have to select each component of the time and change it individually. This feels slow, clunky and frustrating to use, since I’m used to more thoughtfully-designed software.

With the date input boxes in em Client, the user can type in the entire date string using the keyboard. With the times, the user can type in the hour and minute components, but he/she then has to press the Right Arrow key to go to the AM/PM part, and this wastes a lot of time. The dates also get date-picker UI controls. Why not treat times in the same way?

Another flaw with this design for both the date and time selection controls is users can’t copy and paste dates or times. In fact, the current implementation is so poor that users can’t even copy the components.

It’s important that user interfaces are efficiently accessible via keyboard while also being intuitive and efficient for mouse-only users. I suggest that time fields be implemented as text boxes with time parsing support and a pop-up time selection user interface.

Some time formats to consider are as follows. Examples are for the time “9:53pm”.
-The current time format in the user’s regional settings.
-9:53 PM
-9:53 pm
-09:53 pm

If you won’t do the above, I think em Client should, at a minimum, support typing times directly using the user’s regional settings’ time format. The current implementation doesn’t recognise this format and the AM/PM part is treated separately, which prevents typing the whole thing smoothly.

For the user interface part, here’s an example of how Lightning does it:

I second this. The current approach to entering time in eM leads to Mouse-Clicking Fatigue Syndrome (MCFS). (See your doctor if you experience numbness of the fingers, shortness of breath, elevated blood pressure or dizziness :wink:

There are two problems here: One is that it’s not a simple text field that you can type into , and two is those ridiculous “increment spinner” up/down arrows. They remind me of (although not nearly as bad as) setting an old digital bed-side alarm clock – where god help you if you have to set your alarm to 7:45 and it’s currently set to 7:00. Now you have to click that little minute button 45 times! hahaha…

I suggested this in another post. Consider changing all time fields in the program be a text field with a dropdown rather than a increment “spinner” field.

The program *already* asks you to set your preference for time granularity. So why not use this information? I currently use a calendar program that does this perfectly. The time granularity is set to 30 minutes by default, but you can change it to what ever works for you (5, 10, 15 mins, etc). Then when you encounter a time field, you can type in a value (and it intelligently parses it from practically any style or format that I type in!), I can copy and paste text from the field, AND there’s also a drop down if i’m feeling lazy and want to select a preset time. And these times are just a list of 24 hours divided by the time granularity I’ve already set. (See the screenshot)

One more thing, even though I use 24 hour, my calendar program will still let me type in “10 PM” in a time box, and it changes it to 22:00 immediately after I tab out of the box. Cool, huh!

In Outlook as well as in Google Calendar, I just very freely type in the time and hit tab to go to the next field. Outlook and Gmail then automatically “reformat” the time accordingly.

For example, to input “3:47 PM” as the start time, all I type is:

  • 347p

then I hit tab to get to the end time for the event.

Please please please implement a similar time-entry scheme in eM Client. Adding appointments to eM Client because of its time-consuming time-entry process is so painful right now.


This sounds very reasonable - we will consider it.


I think George said they will consider it.

that was 5 yrs ago…

And I guess they considered it because this thread was marked as Acknowledged. As you mentioned in your other thread, there is not much feedback on these proposals.