mobtimeapp / mobtime

A real-time, collaborative mob programming timer. Made with technology from the future, today!
https://mobti.me
MIT License
67 stars 38 forks source link

Feature request: initiliaze mob and other settings in URL which can be bookmarked #104

Open rzijp opened 4 years ago

rzijp commented 4 years ago

Initializing the mob timer is a repetitive process for us to fill in the names for the team and to set the sequence of roles. It would be great if we could add the names as URL parameters, such that we could bookmark that URL and skip the manual steps.

The initialization based on the parameters should only happen once though: when a timer is already in use, it shouldn't get reset when someone opens the bookmark by accident.

mrozbarry commented 4 years ago

@rzijp I'm just going to run down how I'd solve this, and you can tell me if this conforms to what you were thinking

Let's pretend that we have an endpoint mobti.me/_/timer?id=your-timer-slug&mob=...&goals=...&timerSettings[...]=.... ...but I probably won't expose individual params like this, but I'm not sure yet

when the timer doesn't exist

  1. Set a cookie describing the timer build steps
  2. Redirect to timer url
  3. Client reads the cookie, and builds timer data.
  4. Client deletes the cookie

when a timer does exist

  1. Redirect to timer url

other stuff

Also, in the timer settings tab, provide a link that can be bookmarked that describes all of your timer settings.


Does that work for your use-case?

rzijp commented 4 years ago

Thanks for the breakdown. I'm not familiar with how the timer is using cookies and the like to 'exist', but from what I can make up from your proposal it seems to come very close to what I had in mind!  -------- Original message --------From: Alex Barry notifications@github.com Date: 26/08/2020 21:42 (GMT+01:00) To: mrozbarry/mobtime mobtime@noreply.github.com Cc: rzijp git@rzijp.dds.nl, Mention mention@noreply.github.com Subject: Re: [mrozbarry/mobtime] Feature request: initiliaze mob and other   settings in URL which can be bookmarked (#104) @rzijp I'm just going to run down how I'd solve this, and you can tell me if this conforms to what you were thinking Let's pretend that we have an endpoint mobti.me/_/timer?id=your-timer-slug&mob=...&goals=...&timerSettings[...]=.... ...but I probably won't expose individual params like this, but I'm not sure yet when the timer doesn't exist

Set a cookie describing the timer build steps Redirect to timer url Client reads the cookie, and builds timer data. Client deletes the cookie

when a timer does exist

Redirect to timer url

other stuff Also, in the timer settings tab, provide a link that can be bookmarked that describes all of your timer settings.

Does that work for your use-case?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

haraldreingruber commented 4 years ago

Another idea would be changing the URL on the client-side via history.replaceState() and add the settings to the query string when they are updated. This means the current URL will always contain the current settings (at least the ones which should be exposed). Similar to the example above, the URL might look for example like this: mobti.me/your-timer-slug?&mob=...&goals=...&timerSettings[...]=...

On initial load, if that timer doesn't exist yet, the app would have to check the query string params and initialize the settings.

This way, one could just bookmark and share the current URL.

What do you think about this approach?


This feature would be also very useful in our MobRetreat events. In our use-case the most important settings would be:

Just wanted to share our use case as well. I guess it could be solved either way.


Thanks a lot for continuously improving the app 🙏!

mrozbarry commented 4 years ago

Might be related to #133 , but this could be standalone, too.

I'm going to start a branch with just this, and it might evolve info a full client-side router integration ticket, we'll see.

Also, for the sound notification, that will probably end up in localstorage, since it's relative to the client and not the timer.

And it's my pleasure to build a tool that makes any developer's life better.

mrozbarry commented 4 years ago

What if you had something like this in a terminal:

$ npx some-mobtime-command yourTimerName init --mob "first mobber" --mob "second mobber" --goal "first goal" --goal "second goal" --timer-duration 8min
rzijp commented 4 years ago

