mobtimeapp / mobtime Goto Github PK

When booting up the timer, log if there is a newer version of the timer that can be pulled down.

Having a dedicated database might increase scalability, but it's not clear what sort of limitations in-memory is going to pose.

ava is great for writing tests for both front and backend. We should be able to write tests for all components. Cypress would be great for end-to-end tests, too.

Notifications can be duplicated right now, but changing the ResetTimer action to check for timerStartedAt before sending out a mass notification would fix this.

It just needs a limit for now.

Enable app tokens. For now, probably on a per env basis. Maybe something like:

APP_TOKENS="someTokenHash:timerId,otherTokenHash:timerId" node ./index.js

At some point, this could be migrated to some database.

Celebrate often. Allow users to share a reactions, like emoji/animations.

This feature isn't really being used in general, but it also was a feature band-aid to calculate end of cycle that never really made it out of the gate.

I sort of envision a public/i18n/index.js, along with public/i18n/en.json for now. I don't mind having more than english, but I think this ticket is just to extract as much text as possible into key/values so we can swap out other languages.

Goal complete/uncomplete has a weird path ordering that doesn't follow the scheme of other endpoints.

Doesn't have to look like the timer card. Maybe a little more market-y?

If actions didn't auto dismiss, having a "Cycle and Restart Timer" action could make things smoother. That also means adding a dismiss action.

I currently don't have any tools to see how timers are being used, and what sort of engagement users are having. Since timers already provide users with unique anonymous tokens, I want to create a small sqlite database that looks like this:

This could help identify UI and collaborative issues, like multiple timer starts within a time period, wrong defaults, difficulty starting a timer, frustration with limits, etc.

This could also provide a way to build statistics that don't require live data.

Enable https://xyz.ngrok.io/timer-name to create new adhoc timers.
For the sake of memory, timers should probably delete themselves if there are no websocket connections for N (probably 5) minutes.

Depending on the team using it, have a select option to auto rotate the team. This may save a click and keep the flow going.

Keep track of who has added a person, started a timer, cycled, etc.
Only viewable by the first user to connect to the timer.

Depends on #6

Depends on #131

Over voice chat, it can be very noisy if everyone is chatting over each other. A small chat feature could be nice. Maybe integrate with discord or slack could be neat.

There should be some documentation about where code is located, what the API is, and some guidelines on what contributions should contain.

I'm not a designer, and this could look way better. I'm currently working with @FrankyFrankFrank on some design ideas, but others are welcome, too.

As it currently stands, there is no endpoint that exposes a list of timers, or a way to identify malicious use of timers (ie timer spam, people intruding on a timer, etc.). Having at least a data set to track would be better.

Allow signing in with github to automatically add you to the mob timer, and to give a profile picture?

See number of active timers and connections in a broad sense.

A cycle count increases if:

• At least 2 mobbers
• Cycle has been pressed at least once
• The mob array matches the initial state (will have to be stored as extra data)

A cycle count is reset if:

• Shuffle has been pressed
• A new mobber has been added and a full cycle has been completed
• An old mobber has been removed
• The timer has expired

When a cycle completes:

• A notification should be displayed
• You just completed a cycle, consider taking a 5 minute break

As a user, I should be able to:

• Save the timer state to local storage
• Save the timer state to a file to load later
  • Load a timer from a file

This will supersede #20 , but it's not off the table. Depending on user requirements, database support could become a paid feature for dedicated timers in the future, but I don't think it's necessary.

The API currently hard-codes the max number of goals. This should be set by the timer itself, so the clients can receive that data rather than have those values synced between server and client manually in code.

We've developed 'mob', a CLI tool that allows to handover your state via git more easily. You can start a session by $ mob start 10 which will get the previous state and starts a 10 minute timer. Problem often is: the timer is overheard. But rotating often is important.

To solve this, I was thinking how to combine 'mob' with 'mobtime'.

The idea: 'mob' could send the name of the user, the duration (10 minutes), the timestamp, and maybe a hash of the origin url as a mob name when $ mob start 10 is called and others could then open 'mobtime' as well in the browser to help keep track of rotation. With that approach, we wouldn't really want to enter data into 'mobtime' manually, but it's only fed from the 'mob' tool calls - making the ui components of 'mobtime' for this case unecessary.

htm is a great substitute for jsx, and will make reading h(tag, props, children) much easier.

Each time we add a name, provide an id to it. Use that id for subsequent api calls.

Have a basic todo list that your team can manage the goals of the mob.

At the end of a cycle, you are prompted to reset the goals.

Depends on #15

• Share turn time so you can just click "Start the Timer"
• Force users to "knock" to enter timer

Clients need semi-frequent activity to keep the connection alive. Sending { ping: Date.now() } should be more than enough, every n minutes