Time entry that doesn't allow overlaps

Question

I'm working on a time entry form for a project management app. The time entries entered represent real tasks done, so they cannot be allowed to overlap. Currently, we accomplish this by simply displaying an error if the entered time overlaps with another time entry for that person.

I'd like to redesign it so that the control for entering time will show you what "slots" are available for the given date, to eliminate the "try it and see" workflow we currently have.

The control should also enable a user to adjust existing time entries, in case they have been entered incorrectly (a common occurrence with some of our users). I have come up with a rough concept. (Link because I don't have enough rep to post images)

It represents a timeline. The blue lines represent existing time entries, that could be adjusted using the handles on each end, probably with feedback on drag. The green and red lines represent a new time entry is added. The green one is in an empty slot, so it is all good. The red one overlaps, so the color reflects that.

My concern is that this may be too complex for the average user to work out. Are there any other similar interfaces I could reference? Does anybody have any experience with an interface like this?

Answer 1

I saw this link on Dribbble.com that looks similar in the look and feel. My initial reaction is that depending on the average number of different time entries, the best thing is to go with a more flexible approach that separates the two parts of the interface. The first part is to show the overall timeline, and the second part is to allow users to provide input. This can be as simple as adding a button which provides a new slider for users to select the time period, and then saving the value so that it is updated on the summary. Depending on whether you want to validate the input or not at the input level (as opposed to the page submission level), you can use the colour coding to show different states as you proposed.

Answer 2

Try to go visual, like in Google Calendar. Users should see from the very beginning what time is and what is nat available. Seeing it is better than reading it, so it will be best to visually represent it. Also, from this point of view it will be easier for users to just select some free time available and create an event inside of it.

You will also need to use temporary time reservation. Let's assume that two users create a time entry in the same moment. Once they finish, it may turn out that the time they wanted to use is busy already, because someone was faster and did it a second ago. Quite disturbing. They need to be completely sure that if they create an entry in a free slot, it's granted for them to have this slot.

Temporary reservation should expire, however, because some users can start creating a task and then go for a caffeine shot or a long meeting. Depending on complexity of task creation (be it the system they work in or any procedures around this process) you can use from 5 minutes to, say, half an hour?

This leads to a conclusion that time should also be reserved at the very beginning of task creation process, to avoid user invest their time for filling in the description etc. and then, while they select the time, finding out that the time span they wanted to use is already used by someone.

So, just to summarize, the idea is to:

• show users the timeline(s) visually
• allow them to (also visually) select free slot from this timeline
• then let them click "create a task"
• while they create the task, the time slot is temporarily locked, not to allow someone else use the same slot (so that neither the first nor the other user gets confused)
• if user does not create the task, the reservation expires after a timeout (depending on overall complexity of creating the task)

Adjusting can be dealt with by simply dragging the task borders (start and end time) in the timeline view, and so can be done dragging to another time slot if there is a need to reschedule or there is not enough time to use to expand the task, and it is necessary to do so. In this case, the system should first lock the new time slot, and then release the old one.