search

StanfordHCI / flash-teams

2 stars 0 forks source link

Maggie no tasks #259

Closed mgoulder closed 10 years ago

mgoulder commented 10 years ago

Fixed the bug where "You have no remaining tasks" never changes. Now, it should say in worker view whether the worker's upcoming task begins now, is delayed, is in progress, if they have no remaining tasks or if they've completed all their tasks.

Right now the minute counter is always 2 min off, but this should be an easy fix.

For testing, try a whole bunch of variations of teams and make sure that the minute counter and accompanying message in worker view is accurate. Do some early completes and delays and make sure this doesn't mess it up. The testing for this needs to be pretty thorough because I had to change the way some functions in events.js retrieved values from the JSON, which could affect other aspects of the application. Also pay close attention to the shading of the events because the bulk of my changes were in the drawShade function so that potentially could be a problem spot.

ato1120 commented 10 years ago

All of the cases are really weird when the team hasn't started. For example, if you are the first to go, but the team has NOT started, you are still told "your task starts now" which is a little terrifying. Similarly but less scary is the worker who starts in an hour. It's not really an hour if the team hasn't started... might just want to do a simple phrasing change?

screen shot 2014-07-28 at 4 40 08 pm

ato1120 commented 10 years ago

If your task is getting delayed, some freaky stuff happens to the next task. The timer oscillates between 1 and 2 minutes. (have a video you can reference, but can't upload to Git). Might want to switch to "your task will start as soon as the delayed task ends"

ato1120 commented 10 years ago

Also "your next task" vs. "your task.." might be better, but haven't thought through all of the cases for that. More subjective.

mgoulder commented 10 years ago

Fixed all the above issues! You'll notice that the clock still oscillates when a prior task is delayed, but this will be resolved in real time (ask Negar about this-- I think it has something to do with how often the team is updating. It updates many more times per minute in real time than it does in fast time).

I already did quite a bit of testing, but testing for this one needs to be pretty thorough so just try as many cases as you can-- multiple workers, ending tasks early/late, many different arrangements/intervals between events, etc.