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

Make feature type more visible in the inspector #3848

Closed
slhh opened this issue Feb 18, 2017 · 2 comments
Closed

Make feature type more visible in the inspector #3848

slhh opened this issue Feb 18, 2017 · 2 comments

Comments

@slhh
Copy link
Contributor

slhh commented Feb 18, 2017

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:
edit feature headert

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.

@bhousel
Copy link
Member

bhousel commented Feb 20, 2017

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.

@bhousel bhousel closed this as completed Feb 20, 2017
@slhh
Copy link
Contributor Author

slhh commented Feb 20, 2017

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.

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

No branches or pull requests

2 participants