pheara
commented
9 years ago A rudimentary version of the single-line address-search-field has been implemented as of deab2d7, however the ux needs some polishing. I'd think it would be best if the interface behaved as following:
Suggestion for A Usage Workflow
1) After the first word's been finished (a space-character has been entered) or when the user stops typing for 2 seconds the query get's send to the server 2) while the http-request is in progress the drop-down is visible and shows a spinning wheel (to communicate that it's working) 3) the request returns, the drop-down gets populated with matching addresses that nominatim could resolve 4a) continuing to type queries nominatim again (see (1)) 4b) select one of the alternatives (using arrow-keys or the mouse) 5) the selected location replaces the query-text in the text-field and is shown on the map
Only Resolvable Addresses (Design Question)
The system needs a location in the form of longitude and latitude. If the user doesn't select an entry from the drop-down those might not be defined. There are a two alternative ways we could deal with this:
- if none has been actively selected, use the first one. I'd put the blue highlight on the first entry in the drop-down to make that clear.
- not use the location when publishing a need unless it's a valid location
- we could display a green checkmark or sthg similiar next to the search-field if a valid location has been selected (like the wienerlinien-page / quando does)
Personally i think the second would be cleaner and more predictable for the user (e.g. when deleting the text to reset the location input)
Open TODOs
Must-Haves
- Empty Result Sets: If the location can't be resolved (because it doesn't exist in any of the osm databases), we need to show some kind of error message, e.g. in the drop-down.
- filter for duplicates
- limit to 5 displayed unique results (anything beyond is clutter + the search query can be refined anyway). the alternative would be to implement scrollable dropdowns but the usability would be really low imho.
- error handling (e.g. in case nominatim changes it's API)
- make sure json-structure actually is as assumed
- fix the graphical glitches the markers' popups cause to the markers themselves
- maybe changing the marker implementation helps.
- might require patching the leaflet code
- make the foldout-box, search-field and map seperate directives (field and map might be better as a single one though)
Nice-to-Haves
- show all results on the map and highlight the one / zoom in on the one that the mouse hovers over (in the drop-down)
- highlight typed text in result strings (by placing 's around it)
- show spinner in folded out drop-down while http-request is loading
- bind down button to open the dropdown (to prevent the browser's own autocompletion from showing/overlapping
- hide results with a really low score behind a "show more"-fold? (to filter out bogus results)
fkleedorfer
tl;dr there's many different address formats, which is hard to handle in a UI.
On Address Forms
The address form as it's sketched atm assumes an ecommerce-like address form with separate fields for street, city, country, postcode (or "postal code" / "zip code" / etc for some countries) as opposed to the alternative, a single field (like osm and google maps use). @cbusch assumes (an educated guess) that the former is easier to use for people with less tech experience (who're more likely to have used old-style addresses and -forms on letters and home-shopping than say gmaps). I couldn't find any empirical research on this and would love to try and compare the two alternatives in say an A/B test.
So the plan is to implement the classic-version (first). This will result in some technical difficulties which I'll try to sketch out and document below.
Here's a purportedly really good overview over different postal systems if you want to dive into it in depth: http://www.columbia.edu/~fdc/postal/
Ux Patterns
Issues to Tackle (Classical Form)