Replace "default activity" setting

[dennisguse]

In the settings, one can select the default activity to be used for all subsequent recordings. While recording, one can then change the activity for this recording.

i have the feeling this can be improved by just using the activity of the previous recording. This might be nice, if a user goes cycling sometimes in a row and then goes hiking for several trips. I guess most users won't go to the settings and change the default activity (I don't) and just change it for every recording.

At the end of a recording, we could just store the activity into the same SharedPreference and just remove it from the PreferenceActivity.

[dennisguse]

@rgmf @pstorch Any opinions about this?

[rgmf]

I usually set the default activity with the sport I do the most. Nowadays cycling for example, and then If I go to run then I edit the activity to change from cycling to running.

This is my use case of this setting.

I'm not sure if the change you propose would make my user experience better 🤔

[pstorch]

Or use a combination of both. In the default activity setting add an option "use activity from last recording".

[dennisguse]

I was thinking, this might be an alternative to #983. And just storing the latest activity would also allow us to remove the preference for default activity. Adding another setting is more or less the opposite...

[pstorch]

Ah, you want to simplify the code, not support two different use cases. For me it's fine either way, as I use OT mainly for one activity only. I'm fine with using the last activity for the next recording.

[rgmf]

I can't see how this could fix or be an alternative to #983

If you want to edit an activity after export it then storing latest activity won't solve anything about post-export editing.

Anyway, in this thread we are three people: two of them are not using default activity and the other one do it, so I'd remove default activity setting to simplify the code ;)

[dennisguse]

I am just not sure how to continue with the UI. Should we keep the simple two button interface or go for something with more features, e.g. countdown, sensors, title etc. But that may result in more complexity for the user as well as in the code

So, I was thinking how we can (simply) improve the current UI without too many changes. As I said... not sure how to continue in this i general...

[rgmf]

I am just not sure how to continue with the UI. Should we keep the simple two button interface or go for something with more features, e.g. countdown, sensors, title etc. But that may result in more complexity for the user as well as in the code

So, I was thinking how we can (simply) improve the current UI without too many changes. As I said... not sure how to continue in this i general...

Are talking about TrackListActivity, TrackRecordingAcricity or both? Could you share a UI draft what you are thinking about? It's so we can share our feedback with you. What are you have in your mind?

I'm happy with current UI although it always can be improved.

[dennisguse]

That's my point: I have the feeling that we should do some changes to the UI. But I don't know which and how :)

For example: the pause functionality is technically just doing the same as pressing stop (without moving to TrackRecordedActivity). So:

• do we will still need the two buttons?
• do they always need to be visible (especially while recording)?
• is the UI useful on larger devices?

And we have whole bunch of things that are in this direction: https://github.com/OpenTracksApp/OpenTracks/issues/1088, https://github.com/OpenTracksApp/OpenTracks/issues/1078, https://github.com/OpenTracksApp/OpenTracks/issues/983, https://github.com/OpenTracksApp/OpenTracks/issues/937, https://github.com/OpenTracksApp/OpenTracks/issues/437, https://github.com/OpenTracksApp/OpenTracks/issues/240, https://github.com/OpenTracksApp/OpenTracks/issues/185, https://github.com/OpenTracksApp/OpenTracks/issues/575, https://github.com/OpenTracksApp/OpenTracks/issues/660

[rgmf]

I'd also add this one: https://github.com/OpenTracksApp/OpenTracks/issues/936

So the complete list would be: https://github.com/OpenTracksApp/OpenTracks/issues/1088, https://github.com/OpenTracksApp/OpenTracks/issues/1078, https://github.com/OpenTracksApp/OpenTracks/issues/983, https://github.com/OpenTracksApp/OpenTracks/issues/937, https://github.com/OpenTracksApp/OpenTracks/issues/437, https://github.com/OpenTracksApp/OpenTracks/issues/240, https://github.com/OpenTracksApp/OpenTracks/issues/185, https://github.com/OpenTracksApp/OpenTracks/issues/575, https://github.com/OpenTracksApp/OpenTracks/issues/660 https://github.com/OpenTracksApp/OpenTracks/issues/936

Shall we create a Project (https://github.com/OpenTracksApp/OpenTracks/projects) for UI refactoring?

I could create it and add all these issues and other stuffs.

[dennisguse]

@rgmf Great idea!

[rgmf]

@dennisguse Created here: https://github.com/orgs/OpenTracksApp/projects/1

For the moment I grouped all UI/UX related issues.

I uses the new Projects feature for organizations: https://docs.github.com/en/issues/trying-out-the-new-projects-experience

[dennisguse]

Guess this is obsolete.