Add "Propose new trick" link to navigation

[JulianDietzel]

Addresses issue #230 by adding the button to the form next to the "About" button in the navigation bar. This felt like a place where it is easy to find but not too prominent.

While working on the files, I also refactored the let y = x === z ? true : false lines to let y = x === z and removed two unused dependencies.

Result on Desktop:

Result on Mobile:

[Felix-Hmpl]

Good job, I think the position you have chosen in the menu is great.
I could imagine the "add new trick" page as another good place for this option. What do you think about that?

[Felix-Hmpl]

Right now the link is hardcoded and appears in two files. I think it would be a good idea to store the actual link once in some kind of ressource file.
This way we can change it faster and more reliable when the link changes in the future.

[JulianDietzel]

I could imagine the "add new trick" page as another good place for this option. What do you think about that?

That's a good idea, too. Semantically that might be an even better placement. There are three minor concerns I'd have with that placement:

1. It could seem like the link would act as an alternative to the "Add trick" button in that the filled in data would be submitted to who ever reviews new tricks. But instead its then just a redirect, meaning that the person filled in the data for nothing. That's not too bad though and could be mitigated by adding a horizontal line or adding a small comment on what the link does.
2. The link might be harder to find. But that is purely my feeling.
3. One concern I had when placing the button was it being too prominent. Not every trick needs to be submitted for everyone to see. Probably only very few tricks should ever be submitted. So making the link or button as prominent as adding just a regular custom trick could give the impression of it being a equal 50 / 50 choice. This is why I ditched my initial idea of adding a second "+" button on the page where the tricks are listed. Again, this could be mitigated just by having it look like a link and / or adding a line or a small description.

Honestly, I don't know which placement is better. Do you (@Felix-Hmpl) or does anyone else have a preference?

Right now the link is hardcoded and appears in two files. I think it would be a good idea to store the actual link once in some kind of ressource file. This way we can change it faster and more reliable when the link changes in the future.

On a general note: I was a little surprised by the architecture here. Every time I have worked with bootstrap in the past I just used an Offcanvas Navbar. This way the navbar is contained within one file and just responds to the screensize. Having this would solve the issue. And also the issue that not just the link but all the other options in the navbar need to be synchronized (like for example, the Import / Export functionality is just not there on the desktop version). This might have been a well thought out design decision but it could be worth it to explore this in a little more detail.

On a more practical note for the moment: I do think it would make sense to have the link be referenced from a central resource but since, from my understanding, no such file or thing exists at the moment I also think it's fine this way.

If there is a good / standardized pattern for these kind of resources though and you know of it, please let me know and I will implement it. Might be useful for other links in the future.

[Felix-Hmpl]

I understand your concerns. Honestly I do not know who manages the trick proposals. But in my opinion it would be great to have a lot of new tricks coming in and I think it would be worth the (evaluation) effort.

Concerning the placement

Assuming that we have enough capacity to handle lots of proposals, what do you think about the following placement idea:
All tricks that have been create manually have a "Propose this trick" button in their TrickDetails view. Clicking this button collects all the information of that particular trick and sends a proposal in the background via a POST request. I do not know if google forms supports this, but we could use something different if not. The user should then be informed, if the trick is still in the evaluation process, accepted or rejected.

This way the user does not have to enter information twice and can delay the proposal to a later point in time (e.g. after a long trip with no internet). Also, I think this is very intuitive.

Furthermore, we could more easily manage a problem that I just thought about:
Given the current state of the app and a user that decided to propose a trick, that s/he already added via the plus sign. If the trick gets accepted and added to the library, does this users TrickList now contain two versions of the same trick?
If the user proposed via the button I mentioned above, it may be easier to merge the trick coming from the new TrickList release and the local trick. The user never entered information twice, so there are no typos and they have the exact same information.

But maybe this is not relevant for this pr and should be handled seperately :) I will create an issue in the next couple of days

[bastislack]

Honestly, I don't know which placement is better. Do you (@Felix-Hmpl) or does anyone else have a preference?

I like the placement this way :)

Assuming that we have enough capacity to handle lots of proposals, what do you think about the following placement idea: All tricks that have been create manually have a "Propose this trick" button in their TrickDetails view. Clicking this button collects all the information of that particular trick and sends a proposal in the background via a POST request. I do not know if google forms supports this, but we could use something different if not. The user should then be informed, if the trick is still in the evaluation process, accepted or rejected.

This sounds like a nice idea, too. I think for now we could just use @JulianDietzel's solution and take your suggestion as an upgrade in the future.

On a general note: I was a little surprised by the architecture here. Every time I have worked with bootstrap in the past I just used an Offcanvas Navbar.

I never really had an in-depth look at the responsive UI design, but the Offcanvas Navbar sounds like a cleaner solution than what we have now.

[JulianDietzel]

Assuming that we have enough capacity to handle lots of proposals, what do you think about the following placement idea: All tricks that have been create manually have a "Propose this trick" button in their TrickDetails view. Clicking this button collects all the information of that particular trick and sends a proposal in the background via a POST request. I do not know if google forms supports this, but we could use something different if not. The user should then be informed, if the trick is still in the evaluation process, accepted or rejected.

I like that idea! At it actually seems possible to make a POST request to a google form (Dev.to article from 2020). I think moving this to an issue in of itself seems like a good idea.

If we stick to my proposed solution until we implement that, like @bastislack suggested, then feel free to review or directly merge it.