New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

History and Timeline of Breaks #266

Open
aleuca opened this Issue Jul 7, 2018 · 7 comments

Comments

5 participants
@aleuca
Copy link
Contributor

aleuca commented Jul 7, 2018

Feature addition

Add a new window with history and timeline for breaks.
Acceptance criteria:

  • stretchly has events: break has started, break has finished, user has entered idle time, idle time ended, system went to sleep, wake up of the system, etc...
  • every of this event is saved into local DB file (eg. Event) - SQLite or Postgres?
  • when we are saving event, and we know it's the end of the event (eg end of break), we save new line in DB, let's say Activity (regural break, idle time, skipped break, extra break...)
  • from Activities, we can then have some stats, graphs for skipped break, idle time etc..

Reference #200 and #86

@Sveijk

@hovancik hovancik added the RGSoC 2018 label Jul 9, 2018

This was referenced Jul 9, 2018

@Sveijk

This comment has been minimized.

Copy link
Contributor

Sveijk commented Jul 11, 2018

List

List of all events we could find and actions or state.
Here's also an image attached of sketches for a data graph.
Items that could be subject of the graph are:

  • Counters (number of breaks, etc during some timeframe)
  • Time (duration total of breaks, etc during some timeframe)

Image of our awesome drawn graph

Events

  • Go on break
  • Go on microbreak
  • Pause breaks
  • Pause microbreaks
  • Reset timer on breaks
  • Go to idle mode
  • Come out of idle mode
  • Skip a break
  • Finish break
  • Finish microbreak
  • Skip timer to the next break
  • Skip timer to next microbreak
  • Change settings { microbreaks enabled; microbreaks disabled; breaks enabled; breaks disabled }
  • Reset to defaults
  • Timing changed
  • Skip enabled or disabled breaks / microbreaks
  • Break induced
  • Microbreak induced
  • Manual pause (for an hour; for 2 hours; for 5 hours; indefinately) finished
  • Normal pause finished
  • Postponed

Activity / State

  • Work
  • Idle (computer idle or turned off)
  • Break
  • Suspended / paused
  • Microbreak
  • DND / presentation mode
@drigberg

This comment has been minimized.

Copy link

drigberg commented Jul 11, 2018

I wrote a whole explanation of why i would do it a different way, and then I realized that yours is better. Great work!!!

@drigberg

This comment has been minimized.

Copy link

drigberg commented Jul 11, 2018

Could you provide a proposal for the Event schema? Example:

{
    id: string,
    type: string,
    timestamp: date
}
@hovancik

This comment has been minimized.

Copy link
Owner

hovancik commented Jul 13, 2018

Hey folks, so some things I've been thinking about. I've polished your list of States

Activity / State

  • work (when user is doing whatever she wants)
  • idle/natural break (when we are in idle time - meaning user has been idle longer as 5 minutes - as it it in app right now)
  • break (when break is on)
  • microbreak (when microbreak is on)
  • paused (user has manually paused)
  • DND / presentation mode
  • suspend (computer is in sleep)
  • turned off (pc is turned off)

and questions I am not sure about:

  • do we need to differ between suspend and PC turned off?
  • what will happen when break is on and PC is suspended/turned off?
  • do we need to differ between break and microbreak and natural break? (I guess we want to differ)
  • do we want to have manually started breaks separately?

More specific stats that we would like to have in the end should help us answer this.

Events

We do not need events like user changed some settings and so on. I think the Event should be an event inside application that causes one user State to change to another.

@hovancik hovancik added this to In progress in RGSoC 2018 Jul 13, 2018

@Sveijk

This comment has been minimized.

Copy link
Contributor

Sveijk commented Jul 14, 2018

We researched which database could be used with an Electron App. A database that wouldn't make the user install anything extra other than Stretchly. It seems that there're two options here that we know of: Sqlite and NeDB.

@hovancik

This comment has been minimized.

Copy link
Owner

hovancik commented Jul 16, 2018

I'm for SQLite

@aleuca aleuca referenced this issue Aug 31, 2018

Open

Stats #288

3 of 8 tasks complete
@Hum4n01d

This comment has been minimized.

Copy link
Contributor

Hum4n01d commented Sep 7, 2018

I don’t think you need to use a full fledged database, couldn’t you just store things in the default app.getPath('userData') data folder?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment