Make it faster to answer the building levels quest

[smichel17]

Use case

Building levels is a very common quest in residential neighborhoods, that could be faster.

Proposed Solution

Note: this is a rough mockup -- eg, I was just copy-pasting and the rows are not quite aligned.

Pressing any button switches to the current quest view.

• For the 6 on the left, the behavior is the same as the current one: the fields would be pre-filled and the keyboard is not opened.

• For the blank one on the right, the keyboard would be opened like this:
  • This keeps the number of taps for custom building height the same as it currently is.

Discussion

The slowest part of this quest is when you have to open the keyboard, since that introduces a delay. This solution gives more pre-fill options so you don't have to open the keyboard as often. You still go through the regular entry screen, so new mappers will still see the text, "regular levels (not counting the roof)" and "levels in the roof".

My original idea was to use have the same behavior as above, but show recently used heights instead of a static grid. I opted for this instead because it will be better (consistent positions) in rural, residential environments, where this quest is common. In urban environments with tall buildings, buildings are more varied and also larger, so this quest appears less frequently and recent options are less likely to be useful.

I think there may be room for improvement. For example, we could swap the axes of regular vs roof levels and allow scrolling, if 3 regular levels is not enough for common use cases.

[HolgerJeromin]

This should probably only be shown after x solved level quests. X == 10 or higher

[smichel17]

That's also an option. I'd put X==${numRequiredForAchievement}

[westnordost]

Hm to be honest I am not too convinced about this. It feels there is too much happening there (= layout changes) then. I know that just opening the keyboard can be very disruptive. Maybe there is another way to avoid the keyboard.

[Sequynth]

Maybe there is another way to avoid the keyboard.

Hmm, how about this:
When the user presses the thumb on the house and moves the thumb upwards, the number of building:levels increases. If the thumb is released this number is set and another press-and-slide increases the number roof:levels.

This comes with two problems:

1. How to immediately fix a wrong input?
   It may be that one slides too far (or short) and building:levels is not correct and a new press-and-slide would already change roof:levels.
   Either an initial downward motion reduces the previous input-value and subsequent upward motion increases it again, or there are 2 separate 'stripes', one changes building:levels, the other changes roof:levels. This still has to be made clear to the user

2. What about very tall buildings (10+ levels)?
   It could be that one runs out of screen-space or it will be very cumbersome to enter large values. For this one could just keep the old functionality of opening the keyboard when clicking on the edit field. (From experience in my area this wont be necessary very often...)

This functionality must somehow be conveyed to the user. The current UI for this quest is nice and clear, also explaining the interpretation of difficult cases, when the ground floor isnt the ground floor on all sides. Adding arrows that indicate the proposed functionality can clog the whole UI. Is there a possibility for tutorial animation the first time a quest is used?

[peternewman]

* For the 6 on the left, the behavior is the same as the current one: the fields would be pre-filled and the keyboard is not opened.

Sounds good to me, but why don't they just auto-answer at that point, why the extra step?

[smichel17]

why don't they just auto-answer at that point, why the extra step?

Because the very first time someone encounters the quest, they don't know what the two numbers mean. We need to make sure they see the additional descriptive text.

However, I am agreeing with @westnordost here that there is probably a more elegant solution to avoid opening the keyboard, I just don't have the time to think deeply about it right now.

[peternewman]

why don't they just auto-answer at that point, why the extra step?

Because the very first time someone encounters the quest, they don't know what the two numbers mean. We need to make sure they see the additional descriptive text.

But that goes away if you've completed the quest ten times or whatever.

However, I am agreeing with @westnordost here that there is probably a more elegant solution to avoid opening the keyboard, I just don't have the time to think deeply about it right now.

This seems pretty good to me, most residential buildings that aren't some kind of tower block will be covered by those six answers in a lot of places and it's much faster than having to do any form of data entry in those cases. Although I'd probably agree there might be a more efficient means of data entry for other cases although I'm not convinced some kind of scroller/roller would actually be much faster than a numeric keypad for all other cases (e.g. 20 storey building).

[xuiqzy]

Some input:

If the problem is to not confuse the beginners, maybe a little switch / shortcut icon could be made that switches to the shortcuts for the most common answers and stays that way for the default view for future quests until switched back (perhaps still with a manual entry button). That way it could even be reasonable to accept the answer with 1 click without another click on OK, maybe with the answer numbers or a visual house with the correct heights staying around a little before disappearing.
If that button is discoverable enough, the need to use it should come up naturally when solving many quests.

For every input method, there is the possibility to change the visuals of the displayed house to reflect the entered values, that could help depending on the rest of the design.

I kind of like the idea with the slider and can see that as a quick input method that can fit in visually.
As an alternative, there could be a few of the most common numbers (likely just the lowest numbers) besides the input field, although that would still require 2 clicks when answering the same few answers.
Maybe this could even be the default way to input the numbers, because it can be used for most of the answers and a numeric field as fallback and only then the keyboard pops up.
Instead of the buttons it is also possible to use a spinning wheel like in the date and time pickers in android, although that would probably slower and more annoying for the small numbers compared to the buttons.

[IAmTheWebb]

I was completing a few of these quests last night and I thought simply remembering the last digits used would suffice, I can then click the number to change to any other number then that number will persist as the preselected option until I choose to click the digit again to change.

[alistair-marshall]

I was completing a few of these quests last night and I thought simply remembering the last digits used would suffice, I can then click the number to change to any other number then that number will persist as the preselected option until I choose to click the digit again to change.

Yes! I was thinking something similar. Remembering the last values would have made it much easier.

[peternewman]

that number will persist as the preselected option until I choose to click the digit again to change.

Yes! I was thinking something similar. Remembering the last values would have made it much easier.

Not quite what either of you asked for, but I thought I'd mention it as I'd missed it until very recently; there's a button on the bottom right hand side which lets you pre-fill the last entered height information in one go.

[smichel17]

there's a button on the bottom right hand side which lets you pre-fill the last entered height information

That's why the issue is about adding more pre-fill options :)

[alistair-marshall]

I hadn't spotted it. That will definitely make things easier.

Thanks.

Though does it raise another issue that the button was too subtle (or in the wrong place) for us to spot? If it was just me, I would ignore it, but I now wonder how many others have missed it.

[peternewman]

Though does it raise another issue that the button was too subtle (or in the wrong place) for us to spot? If it was just me, I would ignore it, but I now wonder how many others have missed it.

Yeah, possibly some animation of those values into the pre-fill for the first ten times would help or something, or a message for the first few. For me I guess the bottom RHS seemed quite busy with the roof levels tile and the ground profile. Or a pre-fill/"last used" label next to the button?

I assume there's no logging of pre-fill versus custom entry in the stats?

[ModProg]

I think something like this is badly needed, I filled out some house heights yesterday and they constantly switched from 1/2 to 1/1 to 2/1. So the last used button didn't help at all.

My Idea would be to either long press the last used button or pull it up, to reveal more buttons.
As there is a undo button I think we can at least enable the user to commit without pressing ok.

[westnordost]

Here is an idea for a possibly fun completely new interface : Drop the "last selected value" button, drop the description texts and drop the text inputs. Instead, you can stretch the building up and down like an accordeon, both for the building part and for the roof part.
Difficulties:

• may interfere with the bottom sheet logic
• for very high buildings, this interface is not that well fitted. But that's the vaast minority of buildings
• question is how to start the interface - if with 0, one doesn't have a handle to pull the accordeon apart

[peternewman]

Here is an idea for a possibly fun completely new interface

I hope you're joking! I find I miss pressing the correct number often enough without having to drag something to the right amount! I'd say most buildings I input are < 3 storeys, how does that scale to ones that are even ten, let alone more?

[peternewman]

So having just done a bunch of surveying in an area of terraced houses, I'm even more strongly in favour of this (or at least a couple) of pre-set answers. While SC was certainly faster than other means, the terraces had two storey buildings at either end and one storeys with dormer windows in the middle, along with more normal two storey terraces, I'm also tagging roof lights as being a level in the roof (but not otherwise), so I was using a combination of 1/1, 2/0 and 2/1 and switching between them was definitely the slowest bit. I kept pre-tagging the 2/0s to then go back to do all the 1/1s in the middle.

[Echolon]

For the custom entries there could be + and - buttons to increase or decrease the level number.
The shown start value could be the average level number queried from the surrounding building.

I just wanted to say that I like the mock-up!

[IpswichMapper]

I agree there should be the seven buttons that were originally proposed. Most residential houses have between 1-3 floors, and either 1 layer of roof or none.

Already, entering housenumbers is tedious and slow, and that is only one number being entered. I can't imagine how tedious entering two numbers for every single house is.

Taller buildings are more sparse, and you have to spend more time counting the number of floors, so effeciency isn't as important.

