Skip to main content
Tweeted twitter.com/#!/StackUX/status/120121362084925440
edited tags
Link
Patrick McElhaney
  • 14.2k
  • 9
  • 51
  • 68
added 242 characters in body
Source Link
Jimmy Breck-McKye
  • 17.4k
  • 1
  • 49
  • 71

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

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

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.

Source Link
Jimmy Breck-McKye
  • 17.4k
  • 1
  • 49
  • 71

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

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