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.

[westnordost]

Hm, the current behavior has been implemented the way it is now after many iterations on going forth and back and is consistent for different quests, i.e. the buttons order behave the same for AddBuildingLevels, AddFireHydrantDiameter, BuildingsOverlay and AddBuildingType:

First, the most recently selected item is always displayed at the left-most position. For all other positions in this button bar, the most-used selections within the last fifty edits are used.

I remember that this "most recently selected item always on the left" was added later because users reported that they found it inconvenient that the last selection would not appear in the context of the building levels quest: It is much more likely that two neighbouring buildings have the same levels than as the majority of nearby buildings.

If the most recently used answer was not displayed always on the left, we can have a situation where there are three buildings in a row that have different levels as other buildings in the neighbourhood and the quick-select-button-bar wouldn't help at all.

Or for the building overlay, imagine you pass from a residential area into an allotment area. After you selected the first allotment building, you want to have this shortcut immediately at hand, not some iterations later after the allotment building slowly becomes more popular amongst the last fifty tagged buildings.