Currently, you have to click on the quest, and then on the textbox to bw able to start entering.

With the seven button system, the keyboard could automattically open when you oress the button on the far right, so either way you have to press twice to start entering numbers manually.

@westnordost

Any updates on this? Will it be happening?

[westnordost]

No updates from my side. This ticket was created my @smichel17

[ModProg]

Maybe one could make a setting somewhere to customise, in my neighbourhood a lot of houses have 2 floor roofs.

[IpswichMapper]

Maybe one could make a setting somewhere to customise, in my neighbourhood a lot of houses have 2 floor roofs.

Can you show me a house like this? How does a roof have two floors?

[ModProg]

Maybe one could make a setting somewhere to customise, in my neighbourhood a lot of houses have 2 floor roofs.

Can you show me a house like this? How does a roof have two floors?

[IpswichMapper]

Oh,ok. Thanks

[HolgerJeromin]

https://www.dach-holzbau.de/artikel/bhw_Dach_bis_zum_Boden_2562198.html has even images of buildings with roof:level=2 and building:level=0

[goldfndr]

Similar to iD long ago, could a radial menu suitable for swiping work? Animate selections on finger press, open keyboard if finger released without significant movement. Here's a crude visualization.

[Echolon]

Another option would be to add a plus and minus button somehow similiar like for house numbers

[westnordost]

It'd need to be 4 buttons then. There'd be enough space for it (on normal-sized phones) left and right of each input field but then the interface is really packed. Also, it works well for the housenumbers because the housenumber you are going to input is never the one you entered before but usually one or two up or down. This is not hte case for building levels.

[smichel17]

I would like input on the following from someone who lives/maps in a city.

It'd need to be 4 buttons then.

What if there were only a + button? It would always start at 1 and count up. "Down" functionality can come from an undo (or clear) button in the center-ish. My main concern is that it may be too easy to accidentally hit OK when you mean to hit undo/clear. Edit: I guess putting it on top of the house image would fix that.

It would also not be terribly useful in areas with high buildings… but in that case, how often are the building levels uniform enough that +/- buttons would be useful, anyway? At some point, the building is tall enough that it is faster to open the keyboard.

The previous answer pre-fill can stay the same, or tapping it could show more options, like in my original mockup but with recent answers instead.

[peternewman]

I would like input on the following from someone who lives/maps in a city.

I do some city stuff (e.g. townhouses) and the occasional more skyscraper type thing.

It'd need to be 4 buttons then.

What if there were only a + button? It would always start at 1 and count up. "Down" functionality can come from an undo (or clear) button in the center-ish. My main concern is that it may be too easy to accidentally hit OK when you mean to hit undo/clear. Edit: I guess putting it on top of the house image would fix that.

That wouldn't work for my town scenario here (there are terraces of 1/1 houses bookended with 2/0 at either end), so you'd have to keep resetting and starting over:
#1772 (comment)

It would also not be terribly useful in areas with high buildings… but in that case, how often are the building levels uniform enough that +/- buttons would be useful, anyway? At some point, the building is tall enough that it is faster to open the keyboard.

It depends what you mean by high buildings? Thinking of town houses near me say 4-6 floors high, there are often a number together that are the same height, but there will be some which are a bit, or a lot, lower or higher. That's probably different in a far more built up city.

[smichel17]

(there are terraces of 1/1 houses bookended with 2/0 at either end), so you'd have to keep resetting and starting over

I think this might be a misunderstanding of the proposal, perhaps caused by my hasty mockup. Here's a slightly less hasty one (but still hasty — none of them should have the keyboard open and the bottom-right should have buttons like the bottom-left)

• The top-left image is what I imagine it would look like when the form opens.
  • Pressing the square button on the right takes you to the right.
    • From there, selecting [2/1] would take you down.
  • Pressing the (+) button on the left once would take you down.
    • From there, pressing each of the (+) buttons once would take you right.
      • From either of the bottom images, the reset button would take you back to the top-left.

In other words, in the scenarios you describe,

• For the 2/0 terraces at each end, you'd tap the left (+) twice, then ok
• For the 1/1 terraces in the middle, you'd tap each (+) once, then ok
• For the town houses, you'd tap the "recents" button, select one of the 6 entries, then press ok
  • If there's more than 6 variations, you'd be stuck with the current workflow, or picking a recent variation that's slightly shorter and tap the (+) buttons a few times.

