Add a drop-down for switching between presets

[matkoniecz]

At least in my case my initial attempt was to click on the preset name ("Preset: Default") as shown in quest selection menu

[westnordost]

Not sure if this is possible (without hack)

[westnordost]

But if it is clickable, I think what may be closer to the user expectation would be a popup menu where you can quickly select a preset? (Maybe replacing the selection-mechanism on the "manage presets" page?)

[matkoniecz]

Not sure if this is possible (without hack)

I think it should be, is there any reason why standard solution like #1478 would not work? (I have not looked at code for now! Just wanted to answer question asked on POEditor)

[matkoniecz]

I think what may be closer to the user expectation would be a popup menu where you can quickly select a preset?

At least I would expect regular preset menu... Note the first use when no other presets are existing except default...

[smichel17]

Ref: #3216 (comment)

What I said in #3034 (comment) still holds, I'm willing to implement something like that (or #3034 (comment)).

Due to the way the settings are constructed, there's no easy way to add a click listener to the {sub}title text. All settings screens are under a single FragmentContainerActivity, so they all use the same layout which includes a generic toolbar as the actionbar/appbar/whatever-Google-wants-to-call-it-now-bar. Compared to #1478 where there was a unique layout for that screen. Of course it's possible to refactor, it's just more work.

[mnalis]

While I too agree it would be nice and logical shortcut, I think it is important to also keep the current ... / Manage Presets (it is less confusing for users when all features can be accessed via standard interface too, even when there are other ways).

[westnordost]

Hm well, I am a proponent of that there should be one way to do something in an app, not several options. See also what @rugk posted in that other issue: #48 (comment)

[mnalis]

@westnordost and I would wholeheartedly agree to have only one way to access a feature, if the proposed change was to use standard / well known Android interface. But IMHO it is not (at least I don't think I've often been in situations when clicking on the text of titlebar of some window produced dropdown selection list).

Thus I'm afraid it might be not discoverable for average user if non-standard way was the only way to access the feature.

(I know you don't usually like what-aboutism, but it looks to me kind of like when "two-finger drag" to change tilt in SC is not very discoverable, so we have click-on-compass-icon-to-tilt as extra way to do it)

While I don't feel that having additional shortcut to access some feature is same as adding more preferences (which is what #48 (comment) talks about - I seem to remember that even Gnome, which the article is based on as do-not-have-much-preferences example, has two ways to access Settings menu - via topright triangle, and via right-click context menu - but I digress) I do acknowledge that it is preferable to have only one way to access most features.

The question is does the non-standard UI warrant that the feature can also be accessed via standard UI.

Maybe if non-standard UI was made to look more like regular UI (eg. adding a triangle in menu is it looks like dropdown menu) might help somewhat? (IMHO it still looks too hackish and non-intuitive to new users, and implementation also would also be somewhat hackish)

---

Cleaner solution which keeps only one way to access the feature would be to rearrange the UI a litle so it only uses standard Android UI (even it uses a little more screen estate), like moving Preset name from title to a more standard dropdown element below it. For example see @FloEdelmann mockup in #3034 (comment) which looked fine in that respect to me. (even if you don't want to adopt the rest of suggested changes due to "too much work").

Doing it that way would additionally preserve useful info we previously had in the title (eg. 86 of 111 enabled), which we lost in current quest preset branch (as it was replaced with Preset: xxxx text).

[Helium314]

Doing it that way would additionally preserve useful info we previously had in the title (eg. 86 of 111 enabled), which we lost in current quest preset branch (as it was replaced with Preset: xxxx text).

Actually (for me) the number of enabled quests is shown below the selected preset, so nothing was lost.

[westnordost]

Well let's say the preset selector would be a dropdown below the title.

Then, to select the currently active preset wouldn't make sense in the separate screen.

So the only functionality that remains in that screen is to add new presets and delete presets. (And renaming presets, if anyone is going to implement that. Any takers, @mnalis perhaps; or who proposed that? It's easy to implement, but I decided I spent enough time on this particular feature already. If you guys want improvements on this feature, it would be nice if you showed you are invested in it.) Hm well, fair enough, I guess.

Does anyone have any arguments for not moving the current-preset selector into the quest-selection screen?

[smichel17]

I maintain my offer to implement the dropdown… (although I'd be happy if @mnalis or @Helium314 wanted to help 😉)

One question: right now the preset isn't shown unless you have more than one. In the case where people only have one preset, should we hide the dropdown and add an "add preset" option to the overflow menu?

[westnordost]

Sure, go ahead! The comment targeted at @mnalis et al was referring to renaming presets.

Yeah, in that case, the dropdown should not be shown. I imagine the "Manage presets" item would remain in the overflow menu. As said, in that screen, one can still add, delete (and rename) presets.

[smichel17]

Okay. No promises about exactly when I will get around to this, as I have a couple of other projects on my plate (and am job searching). I will post here when I begin implementation, so it's safe if someone else wants to start on this instead.

[mnalis]

@westnordost sure, I can give it a try at adding rename functionality after @smichel17 does the dropdown rewrite (doing complete rewrite myself is waaay above my head, as someone whose only experience in Android programming has been copy/paste so far 😃). And of course, I can help with testing.

[smichel17]

Adding search terms & clarifying: I plan to add the ability to rename filters when I do this. But still no ETA, and I'm starting a new job this week so my time may be more limited going forward.

[NotSoImportant]

Once I had created some presets I noticed I need to see which one is currently selected on the main screen. So could we - maybe only in case not the Standard is selected - have the current profile shown on the main screen (maybe middle top) and be able to quickly change them on a tap?

[mnalis]

@NotSoImportant I would also like that very much, but see #3827

[westnordost]

I'll close this as the quest presets management screen is now directly accessible from the settings menu (not hidden in some context menu within the quest selection screen)

[NotSoImportant]

Not sure, but I cannot find this in 48.0
Could you show a screenshot, please?

[FloEdelmann]

It will be part of v49, see 9eee41f

[NotSoImportant]

V49 beta