New tick flow - suggestion for workflow improvement

[quaestor]

This is actually from an older discussion. My impression is that a lot of users have issues with the way that multiple route logging is handled. Here is how I think the workflow should look like:

1. You select a bunch of routes to log, then open the interface
2. There are "next" and "previous" buttons to switch between the different items you selected
3. You enter the information in the order you want
4. On the last route, the "next" button leads to an actual summary page that lists all the routes, with the information you've entered.

Pressing "Log ascents" on that summary page commits the database transaction (that is, sends a bulk API request), but you have the chance to correct your entries by pressing "back".

Furthermore, there could be an "add shot" button like in the old implementation, which adds a shot number to the title of the modal and switches to the next page (so you can go back to the previous shot via the "back" button mentioned above). There have been complaints about having to open the logging interface multiple times to do this (e.g. to comment on each attempt instead of using the "number of tries" feature).

[martymh]

I would also like to see these improvements. Especially having per-shot comments. I chose to switch back to the old UI to log multiple shots for something I am projecting. I had notes on each attempt that I wanted to log separately with each shot, and it just felt tidier to do it that way.

[scd]

I note that there are probably three different pieces of work here for us to consider.

1. Clone shot when saving so you can add another ascent of same route.
2. Navigate forward and backward buttons.
3. Summary page with deferred save.

Note that there is a lot for us to consider here. In particular the deferred save summary page is not something we really want to do, but could consider an alternate solution like draft / publish status.

At least now we have this in an git issue for ongoing discussion.

[martymh]

Adding this comment as suggested by @scd in the release 104 discussion.

In the per-shot vein, I think it would also make sense for the user to be able to set different tick types for each shot.

It is quite reasonable that a climber working a route would have multiple attempts, and that those attempts could have different tick types. They could perhaps start with a top-rope tick, then have a failed lead attempt tick, then a hang dog tick, and then maybe something like a pink point or red point.

Perhaps this boils down to there being two classes of information being collected in the ticking interface:

1. Route information (these values would be the same for all shots/tries)
   • Route
   • When
   • Quality
   • Difficulty feedback
   • Overrides (route name, grade, length)
   • Route comment (a comment about the route itself, not the ascent)?
2. Ascent information (these values can differ between shots/tries)
   • Who with (belay partners can change between shots)
   • Tick type
   • Ascent/shot comment

If a user selects multiple attempts, then being able to override the ascent information fields on a per-shot basis should allow them to enter the desired information.

[scd]

Just to be clear in the old tick flow a shot is a separate tick and it is not associated with the original tick. It kind of looks that way because of the UI template, but if you update after you must update ticks separately. So the discussion of different tick types per shot is not correct.

[martymh]

Ah, okay. Thanks for the clarification, @scd.

Well, the old UI did make it easy to add, comment, and set different tick types for multiple ticks of the same route.

Could something equivalent be provided by the new UI? Even if it does mean that multiple ticks are created to match the user's choices?

What I mean is, if per-shot overrides are not specified, then a single tick for the route would be added to their log. But, if per-shot overrides are specified, then multiple ticks could be added to their log (one for each shot).

Granted, later updates must be done separately, but that could still be okay? It's what I have to do today, anyway, if I want to edit a shot from the old UI.

[scd]

I am thinking of a button which allows you to 'save and clone' which saves your ascent clones the details for you to add another ascent. We need to work out some designs and wording. Also we need to make sure it works with the other idea of navigating forward and backward through the list.

[quaestor]

I'm delighted to see that this is gaining some momentum. Sorry for being a bit miserable in the forums, I should have created an issue immediately.

[scd]

Change is always difficult. I can hardly remember adding anything without having change management issues.

[martymh]

Yes, @scd, a save and clone button could be a good approach.

I suppose some care would have to be taken with how the number of attempts in session input is handled with regards to cloning.

For example, a user that wanted to record 3 attempts would likely set that value to 3, and then press the save and clone button. But, in that case, what should happen with the value of 3 that is assigned to number of attempts in session?

I assume that we would not want to clone that value, otherwise the user would have 3 ticks with 3 attempts each, totalling 9 ascents. Not what they would have intended.

What if the solution was something like:

1. Add a new Customise each attempt checkbox just below the number of attempts in session input (the checkbox might only be visible/enabled if the number of attempts is greater than 1), and
2. When customise each attempt is checked, the save button text changes to save 1st attempt, save 2nd attempt, and so on while editing each customised attempt (using your save and clone approach)

This would actually result in a save and clone for each attempt, as you have already suggested. When customise each attempt is checked, the number of attempts in session would determine when, and how many, clones are needed. Also, in that case, the number of attempts in session would not be saved with the individual ticks so as to avoid "duplication" of attempts. That is, the user wanted 3 ascents, not 3x3 ascents.

[rouletout]

Most if not all of that was implemented with last release, closing.