Building Overlay: Don't reorder the buildings quite so often

[tordans]

Use case

I was using the new buildings overlay today and noticed, that I frequently miss clicked the building type because I expected it to still be on the same position as before.

Proposed Solution

I get that some reordering has to take place in order to change the last used buildings. However, I suggest to not reorder the list when one selects a building from that list.

[rhhsm]

This is how StreetComplete behaves in some cases, while in other cases the order doesn't change at all. I got used to this and learnt that I should always check if I'm tapping the right icon (which is a good thing). Maybe the best compromise between these two behaviours is if the total number of answers given by a user is taken to order the list. When first starting with a particular quest, the ranking changes often with each quest solved, but after some time it won't change as often until a large number of quest answers have been given. The result will be a ranking that doesn't change any more, but is still personal for each user. Would this be possible to code?

[mnalis]

When first starting with a particular quest, the ranking changes often with each quest solved, but after some time it won't change as often until a large number of quest answers have been given. The result will be a ranking that doesn't change any more, but is still personal for each user. Would this be possible to code?

I seem to recall that some quest (I think "building number of floors" maybe?) had extensive work at one time which tried several different approaches and tweaks on how to cache the order of "recently used", before settling at current behaviour, which I think is behaving more or less like you describe.

I don't know if building overlay reuses that logic or has its own independent one. Perhaps that recent-answers logic could then be abstracted and used in multiple quests (if that isn't already the case)?

[Helium314]

BuildingOverlay also uses LastPickedValuesStore.
See description of mostCommonWithin for how it should work.

[tordans]

I can share that from what is taught in interface design and interaction classes that …

• …the order of things should not chance (as little as possible) to enable (short term) muscle memory
  There are (old) models from when HCI was "invented" that put this into calculations and one rule of thumb is, whenever you make users think before doing something, your UI takes a big efficency hit. The classic https://en.wikipedia.org/wiki/The_Humane_Interface has a chapter on KLM/GOMS to learn more.
• …any modality is to be avoided. Jef Raskin explains this very well. So any solution that make the app modal like an expert mode or some artificial counter after which the UI behaves differently would make the situation worse.

In this case I don't see any downside in doing less…
Just don't reorder the "last pick" to the front of the line.