That could work as well, thanks for the suggestion! I'd have to install npm for it as this is not part of my ecosystem yet, but that's a minor nuisance.  Would be great if we could also configure the roles :-). Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Alex Barry notifications@github.com Date: 21/09/2020 20:21 (GMT+01:00) To: mrozbarry/mobtime mobtime@noreply.github.com Cc: rzijp git@rzijp.dds.nl, Mention mention@noreply.github.com Subject: Re: [mrozbarry/mobtime] Feature request: initiliaze mob and other   settings in URL which can be bookmarked (#104) What if you had something like this in a terminal: $ npx some-mobtime-command yourTimerName init --mob "first mobber" --mob "second mobber" --goal "first goal" --goal "second goal" --timer-duration 8min

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

mrozbarry commented 4 years ago

Yeah, I'm sure we could do --positions "Navigator,Driver" without much hassle

haraldreingruber commented 3 years ago

Another alternative or intermediate solution @mrozbarry and I discussed is offering an option to export/import settings probably via a text area field as a JSON string. Did I remember the idea correctly? I kind of like the simplicity of this approach...

tedyoung commented 3 years ago

I'd like to see something that supports either a direct API endpoint (so I can create a timer from my mob session registration system), or be able to paste a JSON string. Something other than a command line would be desired.

I mean, I could probably kludge something together by sending compatible events over the websocket, but that seems, well, kludgey. 😄

mrozbarry commented 3 years ago

direct API endpoint (so I can create a timer from my mob session registration system)

what is your mob session registration system?

tedyoung commented 3 years ago

@mrozbarry It's a tool I'm developing to help me manage the private mobs I'm facilitating. Still in early stages.

mrozbarry commented 3 years ago

@mrozbarry It's a tool I'm developing to help me manage the private mobs I'm facilitating. Still in early stages.

Well, I am in the midst of a nodejs sdk and cli, so there may be an opportunity there. github.com/mobtimeapp/mobtime-sdk

tedyoung commented 3 years ago

I'm a little fuzzy on what the mobtime-sdk is doing, is it opening a websocket and sending message/commands to the remote mob timer? If so, is the websocket message content considered a "published" API for mobtime (which was basically my original question)? My tool is written in Java/Spring Boot which has direct support for Websockets, so I'd be fine with pushing messages over websocket if that got me what I wanted.

mrozbarry commented 3 years ago

Yeah, you could use the sdk or the vscode plugin as a reference. You could also use mobtime itself for reference, no biggy. As the sdk matures, and if you have time and want to extract it, I'm not opposed to having a java sdk version 😉

mrozbarry commented 3 years ago

Just wanted to note that this is half-done on https://dev.mobti.me/ . Currently, you can edit the timer, and choose to auto-save it, and it will commit the timer to local storage. On load, if you are the first person to open the timer (making you the owner), the app checks to see if there is a saved timer with the same timer slug, and will load it back in. I'm guessing this will best work if all people using the timer have the auto-save checked.

Some other pieces that could work to enhance whats on dev:

rzijp commented 3 years ago

Thanks for the update! Now I realize that what I actually needed was a saved timer, I was already jumping to solutions ;-). Will check it out, sounds promising! Sent from my Galaxy -------- Original message --------From: Alex Barry @.> Date: 02/05/2021 05:41 (GMT+01:00) To: mobtimeapp/mobtime @.> Cc: rzijp @.>, Mention @.> Subject: Re: [mobtimeapp/mobtime] Feature request: initiliaze mob and other settings in URL which can be bookmarked (#104) Just wanted to note that this is half-done on https://dev.mobti.me/ . Currently, you can edit the timer, and choose to auto-save it, and it will commit the timer to local storage. On load, if you are the first person to open the timer (making you the owner), the app checks to see if there is a saved timer with the same timer slug, and will load it back in. I'm guessing this will best work if all people using the timer have the auto-save checked. Some other pieces that could work to enhance whats on dev:

Load timer from file Use an external thing, like (but it doesn't exist yet) https://create.mobti.me/desired-timer-slug?goals=...&mob=... , but this may be difficult since goals and mob participants have other attributes, like ids, avatars, completed, parentIds, etc. That's not to say it can't be done, but it may not be fully descriptive.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

dpolivaev commented 3 years ago
  • Use an external thing, like (but it doesn't exist yet) https://create.mobti.me/desired-timer-slug?goals=...&mob=... , but this may be difficult since goals and mob participants have other attributes, like ids, avatars, completed, parentIds, etc. That's not to say it can't be done, but it may not be fully descriptive.

I would be happy to be able to configure only timer settings (turn duration and mob order) using URL parameters. So I could give a preconfigured URL to all groups in a coding dojo so that they all use the same schema.

In my eyes having additional options to preset client settings or goals is a separate and less important feature. I am afraid that loading all settings from local storage does not allow to distribute the settings over different teams.