Cannot enter new workout name when template exists

[ckelwin]

Is this expected? Should the UI be redesigned?

Template exists. Cannot enter name of template. Only template selection is visible.

No template exists. Can enter new workout name.

[KalleHallden]

It is to be expected the way that I designed it. But like most things I have designed there may well be a better way. Are you thinking that using a search field would be better, so that the user can search for workout templates?

In the case that a user has used the app for a long time and has hundreds of templates then this is probably better.

[ckelwin]

I'm still a bit unclear on the process flow of this app. When it is empty (I do not have any workouts yet), the Start new workout suggests I am trying to log my workout routines into the app. This makes sense as the "workout data" is stored with the current (server) timestamp. So, this is something happening 'now'.

However, once a template is created, there's only the dropdown to select workout from templates but I cannot 'start fresh' like in the use case above when no templates exist yet. Well, not entirely true because we can proceed without selecting any template and add an empty workout on the next screen. Just feels a bit odd having two different process flows depending on whether there exist any templates.

This might be somewhat related to the discussion in #26. It would be clearer to separate the process flow between 1) creating an ad-hoc workout schedule, and 2) creating/maintaining a template.

Suggestion: A more fancy way to categorize and search workouts from templates will be nice. However, that will be a bigger piece of work. As a quick win, we can now do the following:

1. Start new workout : existing button, that starts an empty/adhoc workout. This shows the New Exercise dialog when no template exists.

2. Start from template : new button place below/beside of the existing button in point 1 above. This shows the New Workout dialog current shown when there are templates created. It then creates a new set of workouts based on the selected template.

@KalleHallden What do you think?

[KalleHallden]

Great points, I agree! That sounds like a better UX. Let's do that!

[KalleHallden]

I created the smaller-features branch where these sort of smaller improvements can be worked on.

[ckelwin]

@KalleHallden We should be working from (branching out and merging back into) the master branch. Having multiple open branches outside of master with different features will create a merge hell situation when they need to be merged back into master later on. It also causes confusion as to what is in which branch.

I suggest all features, big or small be branched out from and merged back into master. That means each pull request needs to be in a working state and should not cause master branch to break.

Also, I would like to work on this issue. Can you assign it to me? Thanks in advance.

[KalleHallden]

Okay I'm not really sure I understand how what you describe is different from what is currently being done? We have a master branch and then other branches that are branching out from master and merging back in aren't we?

I've also seen suggested git structure something like this: master ---- version -------- feature 1 -------- feature 2 -------- bug 1

Where everything is merged into the version branch and once the new version is complete and has passed testing then the version is considered complete and merged into the master. As a way to keep the master branch as the most stable version. But I think I am missing something in what you said since I thought that the workflow that you suggested is what I was doing hehe

Yes I'll assign you!

[jorre127]

@KalleHallden I think what he means is that we skip the in-between branches like "login" and "smaller-features" that are currently being used. instead Pull requests will just be made directly to the master. This way we don't have multiple branches running parallel to the master each with different changes. This makes it easier to know what is currently in the app and will also help with merge conflicts. Even better would be like you said to have an in-between branch like "alpha" for example, all the pull requests will go to alpha then, this way you know the alpha branch will have all the new features. Then when you think it is stable enough for a new release, when can merge alpha to the master. And repeat the process of making PR's of new features to the alpha branch until a new release.

[ckelwin]

@KalleHallden Branches you mentioned like 'feature 1', 'feature 2', 'bug 1'... these will be created in other's (not your) forked repository. We'll need to create a PR from our repo into your repo's master branch. So they shouldn't appear in your repo at all. As for 'version', there is no need to create a branch specifically for the 'next release' we are working for. That is the 'master' branch. Upon releasing a version, you can use tags to identify a commit. However, some may choose to create a branch instead which is fine but this should be created towards the end, not at the start.

I am suggesting to stop using multiple long-lived development branches (as what @jorre127 described above). They may work fine for smaller teams or when developers are working on different areas of a large application but can become challenging in an open source setting.

https://trunkbaseddevelopment.com/ The website talks about Trunk Based Development (TBD) and contains some useful information. TBD suggests having a single 'main' branch (e.g. main, master, trunk, etc.). This branch should be releasable all the time. Therefore, automated tests and ensuring the build passes before merging into the main branch are important.

When you decide to release a new version, you can choose to either:

1. Create a new "candidate/alpha/release" (R) branch for it. This will be branched out from master. This allows everyone else to continue contributing where their pull requests will continue to be merged into master. Only bug fixes will be merged into the candidate (R) branch. New commits into candidate (R) branch needs to be merged back into master but not vice versa. This is explained as being ... 'hardened' before a release in the article.
2. Release from the master branch directly. Any bugs found will be fixed in the next release (fix forward).

Some products may provide two download options (e.g. stable and latest). In such a scenario, having two branches (e.g. master and develop) will be needed. Bug fixes go into both branches while new features or major code refactor will only go into develop.

There are many ways to manage the branching strategy. You'll need to find one that is suitable and that you feel comfortable with.

(Thanks for the shoutout!)

[KalleHallden]

@ckelwin haha no worries man thanks for all the help!

Yeah I think we might have solved the branch thing now the way that you meant. I have made the alpha branch the default branch so that is the one that we work on and merge into. So that is the release branch or the latest branch and the master will be used as the stable branch. Not sure if I should remove the other branches from the repo so that people don't accidentally start working in one of those branches?

[ckelwin]

@KalleHallden I suggest deleting stale branches that are no longer needed. Less clutter. You can update the repository settings to automatically delete source branches when a pull request is merged. This is mainly to clean up future branches you push and merged (other contributor's branches will be in their own repo).

Settings > General > Pull Requests > Automatically delete head branches.

[KalleHallden]

Great suggestion, I have done that now.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.