I think that's a pretty reasonable compromise between number of taps, amount of buttons on screen, and how often you need to open the keyboard. The keyboard is the key (:roll_eyes:) consideration here, because it's only worth optimizing the interface if you can make it faster than the baseline of "just use the keyboard". This is faster (I think?) for buildings with few levels and for neighborhoods with 6 or fewer variations. I'm not sure it's possible to get faster for neighborhoods that are both tall and varied.

[smichel17]

Or maybe we're over-thinking this. What about a row of buttons with numbers (1-5) on them along the bottom? Pressing the button fills in that number for the selected field and swaps focus to the other field. If you need to go higher, use the keyboard.

Alternatively, four buttons at the bottom (+1 / +2 / +3 / keyboard), a clear button next to each field that's filled in, and tapping on the field just selects it without opening the keyboard (which you'd do via the keyboard button instead).

[peternewman]

I think this might be a misunderstanding of the proposal, perhaps caused by my hasty mockup. Here's a slightly less hasty one (but still hasty — none of them should have the keyboard open and the bottom-right should have buttons like the bottom-left)

That makes sense now, although doesn't feel hugely intuitive to me personally as to how that button represents recent entries.

In other words, in the scenarios you describe,

* For the 2/0 terraces at each end, you'd tap the left (+) twice, then ok

* For the 1/1 terraces in the middle, you'd tap each (+) once, then ok

I think that's a pretty reasonable compromise between number of taps, amount of buttons on screen, and how often you need to open the keyboard.

Maybe it's my fat fingers, or small screen, but I often seem to manage to miss-press stuff, especially if doing it while walking (e.g. selecting the surface type under the okay button, rather than okay). I think for me, the recents would be more accurate than having to keep double-tapping to get to 2 and 1. Also don't we need a zero for the roof otherwise I thought it just doesn't tag it?

Or maybe we're over-thinking this. What about a row of buttons with numbers (1-5) on them along the bottom? Pressing the button fills in that number for the selected field and swaps focus to the other field. If you need to go higher, use the keyboard.

I think this would need a 0 for the roof again? I guess potentially for the non-roof floors too.

Alternatively, four buttons at the bottom (+1 / +2 / +3 / keyboard), a clear button next to each field that's filled in, and tapping on the field just selects it without opening the keyboard (which you'd do via the keyboard button instead).

You don't need a keyboard button do you, as you can tap in the field to enable the keyboard?

I'm not sure it's possible to get faster for neighborhoods that are both tall and varied.

I think this is probably true. Any optimisation only really works for terraced/semi/detached houses. I guess the edge case is needing a recent for estates of likely low-rise tower blocks, which are all built to the same height. It's perhaps all missing the key thing, if you've got a 10 storey block, it already has a far greater population density so there are likely to be fewer of them (with a few notable international examples), the benefit to this optimisation is when you have many streets of identical or near-identical houses. Also the whole time to count floors versus enter data consideration.

[mnalis]

@smichel17 I agree it would be best not to over-engineer.

IMHO, just a multi-choice for recent houses (instead of currently available single-last-recent choice) looking mostly like depicted in your top-right image would probably be good enough for me. In vast majority of cases where I go, there are 2-4 different types/heights of houses that repeat all over again.

So multi-choice for several (6?) recent heights would solve 95% of annoying repetitive work that I had to do (before I disabled that quest as too unergonomic), and 5% that remains would be rare enough to be fine even if its UI is not perfect.

[HolgerJeromin]

What about such an interface (taken from the time selector of vespucci)? Each on both sides of the house:

[ModProg]

What about such an interface (taken from the time selector of vespucci)? Each on both sides of the house:

Looks not bad actually, and clicking the middle number opens the keyboard

[peternewman]

What about such an interface (taken from the time selector of vespucci)? Each on both sides of the house:

While a spinner or similar might be quicker for data entry (especially for say the taller buildings). I think there is still some other optimisation possible for repetitious estates/roads of non-high-rise buildings as the other part of what we've been discussing. That almost feels like a separate enhancement to me (and it's already used on the lanes quest, so it has commonality there).

[FloEdelmann]

I implemented the suggestion from @mnalis's comment in #2925. Tell me what you think there :)

[westnordost]

All: Please check out @FloEdelmann 's pull request and let him know what you think. There are pictures too.

[smichel17]

@FloEdelmann I've finally gotten the chance to go mapping with this improvement and it makes a huge difference. 100% satisfied. Thanks!