organicmaps/organicmaps-tmp

Archived

Fork 1

Global issues with icons and thoughts on improvement #4017

New issue

Open

opened 2022-12-03 21:48:08 +00:00 by euf · 1 comment

euf commented

2022-12-03 21:48:08 +00:00

(Migrated from github.com)

Intro

After tinkering with OM icons for some time, I noticed several problems. Since they seem to be interconnected, it seems logical to list them together rather than split into separate issues. Disclaimer: I am neither a professional designer nor a professional software developer, but I have a soft spot for great apps (such as OM) and great designs (which is the point of this discussion).

1. Styles naming and file structure (subjective)

organicmaps/organicmaps#7264

Using names clear/vehicle for main styling of the map and clear/night for color mode is confusing. It could be renamed to base/vehicle (with further addition of hiking, cycling, etc.) and day/night respectively. Overall file structure related to icons makes me search for stuff for too long: paths like data/styles/clear/style-night/symbols/ and data/styles/clear/style-clear/xhdpi/ are hard to memorize and navigate.

2. Workflow complexity (subjective)

As described in STYLES.md, adding icons requires running generate_symbols.sh, which calls custom skin_generator_tool. Since I am not a C++ developer, I failed to figure out the reason for having this custom tool, as well as the reason for joining all icons into a big symbols.png with symbols.sdf. It feels like this workflow could be simplified by doing a SVG→PNG conversion separately, e.g. using Inkscape CLI.

3. SVGs sizes are misleading for a designer

#7118

One of the hardest thing to figure out in the current SVG→PNG workflow is scaling of the icons. It turns out that SVG size in pixels is downscaled 0.75 to become mdpi (@1 on iOS), 0.75×1.5=1.125 to become hdpi, 0.75×2=1.5 to become xhdpi (@2 on iOS). For some icons dimensions, it goes like this:

sixe in px		1x	1.5x	2x	3x
	svg	mdpi	hdpi	xhdpi	xxhdpi
small (e.g. `airport-s`)	16	12	18	24	36
regular (e.g. `alcohol-m`)	24	18	27	36	54

This 0.75 downscaling leads to blurry designs. While editing SVGs, people tend to use pixel grid snapping, because it helps to achieve pixel-perfect design. Unfortunately in OM the SVGs pixel grid is misleading. To do real pixel-perfect icons, one should use 1pt=0.75px pixel grid in Inkscape, which is not intuitive at all. Here is my attempt at redrawing beer icon with the correct grid in mind:

The easy fix for this would be removing the 0.75 downscaling step from the code and resize the SVG files themselves. Unfortunately it will not fix pixel grid alignment for current icons, and the only benefit would be the simplification of the workflow for future icon designers.

4. Sizes of the icons are not consistent and their scaling is weird

organicmaps/organicmaps#9418

As far as I can tell, drape uses the following scaling:

MdpiScale = 1.0
HdpiScale = 1.5
XhdpiScale = 2.0
6plusScale = 2.4
XxhdpiScale = 3.0
XxxhdpiScale = 3.5

https://github.com/organicmaps/organicmaps/blob/master/drape_frontend/visual_params.cpp#L37

First of all, Xxxhdpi is commonly understood as 4.0 (not 3.5).

Secondly, skin generator tool uses different scaling:

  std::make_tuple("mdpi", 18, false),
  std::make_tuple("hdpi", 27, false),
  std::make_tuple("xhdpi", 36, false),
  std::make_tuple("xxhdpi", 54, false),
  std::make_tuple("6plus", 54, false),
  std::make_tuple("xxxhdpi", 64, false),

https://github.com/organicmaps/organicmaps/blob/master/qt/build_style/build_skins.cpp#L37

BuildSkin clear  clear mdpi    18 _clear symbols
BuildSkin clear  clear hdpi    27 _clear symbols
BuildSkin clear  clear xhdpi   36 _clear symbols
BuildSkin clear  clear xxhdpi  54 _clear symbols
BuildSkin clear  clear 6plus   54 _clear symbols
BuildSkin clear  clear xxxhdpi 64 _clear symbols

https://github.com/organicmaps/organicmaps/blob/master/tools/unix/generate_symbols.sh#L89

This leads to a strange inconsistency for xxhdpi, 6plus and xxxhdpi scales:

	visual_params.cpp	build_skins.cpp	build_skins.cpp / 18
mdpi	1,0	18	1,000
hdpi	1,5	27	1,500
xhdpi	2,0	36	2,000
xxhdpi	2,4	54	3,000
6plus	3,0	54	3,000
xxxhdpi	3,5	64	3,556

@biodranik gave an advice to search for rationale in old omim repo, but I couldn't find anything clear on this topic. It seems that these discrepancies are here due to different approaches in different commits by different people over time.

While fixing it looks easy (just unify everything to 1/1.5/2/2.4/3/4), it would require extensive testing on various devices.

5. Data redundancy and styling limitations

All night icons are just clear icons with the opacity set to 60%. organicmaps/organicmaps#4014
Colors for business, outdoors, etc. are not that consistent (see #3940).

I'm not sure, should it be fixed by separating icons from their backgrounds to merge them on the fly, or it would even increase workflow complexity. Anyway, when I tried greping hex codes from all non-subway SVGs to create a color palette for design guidelines, I found more colors used than it was expected, so further investigation and fixes are to be done.

6. Design language and pixel-perfect approach

At the moment STYLES.md suggests to

preferably look for icons in collections OM uses already

First of all, it leads to copying vector shapes without their alignment on the pixel grid, which makes icons blurry on smaller screen resolutions (for mdpi it's even hard to recognise shapes). Secondly, even if someone tries to draw a nice icon themselves, they are likely to fail in designing a sharp icon due to reasons decribed above (3. SVGs sizes are misleading for a designer). Finally, even with correct pixel grid, design will be not consistent:

some icons come from material sets, others do not;
some are just outlines instead of filled forms;
some use sharp angles, others use rounded corners;
stroke width varies significantly between similar forms…

All these discrepancies can be noticed on a great page https://github.com/organicmaps/organicmaps/wiki/Icons.

There are good examples of nice map themed icon sets, such as mapbox/maki. To look good together, they are based on design guidelines. I believe that creating a guideline document for OM icon design and gradually updating icons to be compliant with it would drastically improve legibility as well as the overall impression of the app.

Conclusion

Many of the issues above may be solved independently, at least to some point. At the same time, I heard that current SVG→PNG pipeline is already seen as suboptimal by the developers. I'm not sure whether there are specific plans to render SVGs natively by drape or we gonna live with PNGs for another couple of years. While I have no real experience in building vector icons management tools, it definitely feels like the current approach could be improved in many ways. That said, I hope to provoke further discussion by this meta-issue.

### Intro After tinkering with OM icons for some time, I noticed several problems. Since they seem to be interconnected, it seems logical to list them together rather than split into separate issues. Disclaimer: I am neither a professional designer nor a professional software developer, but I have a soft spot for great apps (such as OM) and great designs (which is the point of this discussion). ### 1. Styles naming and file structure (subjective) - [x] https://git.omaps.dev/organicmaps/organicmaps/pulls/7264 Using names `clear`/`vehicle` for main styling of the map and `clear`/`night` for color mode is confusing. It could be renamed to `base`/`vehicle` (with further addition of `hiking`, `cycling`, etc.) and `day`/`night` respectively. Overall file structure related to icons makes me search for stuff for too long: paths like `data/styles/clear/style-night/symbols/` and `data/styles/clear/style-clear/xhdpi/` are hard to memorize and navigate. ### 2. Workflow complexity (subjective) As described in [STYLES.md](https://github.com/organicmaps/organicmaps/blob/master/docs/STYLES.md), adding icons requires running `generate_symbols.sh`, which calls custom skin_generator_tool. Since I am not a C++ developer, I failed to figure out the reason for having this custom tool, as well as the reason for joining all icons into a big `symbols.png` with `symbols.sdf`. It feels like this workflow could be simplified by doing a SVG→PNG conversion separately, e.g. using Inkscape CLI. ### 3. SVGs sizes are misleading for a designer - [x] #7118 One of the hardest thing to figure out in the current SVG→PNG workflow is scaling of the icons. It turns out that SVG size in pixels is downscaled 0.75 to become mdpi (@1 on iOS), 0.75×1.5=1.125 to become hdpi, 0.75×2=1.5 to become xhdpi (@2 on iOS). For some icons dimensions, it goes like this: | sixe in px | | 1x | 1.5x | 2x | 3x | |---|---|---|---|---|---| | | svg | mdpi | hdpi | xhdpi | xxhdpi | | small (e.g. `airport-s`) | 16 | 12 | 18 | 24 | 36 | | regular (e.g. `alcohol-m`) | 24 | 18 | 27 | 36 | 54 | This 0.75 downscaling leads to blurry designs. While editing SVGs, people tend to use pixel grid snapping, because it helps to achieve pixel-perfect design. Unfortunately in OM the SVGs pixel grid is misleading. To do real pixel-perfect icons, one should use 1pt=0.75px pixel grid in Inkscape, which is not intuitive at all. Here is my attempt at redrawing beer icon with the correct grid in mind: ![image](https://user-images.githubusercontent.com/11754264/205439292-2b0c64be-7ce5-45e9-887c-b750b2c43f18.png) The easy fix for this would be removing the 0.75 downscaling step from the code and resize the SVG files themselves. Unfortunately it will not fix pixel grid alignment for current icons, and the only benefit would be the simplification of the workflow for future icon designers. ### 4. Sizes of the icons are not consistent and their scaling is weird - [x] https://git.omaps.dev/organicmaps/organicmaps/pulls/9418 As far as I can tell, `drape` uses the following scaling: ``` MdpiScale = 1.0 HdpiScale = 1.5 XhdpiScale = 2.0 6plusScale = 2.4 XxhdpiScale = 3.0 XxxhdpiScale = 3.5 ``` https://github.com/organicmaps/organicmaps/blob/master/drape_frontend/visual_params.cpp#L37 First of all, `Xxxhdpi` is commonly understood as 4.0 (not 3.5). Secondly, skin generator tool uses different scaling: ``` std::make_tuple("mdpi", 18, false), std::make_tuple("hdpi", 27, false), std::make_tuple("xhdpi", 36, false), std::make_tuple("xxhdpi", 54, false), std::make_tuple("6plus", 54, false), std::make_tuple("xxxhdpi", 64, false), ``` https://github.com/organicmaps/organicmaps/blob/master/qt/build_style/build_skins.cpp#L37 ``` BuildSkin clear clear mdpi 18 _clear symbols BuildSkin clear clear hdpi 27 _clear symbols BuildSkin clear clear xhdpi 36 _clear symbols BuildSkin clear clear xxhdpi 54 _clear symbols BuildSkin clear clear 6plus 54 _clear symbols BuildSkin clear clear xxxhdpi 64 _clear symbols ``` https://github.com/organicmaps/organicmaps/blob/master/tools/unix/generate_symbols.sh#L89 This leads to a strange inconsistency for `xxhdpi`, `6plus` and `xxxhdpi` scales: | visual_params.cpp | build_skins.cpp | build_skins.cpp / 18 -- | -- | -- | -- mdpi | 1,0 | 18 | 1,000 hdpi | 1,5 | 27 | 1,500 xhdpi | 2,0 | 36 | 2,000 xxhdpi | 2,4 | 54 | 3,000 6plus | 3,0 | 54 | 3,000 xxxhdpi | 3,5 | 64 | 3,556 @biodranik gave an advice to search for rationale in old omim repo, but I couldn't find anything clear on this topic. It seems that these discrepancies are here due to different approaches in different commits by different people over time. While fixing it looks easy (just unify everything to 1/1.5/2/2.4/3/4), it would require extensive testing on various devices. ### 5. Data redundancy and styling limitations - [x] All `night` icons are just `clear` icons with the opacity set to 60%. https://git.omaps.dev/organicmaps/organicmaps/issues/4014 - [ ] Colors for business, outdoors, etc. are not that consistent (see #3940). I'm not sure, should it be fixed by separating icons from their backgrounds to merge them on the fly, or it would even increase workflow complexity. Anyway, when I tried `grep`ing hex codes from all non-subway SVGs to create a color palette for design guidelines, I found more colors used than it was expected, so further investigation and fixes are to be done. ### 6. Design language and pixel-perfect approach At the moment [STYLES.md](https://github.com/organicmaps/organicmaps/blob/master/docs/STYLES.md) suggests to > preferably look for icons in [collections OM uses already](https://github.com/organicmaps/organicmaps/blob/master/data/copyright.html#icons) First of all, it leads to copying vector shapes without their alignment on the pixel grid, which makes icons blurry on smaller screen resolutions (for [mdpi](https://github.com/organicmaps/organicmaps/blob/master/data/resources-mdpi_clear/symbols.png) it's even hard to recognise shapes). Secondly, even if someone tries to draw a nice icon themselves, they are likely to fail in designing a sharp icon due to reasons decribed above (**3. SVGs sizes are misleading for a designer**). Finally, even with correct pixel grid, design will be not consistent: - some icons come from material sets, others do not; - some are just outlines instead of filled forms; - some use sharp angles, others use rounded corners; - stroke width varies significantly between similar forms… All these discrepancies can be noticed on a great page https://github.com/organicmaps/organicmaps/wiki/Icons. There are good examples of nice map themed icon sets, such as [mapbox/maki](https://github.com/mapbox/maki). To look good together, they are based on [design guidelines](https://labs.mapbox.com/maki-icons/guidelines/). I believe that creating a guideline document for OM icon design and gradually updating icons to be compliant with it would drastically improve legibility as well as the overall impression of the app. ### Conclusion Many of the issues above may be solved independently, at least to some point. At the same time, I heard that current SVG→PNG pipeline is already seen as suboptimal by the developers. I'm not sure whether there are specific plans to render SVGs natively by `drape` or we gonna live with PNGs for another couple of years. While I have no real experience in building vector icons management tools, it definitely feels like the current approach could be improved in many ways. That said, I hope to provoke further discussion by this meta-issue.

👍 6

dvdmrtnz commented

2022-12-05 17:39:07 +00:00

Contributor

All night icons are just clear icons with the opacity set to 60%.

I'm working on improving the dark mode style of icons in organicmaps/organicmaps#4014

> * All `night` icons are just `clear` icons with the opacity set to 60%. I'm working on improving the dark mode style of icons in https://git.omaps.dev/organicmaps/organicmaps/issues/4014

❤️ 1

This repo is archived. You cannot comment on issues.