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.

  • Unfortunately, giving them an application built to less flexible workflows is not a viable option. Sep 29, 2011 at 16:54

5 Answers 5


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).

  • Workers can set availability for up to ten weeks. Walking them through every entry they produced would, I think, be arduous. Sep 30, 2011 at 7:53
  • @Jimmy: at first yet, but once the pattern thing is in place you would only have to walk them through the exceptions to that pattern. Sep 30, 2011 at 10:13

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.

  • We already plan to separate the recurring and ad-hoc panes, and yes, changes to ad-hoc availability don't effect general availability. As for colours, that seems awkward. We will have to produce a key, which I doubt users will read. We will also have to have a way of visually handling two sets of availability and manage the behaviour of overlapping availability spans. I think that would over-complicate things. Sep 29, 2011 at 17:01
  • That said, the idea of only applying availability to weeks the user hasn't changed isn't a bad one. But will the behaviour be clear to the user? And what if the user makes and edit and rescinds it later? Are we to assume that's fair game for changing? Sep 29, 2011 at 17:07
  • 1
    As for colours, I mean more of an opaque grey overlay. Just something that looks a little different. Test and see. Basically if the user changes something then they override their default availability (whether it is available or not).
    – JohnGB
    Sep 29, 2011 at 18:10
  • That basic behaviour - overriding general availability with ad-hoc entries - is something we've already chosen to do. The question is: what happens to the user's 'customized' availability after they change their 'general pattern'? Sep 30, 2011 at 4:23

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.

  • 2
    Make sure to give them the ability to undo! :-)
    – Evan
    Sep 29, 2011 at 17:43

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.
  • The dragging behaviour already exists in the current interface. We have considered multiple colours, but feel it would force us to add a key, which would make things clunkier. We have considered using chroma to indicate 'transient' data, but again feel there's a lot of room for misinterpretation. Also, I think the click model of no availability -> permanent availability -> transient availability doesn't make sense. You'd expect the more static availability to require more clicks. Sep 30, 2011 at 7:51
  • Generally, I think the idea of managing general availability in each specific week's view is an odd one. But thanks for the answer anyway. Sep 30, 2011 at 7:55
  • Also, at application level, we don't separate general availability from specific overrides. We don't have the development resources to implement a different model - only to build auto-population of the existing 'ad-hoc' diary. Sep 30, 2011 at 7:58

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.

  • This was an obscure project two years ago for a piece of software that no longer exists at a company I no longer work for. It's probably a little late for this advice. Sep 7, 2013 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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