Online Timer

> Bump
What dos this mean ?

Infonomix, dotproject, and others provide timers. If Storm had an optional javascript timer module then Storm would be close to a 100% replacement for Infonomix and remove one of the main incentives for using the other project management tools. Even in organisations that do not bill customers, managers want time recorded.

Timer screens are often lost on a busy desktop. For my use, the ideal time recorder would update the database once per minute using Ajax. If I shut down the browser without remembering to record the end time, there will be an end time to the nearest minute. Jquery timers lets you time easily using the best of Jquery and could be easily connected to a standard button you could put on task and project pages. We could then record against a task or project without having to set up artificial tasks.

A timer table would be useful to let us see the times as recorded. When we hit start, create a new row then each minute update the end time in the row. The button text would change to stop and there could be text next to the button showing the cumulative time.

There was a timer for Drupal 5 but it is not for D6, required CCK, and is not Jquery, leaving the user with possible browser compatibility issues. A Storm Timer could be useful outside of Storm if it could be used without activating other Storm modules.

Would you available to sponsor the development of this feature ?

Marked #282787: Time tracking through a js stopwatch as a duplicate of this issue.

Check this out: http://drupal.org/project/bubbletimer.

Funky - and REALLY easy to integrate.
A possible way could be to have minimal integration and add-on functionality with that module enabled.

Would somebody like to take a stab at this?

It'd be good to even simply have a button for each of the start / end times which inputs the current time to that field.

