Default filtering "Search Area" as "Current view"

[MikiDi]

When opening the app for the first time, a user is presented with the map at zoom level 0. An amount of notes are shown on the map. The most natural first-use pattern I imagine is zooming to an area of interest and clicking "refresh". Without having read through the entire filter modal, the results one now gets are unexpected and there's nothing to hint the user why this is happening. If you're lucky, one note may show in your current view, maybe none. At the point where I was about to give up, the "Search Area" filter option caught my view.
To me, this experience gave a buggy impression, while the app actually works great!
I'd advocate for setting the "Search Area" filter to "Current view" as a default. This wouldn't change anything to the behavior of the first screen load, since at zoom level 0 "Current view" and "Global" result in the same thing.

[ENT8R]

I agree that clicking on refresh and seeing no results is quite counterintuitive, but there should be a small hint at the bottom of the screen which (when clicked) zooms the map to contain all results:

I would not really like to change the default search area behavior since the search within a specific area or bounding box is a little bit more expensive in terms of computation and searching in the current view by default for all users might lead to longer waiting times and an increased strain on the backend.

Maybe it would be already helpful to increase the size of the button or move it from the bottom of the screen to somewhere else, possibly in the vicinity of the other buttons at the top of the screen?

[opk12]

I would assume that most (if not all) users have a country / area of interest. What about

• auto-showing the filter dialog at launch,
• moving the area selection buttons to the top, to make it quick to reach and prominent,
• not having a default for the area?

Maybe it would be already helpful to increase the size of the button or move it from the bottom of the screen to somewhere else, possibly in the vicinity of the other buttons at the top of the screen?

For me, the implication that Center to the map results means "you are not centered" therefore "the search is not restricted to this view" is too much thinking as an occasional user. Also the white background color does not stand out with respect to the land color.

[CaqKa]

Hi! I came across this project in a discussion where it was suggested as a potentially useful tool for OpenStreetMap editors. I wanted to share some feedback based on my first impressions and experience using the interface.

1. Initial User Experience

When I first opened the page, I expected to see more notes. My immediate reaction was: “There must be more notes than this.” I then zoomed into my local region—but saw nothing displayed. This was confusing and discouraging. As someone with some background in UX, I believe this is a key moment where users might abandon the tool.

2. Filtering UI and Usability Issues

The filtering interface at the top was difficult to understand:

The first input field asks for a “query”. For a casual or even moderately experienced user, it's unclear what is expected here. Is it a keyword? A tag? A full-text search?

The second field asks for “author”, which is not immediately relevant for users who are simply looking for unresolved notes in their area.

From a UX perspective, the most relevant filtering options should focus on location and status (open vs. closed notes). These are intuitive and actionable for the majority of users.

3. Map Behavior and Defaults

The “current view” vs. “global view” setting is located at the bottom of the filter. I’d suggest moving it to the top—this is a key option that significantly affects results.

The default behavior should be:

Current view selected by default

Automatic refresh of the note list as the map is moved or zoomed

Show a loading indicator while data is being fetched (to avoid confusion about whether results are loading or simply absent)

To draw a comparison: imagine a map showing houses but not displaying house numbers, POIs, or terrain height unless the user clicks “refresh.” That kind of interaction would feel broken or outdated. The same applies here.

4. Performance and Energy Considerations

I understand the concern about server load and energy consumption. But this is the trade-off of creating useful tools: we expect computing resources to be used to make user experiences better.

Even this GitHub page consumes resources, but in doing so it enables collaboration and progress. A system that avoids consuming energy to the point that it fails to deliver meaningful utility is not fulfilling its purpose. Let the server use its RAM and CPU—it’s doing meaningful work to improve open mapping.