0

Should we update the logic for how task dates are calculated? Need client feedback.

Don Parker

April 17, 2009 06:52

None

Follow

Currently, the "start", "end", and "duration" fields on tasks have some logic built in to update each other where possible.  Here is the current logic:

 

- If "duration" is empty, and both "start" or "end" are filled in, calculate the "duration".
- If "duration" is updated, and one of either "start" or "end" is blank, then calculate for the blank field.
- If "duration" is updated, and both "start" and "end" are filled in, update the "end" date.
- If "start" is updated, and both "end" and "duration" are filled in, update the "end" date.
- If "end" is updated, and both "start" and "duration" are filled in, update the "duration" field.

 

We just received this feedback from one client:

 

So, now that this has been in place and settled a bit, I think it’s turning out that one of these cases isn’t giving us the desired/expected behavior.  Mainly these two:
 
- If "start" is updated, and both "end" and "duration" are filled in, update the "end" date.
- If "end" is updated, and both "start" and "duration" are filled in, update the "duration" field.
 
I think it would be better if both of these cases were the same, and each updated the “duration.”  We’re finding that it’s misleading to people when the two cases have different behavior.

 

This suggestion means we'd update the logic like this:

- If "start" is updated, and both "end" and "duration" are filled in, update the "duration" field.
- If "end" is updated, and both "start" and "duration" are filled in, update the "duration" field.

 

We'd like to get more client feedback before we make this change.  It does seem to make sense for the behavior to work the same in both cases (updating duration), but I tend to push schedules back by updating the start date (so a change to the duration would confuse me for a while).

What do you all think?

• Facebook
• Twitter
• LinkedIn

5 comments

• 0
  
  Andy Geers April 17, 2009 08:15

  Can I clarify - is this just for the API? Or the user interface somehow?

• 0
  
  Don Parker April 17, 2009 10:02

  Hi Andy,  I'm talking about through the interface.

• 0
  
  Andy Geers April 17, 2009 11:35

  Does this mean that internally, the start date, end date or duration might be empty, even though a (calculated) value is displayed in the user interface? I think I fed back to you guys a few weeks ago that our producers were pretty much treating the duration of a task as sacred, so were expecting that moving either the start date OR end date would always update the complementary date field and leave the duration untouched. So they would agree that the current inconsistency is bad, but I think would consider it even badder if both start and end dates now caused a change of duration.

   

  The context where they particular care about this issue is when doing a multiple edit on a bunch of tasks. They might well want to shift a whole bunch of tasks to match a change in delivery deadline, and all those tasks might be of different durations. All they know is that now the due date is three weeks later than it used to be. At the moment if they update all of the end dates, the start dates stay fixed and the durations are extended. They couldn't set the start dates in a multiple edit because the varying durations mean they should all have different start dates.

  
  Maybe in the context of a multiple edit you could display radio buttons that explicity tell Shotgun what to change and what to leave constant?

• 0
  
  Mike Romey April 21, 2009 17:16

  Well, the big issue on our end is the duration.  The duration of a task is a reflection of the bid and the time associated with that task.  Prior to starting a project we do a calibration of the bid to our tasks.  We call this "day one actuals".  Once that is approved, artist bill to those task and use the duration to calculate our over/under.  So from our perspective I would use caution updating the duration in any way that manipulates the duration in a way that reflects a different value, hence manipulating the bid and eventually manipulating the over/under costs associated with that bid.  So I would assume your propesd fix would mean that we would want to generally tell our producers to slide the gannt to mantain the duration and not necessarily manipulate the start and end time.  Keep in mind up until recently per a request we made when you slide the gannt it didn't properly maintain the duration when dealing with sub day amounts.  Honestly I feel like the whole gannting system really needs an update and refresh to support important scheduling shortfalls and this should be a very important priority.

  -Romey

• 0
  
  Joe Frayne September 11, 2009 17:57

  I'm not sure how current this discussion is now, but it seems to me that there is some confusion about terminology here. The task has a "bid" and a "duration", which we understand to mean two different things. The "bid" to us what is sacred -- this is how many days of work the artist is expected to spend on the task, as defined at the beginning of the project, and it is never updated. The start and end dates can change, however, and in between those dates an artist may or may not spend all of that time working on the task. The "duration" is simply the number of days between the start and end dates, which must change when the difference between the dates change.

  I think the way Shotgun behaves right now, which is the same as Don described above, is the way we want it. Don probably should have mentioned that the "bid" is unaffected by any changes to the dates or the duration.

  One related thing that has been brought up here, however, as a point of confusion, is that Time Logs have a "duration" field, which really has a different meaning than the task's "duration". We suggest changing that field's name to something more clear, such as "Time" or "Work" or "Time Worked".

  Joe