We have here two totally different approaches:
1. stopwatch (http://plugins.jquery.com/project/timers)
2. bubbletimer (http://drupal.org/project/bubbletimer)

Mine choice would be bubbletimer (check out the screencast http://www.youtube.com/watch?v=hfajpm2No1o ), because I do not understand usefulness of stopwatch - with it when you are working on some task/ticket/project you would have to open it's node. On the other side that could be easier then measuring time be hand... Am I right?

Maybe some combination would be most complete (and complicated) solution.

Other opinions?

Would #539982: Don't loose any time when timetracking solve this?

perhaps soon - but don't think it is all quite covered yet.

I have attached an image of what I think creating a Timetracking node should look like. This would include a simple start and stop that would log the current time and date and then automatically total it (with permissions to only allow admins to manually change the times).

What does everybody think?

Looks good, will it work in the background, i.e. will you be able to navigate elsewhere whilst it's still timing?

I think it would work to either leave the window up while you're working on the project or you could save it after clicking the start time and then edit the timetracking node when you're ready to put in the stop time. Either way would work I think. I'm not a good enough programmer to actually do this but this seems to be the easiest solution to having a timer... And I would simply like to see some of the changes I show in that sketch implemented.

How about using http://plugins.jquery.com/project/timeEntry
Would simplify things as well as offer extra functionality and it's under GPL.

http://plugins.jquery.com/project/timeEntry looks pretty nice. I think that would be a great addition.

I've managed to integrate the jQuery timeEntry, if you want to have a look before I tidy up and make a patch:

URL: http://storm.ctscomputing.com/node/715/edit
Username: stormtest
Password: Storm-Test

@Mark_Watson27 Looks great! I really like the jQuery timeEntry integration. And it looks like the duration is updated automatically. Love it love it love it!

I wonder if there is a way it could be a bit simpler? The time controls for the field are a little over the top I feel - really we only need the functionality from the central button - i.e. set the field to time().

Ideally the duration would update on the update of the time end field too.

So - functionality wise its good, but usability wise, still needs a bit of work.

The only reason I would want it simpler is if you only had the ability to start and stop but once you put in the value and save you can't change it again. But admins would be able to go in and edit the times. But if we don't want to go into that then I like being able to use the arrows to change the time, I actually think that is much more simple for the end user than what we currently have. Plus if you simply click the little circle in the center it puts in the current time. I do wish that little circle was bigger...

@Jay I think adding the ability to pause the timer would be too much work and not really necessary. Personally I think that if you need to take a break then stop that timetracking and then create a new one when you get back. That keeps the functionality simple and it keeps the work time periods logged separately.

@Magnity: Agreed it could be simpler, having said that the plugin does offer some great functionality, probably a bit over the top for just two fields! The plugin does allow you to easily get rid of the left/right arrows if that would make it 'simpler'.

@Jay: I agree with @deggertson that 'pausing' the timing would be more appropriately acheived via two time entries.

@deggertson: I think the granual field access control is a bit over the top and probably not a wide usage scenario. As for the size of the little circle....Well the jquery plugin offered some alternatives so I used the examples to code in a big version when you hover over.

I've also coded in the 'range' functionality of the plugin, this stops you setting time begin after time end or setting time end before time begin.
Up to you guys.

A pause button would work if the time end field was removed, but otherwise there could be an inconsistency between the start / end / duration fields, which I'd like to avoid.

The pause feature would be nice but as I am not really a programmer I have no concept of how difficult it would be... I guess if you took out the end field like Magnity said that would work. In fact I really like the idea of it simply adding time to the duration field while the timer is counting and then allow you to pause and you would simply save the timetracking when you stopped... That would make it so that you could have one ongoing timetracking for each project/task per team member working on it that they could just come back to whenever they wanted to continue on the project. I'm now convinced that this would be the best option. Really no need for a start and end time if you are doing it this way. And it keeps it easier for admins to see how much somebody has been working on a project. I really would be a pain to look through 20 timetrackings for one person just because they had to take a few 10 minute breaks. More thoughts?

Why don't we keep begin, end and duration fields as is but introduce a billing duration field.

This is how we currently handle time in our company. That way the billing duration can be altered by someone if they don't think it's fair. We also use the billing field to enable multipliers for out of hours work, so that the duration is always accurate but the billing duration can be time and a half or double time.

In the case of the above usage scenario the billing duration is simply less than the actual duration and would be the one affected by the start/pause/stop buttons.

Hopefully I'm not joining this great discussion too late. I'd be willing to integrate this improved timetracking functionality into my two modules storm_quicktt and/or storm_dashboard and as they both come with some space on screen already, it would just require the pause/resume and the stop buttons.

With regard to the last few posts I would like to suggest that there should be 2 extra fields: (1) as already suggested the billable time field which can be manually adjusted for many reasons and (2) a field which summarzies the pause time which was counted between start and end time. This would in all regular cases explain as this: end-time - start-time + pause-time = duration. And then billable time would be the relevant one, the other 4 fields are computed values.

A second question is about the automatic recording: so far the suggestion is to implement ths browser based. However, I could imagine a server based recording too. This would help to record time even if it wasn't performed in front of a PC, e.g. customer visits, travelling, and others.

Storm_quicktt is looking to be a great addition as well as storm_dashboard though it would be nice if all the functionality was built into storm core as I see this as something everybody would probably want and need. I believe once we have added a timer into the edit timetracking then storm_quicktt could then take advantage of that to be able to not only stop the timetracking but pause it also. Otherwise I feel that storm_quicktt is already a pretty great solution.

Its probably easier if as much as possible of the functionality goes in the main Storm Timetracking module.

I'm fine with adding billable time. For upgrade purposes, the contents of existing duration fields should probably become the billable time field, and the duration field should become the time end - time beginning. This would also get rid of the need for an option for recalculating the duration, as one would always be computed (duration) and one would either be input manually or by the timer.

For time when you're not in front of the PC, i'd suggest the timer would be irrelevant and you'd just use manual entry to put in times.

I think we're all pretty much in agreement now?

Thanks @deggertsen. I think we do not need a time in the edit form of the stormtimetracking form. We would only need the fields for billable time and maybe paused time as suggested in #32.

QuickTT would deliver the functionality, either for being used by the QuickTT block or by the start and stop buttons already available in Storm_Dashboard. There we would only need a pause button and I'm happy to build them in shortly.

Including the two modules into Storm core is something I'm happy to accept. The decision depends on the Storm maintainers.

The inclusion of those modules or the functionality from them is something we'd have to discuss in a different topic, which i'd be happy to chat about.

Meanwhile, lets focus on the topic in hand, the timer functionality.

@Magnity I think we're on the same page.

@jurgenhaas I would wait to develop QuickTT much further until the main Storm Timetracking construction dust has settled. Once that is done you will be able to adjust QuickTT to match what is available in the storm core TT.

Agreed

Patches are always more than welcome on any issue. I'll also admit js is not my forte.

I'm not sure if @Mark_Watson27 is still in progress with something though - as he seems to have done a fair bit of it already. Otherwise feel free to go ahead.

The work I'd done was only to set the begin/end fields via a click, not a timer as such.
I'd agree that using Storm_QuickTT or it's features would be best for this issue.

As such I see the next steps as (as per @Magnitys comment #34)

1) Change existing duration field to billing duration. I presume we need to do it this way for is for invoicing purposes.
2) Implement new duration field
3) Use Storm_QuickTT to set begin as start of timetracking, end as end of timetracking, duration as difference of these two and billing duration to exclude any pauses.

So let's not re-invent the wheel with the great javascript work of @jurgenhaas in the timer for QuickTT/Dashboard, leaving the question of who's up for altering the Storm module side of things (i.e. step 1 and 2)?

Cheers
Mark

I agree. I'm ready to go for step 3 as soon as 1 and 2 are done.

So for users that did not install storm_quicktt, they would be left with an additional field that they have to manually fill in?

@Magnity I think that's fine.

Are we leaving out the pause button or is that going to be part of quicktt?

I think the pause button will (at least) be part of QuickTT

I would like to be satisfied that the experience for a user who had Storm but not QuickTT would not be degraded - and in this case I mean things which would cause more hassle for them, such as needing to enter more values into fields to get the same operation.

As I understand it from the discussion, billing duration would be the field then used for other functions such as automatic billing. However, if billing duration is no longer linked to start / end times, those users who used to enter their own start / end times and let storm do the rest will be losing out.

Well we could let them decide via an option, i.e. a setting that allows them to use QuickTT to handle the start/end/duration fields or in the abscense of the QuickTT module let Storm do the work.

I've just committed the changes as per 1 and 2 of #41. Assuming the rest is going into storm_quicktt or similar, i'm marking this issue as fixed. Equally though i'd be happy to add the timer to 'Storm core' if preferred - just reopen.

There was an existing setting that controlled whether duration was automatically calculated on each node save, and I have used this in order to set whether the 'billing_duration' field is automatically set equal to the 'duration' field. Therefore if this is going to be used by storm_quicktt, then perhaps this variable needs to be set false.

That's great. I'm going to submit number 3 of #41 later today and that will then work for QuickTT as well as for Storm Dashboard.

Just submitted the new feature which allows pause/resume of timetracking for the current project if using QuickTT. When Storm_Dashboard is used, timetracking can be started/stoped and paused/resumed for organizations, projects, tasks and tickets.

At the moment, just the text "Pause" or "Resume" is displayed and we may want to replace that with icons. I'm open for suggestions.

What I'm doing next is to implement the ongoing storage of elapsed time so that you can't forget to save your timetracking.

Well, I have now implemented the timer in QuickTT as well. That was a bigger deal than I thought but it should now be working very nicely and is fully integrated with Storm_Dashboard (if available) and the QuickTT can operate as an API without the visible block, if that's what you prefered.

Looking forward to you feedback, but probably not in this thread anymore but in a separate issue in the QuickTT queue.

I just found this module, came across this issue, and I'm in awe at this development circle. Thanks.

Related to #1873992: Enter time via comment