-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Improve edit control icons to make them clearer and more intuitive #179 #179
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super excited to see this coming together!! Thanks @symbioquine and @gbathree for working on it!
Just a few questions/concerns... see my inline comments below...
For future reference my process for standardizing/minifying the svg icons @gbathree provided was as follows;
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great improvement! I think @mstenta caught more than I would have noticed 😁
Assuming the colors work when in farmOS/gin theme then I think this is good to go. Just make sure to change the Gin accent color and see that it updates the map. I think our green colors are similar so it might be hard to notice this otherwise.
Good point! Thanks! |
…rmOS#179 The button designs, while elegant, don't fit with users expectations. First, there's a sense that because the fields are perfectly square, that is a square line drawing tool. So there's hesitancy in using it, and rather people use the line tool instead. The problem is that the line tool does not create an area WKT object, and that produces non-obvious cascading user experience failures down the line (you save something that's should be an area as a line and in FarmOS it doesn't show the acreage... when you export to another service, it fails to render it as an area so the service doesn't work right, etc. etc.). I should also say this doesn't just happen sometimes... it happens a lot. So the design changes offer a few simple things to address these issues: - The main area icons (circle, poly) look filled, and poly icon is not square. All this helps inform the user that this is for creating general purpose areas, helping them not use inappropriate (ie line) solutions. - The 'modify' tool is just more obvious, showing a pointer dragging a corner. It's less elegant than the previous solution, but in our experience users need clarity over elegance in this situation. It's also very similar to the design of this type of function in other solutions, building on what users may have already seen. See previous/related issues; - farmOS#146 - farmOS#152
f63f071
to
d7b213c
Compare
The force-pushed changes do the following;
Current HEAD (without these changes): New Version: |
LGTM! Thanks @symbioquine!! |
The button designs, while elegant, don't fit with users expectations. First, there's a sense that because the fields are perfectly square, that is a square line drawing tool. So there's hesitancy in using it, and rather people use the line tool instead. The problem is that the line tool does not create an area WKT object, and that produces non-obvious cascading user experience failures down the line (you save something that's should be an area as a line and in FarmOS it doesn't show the acreage... when you export to another service, it fails to render it as an area so the service doesn't work right, etc. etc.). I should also say this doesn't just happen sometimes... it happens a lot. So the design changes offer a few simple things to address these issues: - The main area icons (circle, poly) look filled, and poly icon is not square. All this helps inform the user that this is for creating general purpose areas, helping them not use inappropriate (ie line) solutions. - The 'modify' tool is just more obvious, showing a pointer dragging a corner. It's less elegant than the previous solution, but in our experience users need clarity over elegance in this situation. It's also very similar to the design of this type of function in other solutions, building on what users may have already seen. See previous/related issues; - #146 - #152
Motivation
Ref: #152 (comment)
See previous/related issues;
Before:
After:
Build output before:
Build output after: