PTO is measured in hours on your paycheck, and people often take it in hours (2 hour off to go the dentist, half a day off for something or other, etc). There's no provision for this on the current app. My suggestion for UI: Leave the entry form initially looking how it is now. Once both the start and end dates are entered, add a link/button for "enter partial days". When that link is clicked, expand the form to list each day individually with a number of hours next to each day, defaulting to 8 on each one. If you want to get fancy, put up and down arrows to click to increment/decrement them. But I'm not a UI design expert, so feel free to do something different. :)
Please try the time picker out at: http://kourge.khan.mozilla.org/pto/ Bonus points for breaking the time picker. No candies for usability issues :P
I can't see that test page on Khan ATM (no VPN), but I think the UI described in comment 0 is overkill. Down-to-the-hour precision for PTO sounds like an edge case to me, and if people really want it I think they should just mention it in the "reason" field (or a separate "notes" field that only gets sent to karen/erica).
I think what he has works pretty well: http://www.grabup.com/uploads/d6231d45a04870a10549664667c0f2c2.png
Note that the 95% case is covered since nobody has to fill in the 00:00 hour fields if they don't want to.
except that they're automatically filled in and that makes it confusing about whether it's counting to midnight or not (so I'd end up picking the day after instead to include the previous day?). That's even more complicated than what I was suggesting I think. However, this sounds much simpler and probably better anyway: < kourge> afaik, what Karen really needs to know is the total number of hours < kourge> so you have three fields < kourge> one, total number of hours, required < kourge> two, starting date, optional < kourge> three, ending date, optional
Sure, that works for me.
Although, the start and end should not be optional unless the hours are < 8. Part of what we'll do with this in the future is being able to see -- at a glance -- who is on PTO that day (a replacement for the email@example.com emails). That won't mean much without the date range.
Side note: If you do 24hr-time (or "military time", as you Americans so affectionately dub it), there's little need for the distinction am/pm. So I suggest either going for am/pm but using 12hr notation, or going for 24hr altogether (which all internationals are likely to prefer) and dropping the am/pm.
The reason for the lingering am/pm distinction even with a 24hr format is stated by the author to be a usability fix. Since strtotime() handles am/pm just fine, I've switched over to the 12hr format.
I talked to Karen about our models of PTO entries, which are abridged and recapped below: - The current model has a rigid sense of starting timestamps and ending timestamps. The timestamps incorporate the date and now the time. - Dave's mockup indicate that each day can have different numbers of hours. This will require the schema to base PTO entries on days, not time periods. Since each day is a row, there would be no need for starting or ending timestamps. - My revised model is that each PTO entry is still based on time periods. But the main important data about each entry is the total number of hours taken for PTO. Starting and ending dates still exist to aid an overview of who's out today or who's out this week. Karen said that the most important part is to know how many hours are taken off the payroll, so the last, revised model is the most ideal. Thoughts?
Ok, so make the hours field manual and have people pick a simple date range (by day, and leave the times in) so if we need to pull a quick status list it's still possible. The date range shouldn't be tied to hourly calculation -- we can leave that up to people. I have a problem with "Since each day is a row, there would be no need for starting or ending timestamps." if it means people have to enter in things more than once for multi-day PTO.
PTOs are now centered around the number of hours at r30609. Test it at http://kourge.khan.mozilla.org/pto/ as usual.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.