You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The feature type should always be visible in the inspector, even when scrolled down to all tags or relations.
Just making the feature type non-scollable would waste too much valuable inspector space.
We can move the feature type into the header instead. There is currently the "Edit feature" label, which can be omited. That the feature is editable there is intuitive, even without the label. In addition users are teached to edit there in the intro.
Here is a mock-up:
The dropdown triangle behind the feature type would make clear that the feature type can be changed. Therefore, the current function of the leftwards arrow isn't required anymore.
I have left the leftwards arrow in the mock-up because it can be reused to open the second sidebar in view of #3836.
Maybe we can omit the misleading "X"/checkmark button in the header (discussion in #3843).
The feature "select feature type" should keep there current header in general, but in case of changing an already set feature type the header containing the current feature type should be shown. This would make more clear which feature is changed (#3693), for example that a lake is converted into a highway area.
The text was updated successfully, but these errors were encountered:
We can move the feature type into the header instead. There is currently the "Edit feature" label, which can be omited. That the feature is editable there is intuitive, even without the label. In addition users are teached to edit there in the intro.
I disagree that the heading can be omitted. This part of the sidebar always has some text in it to give the user context about what the sidebar is currently doing ("Search Features" "Edit Feature" "Select Feature Type" "Upload to OpenStreetMap").
Good design is not about filling the screen with as much information as possible.
Sure we can't omit the heading in general. The headers "Search Features" "Select Feature Type" "Upload to OpenStreetMap" are important.
to give the user context about what the sidebar is currently doing
The modified heading which I have proposed above has just this intent, but is more specific.
When you edit Memberships you should know wheather you are editing a highway or the coincident tramway etc.
A compromise solution would be to only change the header text "Edit feature" to "Edit Secondary Road" etc. dependent on feature type. Maybe even dynamically when the feature type has been scrolled out of view.
But I'm quite sure we can omit the word "Edit" without confusing users, because all the edit boxes shown in the sidebar make it intuively clear.
The feature type should always be visible in the inspector, even when scrolled down to all tags or relations.
Just making the feature type non-scollable would waste too much valuable inspector space.
We can move the feature type into the header instead. There is currently the "Edit feature" label, which can be omited. That the feature is editable there is intuitive, even without the label. In addition users are teached to edit there in the intro.
Here is a mock-up:
The dropdown triangle behind the feature type would make clear that the feature type can be changed. Therefore, the current function of the leftwards arrow isn't required anymore.
I have left the leftwards arrow in the mock-up because it can be reused to open the second sidebar in view of #3836.
Maybe we can omit the misleading "X"/checkmark button in the header (discussion in #3843).
The feature "select feature type" should keep there current header in general, but in case of changing an already set feature type the header containing the current feature type should be shown. This would make more clear which feature is changed (#3693), for example that a lake is converted into a highway area.
The text was updated successfully, but these errors were encountered: