Behaviour of a user diary with both general patterns and specific entries

Question

I'm working on an application that allows users to keep a 'diary' of times they are available to work. The interface is very simple, and deals purely with ad-hoc availability. It's effectively a timetable grid, with cells as hours of time per date. The user can switch the available / unavailable state of an hour just by clicking it, which changes the colour. This is an interface the product has had for around six years, and has around fifteen thousand users, so we're loathe to alter it.

However, there's one major issue: users don't have recurring availability patterns, so they have to enter their availability for each week on a regular basis. We're pushing functionality that allows these users to record a general pattern of 'default' availability, but still record variations in individual weeks.

For example, Sally might be available to do part-time work every day from 10am until 3pm. Her 'default' availability for each week is 10-3 each day. But next Thursday, she knows she'll have a doctor's appointment, so she wants to remove the availability for that day. Our functionality will allow that.

The question is, how should the application behave when the user edits their day-to-day availability, then changes their general pattern? Should the changed pattern override any specific settings to individual weeks? If not, how do we gracefully mark the difference between generic and specific availability, so that the user doesn't see identical-looking availability spans act in completely different ways? If we treat user-entered availability differently to machine-created availability, what happens when a user clears some machine-generated time from their diary only to relent and re-enter it? How would we make that behaviour easy to understand? Should we just tell the user that changing their availability pattern will override everything, possibly asking if there's a date they'd like to apply changes from?

In practice, we think users will rarely change their availability. A large body of our customers are social care agencies that contract their workers to work agreed weekly patterns of workable time, with them adding extra available sessions as they see fit / find overtime attractive. These patterns might change only a few times a year.

Answer 1

The question is, how should the application behave when the user edits their day-to-day availability, then changes their general pattern? Should the changed pattern override any specific settings to individual weeks?

That is what I have found most calendar/diary applications do.

For example GMail's calendar will let you make changes to individual instances of a series (recurring pattern), but when you change the series as a whole, it warns you that individual changes will be lost.

You could of course be a bit more flexible and show the (future) exceptions with the warning and allow each of them to be kept or discarded. You may have to do some user interviews/testing or statistical analysis to figure out what the best default for keeping / discarding may be. The number of "exceptions against the pattern" may also be a trigger to select either keep all/discard all as the default.

If you really want to be kind, show the exceptions against a (more lightly coloured than normal) background of the new pattern, allow each to be kept/discarded individually and provide a keep/discard all remaining exceptions (for which no specific decision was made).

Answer 2

Why not have something like a "recurring availability" view, which looks just like a single week view in the regular app. I can set that, and it will automatically apply itself to all days going forward that haven't manually been changed.

That way anything I set manually in the normal view will override for the time I am changing, but won't change the general pattern. You could even show times from the "recurring availability" as a slightly different shade or some other visual cue.

That way you only need a link on the normal schedule to set this pattern, and you don't complicate the interface that your customers are used to.

Answer 3

Perhaps allow the user to save a particular week's configuration as a template. Then, allow them to apply that template to any other week.

What happens to hours that conflict with a template applied to them? I think you can safely assume that your template should not override specific changes the user has already made for that week. Perhaps immediately before or after applying a template you might ask the user if they want to allow the template to override their existing changes.

Answer 4

Conceptually, you seperate "default availability" from "specific override". Why don't seperate it visually as well?

Now, clicking on a default value would set it to the opposite color, but darker (specific). Clicking again would:

• remove the specific override? or
• do an override in the same color as the default one?

Hm. Maybe ask the user what he would expect, showing him such an sketch as "paper prototype".

EDIT: Another idea: maybe allow "dragging":

1. I'm clicking on a green rectangle, so it changes the color to red.
2. Leaving the mouse clicked, and moving it into other rectangles, will not invert each color, but color them red as well.

Answer 5

I cannot help myself: The suggestion of colour coding or using different shading to denote variations is a really, Really, REALLY horrible suggestion. I am one of the 28% of people, (nearly 100% males), who are colour blind. I am Red/Green and Blue/Green so unless you use bright primary colours any efforts at shading or subtlety using colours is entirely lost on me and anyone else who may be colour blind. I do not say don't use colouring techniques but you MUST use other visual clues as well, please.