Consistent time recording - either 0.5 for half an hour or 0.30 but not both !
complete
*
* Verity Whitmore
Please make time recording consistent as currently on activity cards its recorded in mins and on timesheets it's via decimal - very confusing
Log In
M
Mark Zahorik
Yeah! small change, but big impact.
Kelley Bunge
complete
John Furneaux
in progress
E
Erica Schneckendorf
John Furneaux: Hi John, wanted to check in to confirm how this update will be rolled out, will it be HH:MM or by the quarter of the hour (.25, .5, .75)?
John Furneaux
Erica Schneckendorf: HH:MM is coming as a consistent entry mechanism, both that and decimal will be available in any outputs.
John Furneaux
Hi all! Keen to make an improvement here, I just want to make sure we get it right. Please bear with me if I say something you think is stupid!
So from my own personal experience of filling in my own timesheet in previous companies, it was always a decimal entry, because we were all thinking in terms of total hours... so I'd submit like 8.5 and that felt very natural.
On the other hand, if I'm logging time to a specific card, it's quite possible that it was a small job, and I want to log 20 minutes. I personally would find it much more natural to log 20 minutes than to mentally calculate that it's 0.33 of an hour.
On the flip side, our hours 'output' (in exports or tables) should 100% be consistent, because otherwise it's a nightmare. It's also very hard to do any Excel manipulation of HH:MM format because you can't sum easily.
However - because life is complicated :) - we also have to consider teams with smaller increments that cannot be well represented with decimals (e.g. 20 minutes, or simply using our timer).
Do teams on this thread feel that it's an unacceptable compromise to include both the HH:MM and decimal results on all exports so that they can be manipulated easily, but retain the precise values for those who want them?
Hope that all makes sense,
John
*
* Verity Whitmore
John Furneaux: input doesn't need to be the same as output (so some clever calculations in the background can mean that people can enter both formats but it converts to decimal for reporting purposes.). However staff are super confused by having 2 different input methods - just too complicated and folks don't want to spend time thinking about timesheets. Why can't it all be in hours/mins ?
Z
Zak Lawton
John Furneaux: I feel for the jobs I do in my firm are small jobs so like you said in the statement it does require thought process to say 20 minutes is 0.33 where if it was HH:MM it would instantly be done and not have to be reviewed so there isn't any time wasted. maybe have a setting that can change the time to HH:MM or decimals for different preferences
E
Erica Schneckendorf
John Furneaux: Good Morning, While my agency would prefer to keep it by the hour, I think Zak Lawson's recommendation of it being a setting option would accommodate everyone. Each company can set it by their company standard, all while still streamlining to one consentient way of billing their time.
J
Josh Fuller
John Furneaux: For simplicity, this might be best as an organization/workspace formatting setting. In our world, we think to the hour, or half hour at most. For others, clearer minutes might be best. A big struggle is getting newer employees to think on the scale you're used to. The conversion should be simple enough on the front end, and the output could be customized like % versus hours in resourcing. This way you don't need a training on how to enter data, the system guides you.
John Furneaux
Ok so does anyone object to just standardizing on HH:MM for inputs? It's important that we avoid 'settings bloat' where we can to keep Hive simple.
J
Josh Fuller
John Furneaux: Works for me. My biggest point would be to make the format explicit to the end user, and it sounds like that meets it well.
T
Tomos Walters
John Furneaux: Just to echo some of the older posts on here - regardless of what you settle on the various input formats or options - please do not delay in getting the export format consistent. At the moment exports can have differently formatted time data in the same column - please fix this ahead of anything else, it breaks any attempt to analyse or collate the data without significant manual intervention or workarounds.
John Furneaux
Tomos Walters: I completely agree. The export format is just crazy.
I have good news: the stories were started today. We move swiftly, so we should have an update quickly.
J
Jeremy Chase
under review
E
Elizabeth O'Hare
Agree to add
Andrew Naisawald
Andrew Naisawald
Merged in a post:
Align date formatting in Resourcing export
M
Mark Zahorik
Depending on how estimate entries are made for resourcing (project level vs action card level) the hours can come in three different formats. Unfortunately trying to normalize the data back into a single format in the export does not retain the hours entered.
Andrew Naisawald
Exporting the time-tracked field from Table View for example results in the time-tracked section being in different formats and requires having to manually replace the values in the column to make them usable for analysis.