davwillev/stopwatch

Stopwatch external module for REDCap

stopwatch's Issues

Update screenshots (hide/show_target)

Separate show_target for forms and surveys

Use case: show target field on data entry form hide on survey only.

Show a warning when a stopwatch is still running and the user tries to leave the page

Hide reset button

Hi!, is there any way to hide the reset button??

Enhance Tab Interaction, and prevent skipping of Stopwatch(es) after openening a data entry form or a survey

UI for setting storage formats

Awsome implementation thus far @grezniczek !

I had to read the readme instructions of how 'to set up the storage formats for the validated fields' before I understood it, so guess unfamiliar users will have to do the same.

I know it's a little fancy and probably involves lots more work, but for future versions, to avoid users having to write (for example) the /g group separator placeholder, could a future interface use a row of drop-down menus to set the format and create the JSON parameters in the background?

Missing data codes?

How to handle?

Timer mode possible?

Is it possible to use this module as a timer?

I would like to have users hit the "start" button, then have the timer/stopwatch STOP when 30 seconds have elapsed.

Thanks.

Add link to GitHub in config.json

Move error messages into language file

This can be done when adding config.json configuration options - these should be in English.ini, too.

Can stopwatch track form completion time?

Hello stopwatch folks,
I am looking for a way to track time on task for public facing REDCap surveys. Can stopwatch be set to start the timer when a survey is shown and stopped when the user submits the form? If not, can you suggest alternatives to capture time on task? I would like to try to calculate "typical" completion times?

I am a statistician not a web programmer so clues for the clueless would be greatly appreciated.
Ray

Stopwatch for time_mm_ss should not show hours

Start with widget at top of display (and keep it there)

When using a text box, the widget begins at the tope of the field display and stays there as rows are added to the capture table. However, when using a Text Box or Notes Box with lots of text, the widget begins in the vertical centre of the field and gradually moves upward as rows are added to the table. This means that the user has to keep looking at the widget to 'chase' the buttons up the display to continue using them. This is potentially distracting to the user and risks missing a button click.

Once the table fills the space, the top of the table reaches the top of the field space (after 10 rows or so) and remains there. As more rows are added, the field display increases in size and rows are now just added to the bottom of the table. This latter behaviour feels correct and is easy to use.

ERROR - calculated fields

Hi guys!
When using stopwatch fields into a calculated field, the stopwatch shows an error.

Add paging to capture/lap tabe

Add option for lap mode to show splits?

See also #10.

When a field is blank, the Stopwatch should reflect that

by dislaying not 0:00:00.000 but maybe -:--:--.--- or <blank> or something like this.

Need to disable stopwatch on survey responses when not in edit mode

Define use cases

@davwillev - We should first define the concrete use cases the stopwatch EM is supposed to cover.
There are probably VERY many, such as:

• Simple starting/stoping and putting the elapsed time into a text field.
  • This could be in ms (integer),
  • or seconds (decimal number),
  • or minutes,
  • or formatted HH:mm:ss.nnn
• Capture start time, stop time, and elapsed time in 3 different fields
  • e.g. 2x datetime w/seconds, and an integer field for seconds (or decimal when including fractional seconds).
  • (unvalidated) text fields with HH:mm.ss.nnn format,
  • maybe include the date as well (optionally)
• Capture start, stop, lap time points
  • with or without date (formatted a specific way),
  • with or without the option to halt the time (without reseting - as in current code),
  • as JSON in a text box,
  • as text in a notes box,
  • as new instances in a separate repeating instrument.

This get's rather complicated very quickly. All needs to be configureable by the EM user aka project designer. Fields need to be mapped, etc....

Maybe start with just one use case, but keeping the design open to accomodate more/all of them.

Allow multiple measurements and capture a derived quantity from them

This could be

• minimum
• maximum
• average

of time elapsed.

UI could (optionally?) allow to remove individual measurements before storing the result.

Timer ticks

Currently, Stopwatch uses one timer per stopwatch. Thus, when there are multiple stopwatches on a page, each has its own timer. While this may be negligible for just a few timers, it might be better to have one ticker serve all Stopwatch instances.
This is low priority.

Add 'tallying' feature

Could we add a num_caps parameter to provide a count ('tallying')? This would effectively give the user a method to calculate observed event rate: num_caps/cumulated_time

Rename hide_target to show_target (reversed logic)

And add a separate setting for surveys (show_target_survey)? Both false by default.
@davwillev , what do you think?

HTML IDs

The generated HTML makes use of IDs, which will lead to problems further down, i.e. can't have two or more stopwatches on the same page, or there may be conflicts with other EMs.

Either ids need to be unique, or (preferred) no ids are used at all.

Stops counter is buggy ... it counts in 2, 4, 6, ...

noticed it while watching the call today ...

Ask for confirmation when reseting a Stopwatch

To avoid loosing measurements - see also #34.

Add ability to trigger start and stop through other field(s)

This came up several times in Q&A at the consortium presentation. Might this be related to #8 (Interface for controlling multiple stopwatches)?

Interface for controlling multiple stopwatches

An idea ...
There might be use cases where multiple timings need to be taken. An interface (buttons) to control all (or groups of) Stopwatches at the same time could be added. The functions would include:

• start all
• stop all that are still running
• reset all (only enabled when all are stopped)

This could be implemented as a @STOPWATCH-GROUP="group_id" action tag (that determines placement) and "group" parameters of individual @stopwatch action tags.

This would probably only support the basic use case (record time elapsed).

Storing laps

A very easy to implement way would be to store the laps in a notes field.

Storage as repeat instances of a separate form would require 2 things:

• the configuration logic for the user to set this up, and
• the logic to actually create these instances.

What exactly should be stored? What is optional? How to configure (for the user who sets up the instruments)?

Check docs for spelling and grammar