First reactions: tab field-switching and/or JS execution order. Time is on top, so I'll input that first, then want to set the TZ. Tab goes time1->time2->tz1->tz2, which is unintuitive to me at least. In addition, filling in the dominant origin field first (time) is counter-productive as changing the TZ afterwards then auto-modifies the origin time - clearly not as I intended. This absolutely makes sense from a programmatic reload-free page outlook upon reflection, but not at all going purely on intuitive UI use.
Thanks for giving it a close look. I debated these points and came up with arguments on both sides of how updating should work.
I agree more with your tab ordering point. As far as JS execution (deciding which time to update when city changes) I saw arguments both ways and in the end decided to copy the behavior of a unit conversion dashboard widget from Apple. Not a good reason but it served as my starting point.
Comments
First reactions: tab field-switching and/or JS execution order. Time is on top, so I'll input that first, then want to set the TZ. Tab goes time1->time2->tz1->tz2, which is unintuitive to me at least. In addition, filling in the dominant origin field first (time) is counter-productive as changing the TZ afterwards then auto-modifies the origin time - clearly not as I intended. This absolutely makes sense from a programmatic reload-free page outlook upon reflection, but not at all going purely on intuitive UI use.
Thanks for giving it a close look. I debated these points and came up with arguments on both sides of how updating should work.
I agree more with your tab ordering point. As far as JS execution (deciding which time to update when city changes) I saw arguments both ways and in the end decided to copy the behavior of a unit conversion dashboard widget from Apple. Not a good reason but it served as my starting point.