Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

abcd letters as separate keys for mapping house numbers #5479

Open
canfe opened this issue Feb 9, 2024 · 10 comments
Open

abcd letters as separate keys for mapping house numbers #5479

canfe opened this issue Feb 9, 2024 · 10 comments

Comments

@canfe
Copy link

canfe commented Feb 9, 2024

Use case
When mapping house numbers that have an "alphabetic extension" such as: 45b, it is not convenient to use the full keyboard to look up the latin letter you need.
Proposed Solution
It would be helpful to have the first 3-4 letters of the alphabet highlighted as separate keys. This would solve the great majority of cases.

@westnordost
Copy link
Member

westnordost commented Feb 9, 2024

I strive to have the UI as clean as possible, i.e. be very cautious about adding any buttons that are not necessary. I see several reasons for not adding such buttons:

  1. Adding 3-4 buttons to make it marginally faster to answer the housenumber question for an estimated 5% of housenumbers doesn't seem proportionate to me. An other case where such quick select buttons exist is the building levels quest, but there, one uses these button in the vast majority of cases, I'd guess 90% of the time.

  2. These [a] [b] [c] [d] buttons would roughly have the same size of the same buttons on the keyboard, which is already displayed. So, it really just saves one tap on the [ABC] button and if the user already tapped on that button, it is a duplication

  3. At least for certain countries, the form is actually quite stuffed already, e.g. in Japan where addresses also have an associated block number or Slovakia where addresses may also have a conscription number. At the very least, these buttons would need to be displayed in an own row, which may be confusing when displayed together with the street name input (in the address overlay), as there is no clear indication what these alphabet-buttons refer to.

@mnalis
Copy link
Member

mnalis commented Feb 9, 2024

I understand where OP is coming from, but I also see the problems with suggested solution...

For example in Croatia, it is also possible (although less popular) that instead of 45b you might have 45-1 or 45/1, so - and / would need to be added too, and if the letters are used, in many cases (urban areas) it is because it is a row of apartments building entrances, in which cases at least a-f would be equally popular (or even a-k). Adding all of those buttons would be too much.

And obviously having totally different keyboard for each country (or even city!) would be undesirable.


What perhaps might help in some cases is:

  • to remember last keyboard used? E.g. if last number entered was using full-keyboard, on next start of Housenumber quest start with full-keyboard instead of numeric keyboard? That would save one click in countries where there are many apartment houses (condos) with multiple entrances like 45a, 45b, 45c etc (like Eastern Europan ones?)
  • alternatively, if address ends in a letter, perhaps + / - buttons should not increase the number, but update the letter instead (e.g. pressing + on 45a would change it to 45b, but pressing - on 45a would change it to 45 as there is no letter below a. Pressing - on 45 would work as currently, changing it to 44)

But then again, those two ideas might be somewhat unwanted in countries which use primarily only numbers and only add occasional a or b when e.g. the new building or two are inserted in between existing ones. But I think it still would be net improvement.


  • What would work ideally for me personally, is to have + / - buttons which work as they do now (increase/decrease the number), but also have a+ and a- buttons which would increase/decrease letters (adding or removing them completely as needed). So e.g.

    Button Old value New Value
    + 45 46
    + 45a 46
    - 45 44
    - 45b 44
    a+ 45 45a
    a+ 45a 45b
    a- 45b 45a
    a- 45a 45
    a- 45 45

But maybe having extra 2 buttons might be confusing for newbies? 🤷 Probably still better then adding 4+ new ones, or at least using less screen estate / easier to fit in UI...

@canfe
Copy link
Author

canfe commented Feb 10, 2024

  • What would work ideally for me personally, is to have + / - buttons which work as they do now (increase/decrease the number), but also have a+ and a- buttons which would increase/decrease letters (adding or removing them completely as needed).

great idea!

@thiemowmde
Copy link

I'm currently mapping a German city with a lot of house numbers like 45b. A small improvement that would save one or two extra button presses each time is to automatically open the full keyboard instead of the numeric one when the previous house number ends with a letter.

@westnordost
Copy link
Member

In other words, make the ABC-button appear and work like a toggle button, memorize and re-apply the previous state of it when next opening the form.
This sounds good, however, this means it is necessary to switch back when the ABC-numbering changes to the next housenumber. Do we have some numbers? How likely is it that if a housenumber with an "a" is encountered, there will also be a "b"?
If that probability is less than 50% or around 50%, this suggestion would actually make the UI worse.

@mnalis suggestion sounds fine, but I am not sure if it fits and/or if it wouldn't confuse users. The buttons should probably not be titled a- / a+ though, but bear the actual letter it would apply to the housenumber. (E.g. for housenumber 43c, the buttons would show [b] and [d]).

@canfe
Copy link
Author

canfe commented Feb 12, 2024

@westnordost If housenumber 43c, the buttons would show [b] and [d], but if the next number is pure 45, it would be functional to click on the previous displayed number, i.e., 43c and then on the + button to increase only the digits without the Latin characters.
Basically the layout would not be changed, only the functionality.

@mnalis
Copy link
Member

mnalis commented Feb 13, 2024

Do we have some numbers? How likely is it that if a housenumber with an "a" is encountered, there will also be a "b"?

Quick calculation shows the global distribution of b housenumbers compared to a housenumbers is about 41%.
(I'ts not really precise, because it doesn't really look at closeby houses but just at numbers followed by letters. And it probably significantly differs by countries, so people can run the script on their own country to get the idea)

@mnalis suggestion sounds fine, but I am not sure if it fits and/or if it wouldn't confuse users. The buttons should probably not be titled a- / a+ though, but bear the actual letter it would apply to the housenumber. (E.g. for housenumber 43c, the buttons would show [b] and [d]).

Yes, that sounds like better idea to me:

  • when housenumber is e.g. 43 it would show only next-button a (to advance to 43a)
  • when housenumber is e.g. 43z it would show only prev-button y (to decrease to 43y)
  • when housenumber is ending in any other letter e.g. 43d, it would show both prev-button 43c and next-button 43e.

And it would only cost space for two buttons while covering majority of usages. Something like this:
housenumber_letters_s

Or maybe even move + / - buttons on the left side of housenumber to reduce misclicks?

@westnordost
Copy link
Member

Thank you for the numbers! By the way, I think this is potentially a use case in which sophox or qlever could provide an answer within (milli)seconds.

That's quite a lot of buttons, though. Hmm. How would that look like in Slowakia and other regions where the housenumber layout takes up more space? Anyway, to put the +/- on the left side in case this is implemented would make sense. The ABC-button should probably also be replaced with a dedicated icon showing a keyboard (+ABC in small) to reduce confusion.

@mnalis
Copy link
Member

mnalis commented Feb 20, 2024

Thank you for the numbers! By the way, I think this is potentially a use case in which sophox or qlever could provide an answer within (milli)seconds.

Perhaps, but it would take me significantly more time to learn SPARQL then milliseconds 😃

How would that look like in Slowakia and other regions where the housenumber layout takes up more space?

private fun getCountrySpecificAddressNumberLayoutResId(countryCode: String): Int? = when (countryCode) {
"JP" -> R.layout.view_house_number_japan
"CZ" -> R.layout.view_house_number_czechia
"SK" -> R.layout.view_house_number_slovakia
else -> null
mentions 3 countries with separate form:

  • In Slovakia in particular, the current UI in SC does not seem to implement even current + / - to increment/decrement housenumbers (nor does it remember previous value, instead opening with blank form on every new house), so I guess they would not get buttons for house-letters either.

  • Czechia has HousenumberQuest disabled, but Address Overlay is similar as in Slovakia, without +/- buttons.

  • Japan looks mostly similar to general case, but has an additional block number, so it should be easy to add too. However, I do not see housenumbers ending with alphabetic letters there, so I'm not sure if would be worthwhile implementing it in that form too (perhaps someone with more experience with Japan will chip in).

The Slovakia & Japan forms currently look like this:
small_Screenshot_20240220_183053_StreetComplete small_Screenshot_20240220_182204_StreetComplete


TL;DR: I think that just the general form would need improving (at least for now). Mockup could look something like this (keyboard icon taken from opening hours quest):

housenumber_letters_s

@rhhsm
Copy link

rhhsm commented Apr 9, 2024

Japan looks mostly similar to general case, but has an additional block number, so it should be easy to add too. However, I do not see housenumbers ending with alphabetic letters there, so I'm not sure if would be worthwhile implementing it in that form too (perhaps someone with more experience with Japan will chip in).

If they would distinguish households sharing the same house&block number, they would be unlikely to use Latin script for it :) But they don't: households sharing the same address are distinguished by the family name on the letterbox. So the UI for Japan can be kept as it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants