carbon
carbon copied to clipboard
carbon-design-system
Pictograms' stroke-width is too thin for non-retina displays
Detailed description
Pictograms look all nice and sharp on high-density screens like the Retina screens on Macs but get blurry and deformed on anything not as high-density. This highly affects the aesthetic and overall perceived "quality" of the UI components they're placed in.
A few examples (taken on a screen with 117ppi)
cc @laurenmrice do you know who would be good to direct this towards on brand?
Correct me if I'm wrong, @joshblack, but I think this issue will be corrected once we swap each asset out with the outlined versions of the svgs.
@janhassel I think in terms of stroke width this got adjusted by defaulting to larger sizes of pictograms.
Unfortunately, at smaller sizes, it seems like something that will not be addressed by pictograms or icons given how Plex itself suffers from a similar issue on letters like e, l, etc.
I think for some assets we could see if they are not landing on the pixel grid, but outside of that, it seems like there won't be a way to address this.
Curious what you think @janhassel
@joshblack I quickly tried out some pictograms with the new minimum size of pictograms (48px) and I'm wondering what the reason behind the fractional stroke widths is.
With a stroke width of 1.08px on a 48px pictogram, the line's width is almost indistinguishable compared to a stroke width of 1px, yet the fractions cause some half-pixel rendering. In this example, the top row of pictograms are 48px (=1.08px stroke width) where the bottom row is scaled to 44.44px (= roughly 1px stroke width).
As you can see, the "Duplicate file" pictogram appearance is greatly improved, the "Folder" pictogram actually is a bit more blurry (my first guess would be that due to the scaling, the horizontal lines are placed in between pixels). The screenshot is taken on a display with 109ppi.
Are there any downsides of designing pictograms on a 48x48 pixel grid with a 1px stroke width? It seems this could solve a lot rendering issues on non-retina screens.
@janhassel definitely a great point, I'll defer to @dudley-ibm who is authoring the pictograms to see what he thinks 👀
I think the current stroke guidance currently comes from the IDL which specifies the 0.72px stroke: https://www.ibm.com/design/language/iconography/pictograms/design#strokes
@janhassel the pictograms actually "used" to be 48px, but the recent breaking change is such that all pictograms are 32px now. What did you mean when you said you were trying them out "with the new minimum size of pictograms (48px)" in your above note? I would point this conversation to Mike Abbink, but I cannot seem to tag him here.
@dudley-ibm Sorry, I was referring to the usage guidelines and how they changed from stating 32px as the minimum size to 48px in July last year (https://github.com/carbon-design-system/carbon-website/pull/1438).
Gotcha. I suggest discussing this with Mike Abbink, but again I'm not able to tag him here.
@janhassel The pictograms are intended for larger usage. 48px is a minimum but we recommend 64px and the IBM dotcom team will be implementing that size in their patterns for example. Pictograms stroke weight was determined to work well across a wide range of uses spanning across digital and print (web, social, videos, animations, merchandise, environments, events and signage systems). The stroke weight spans tons of weights within digital media alone.
We increased a bit but 1px basically kills the entire concept along with the flexibility to communicate with the form. The UI icons are more for 48px and below and are much more suited for non-retina displays. Thinking in pixels was not intended for these not would I want it to be.
Concept for these ate to be light, delicate and robust to illustrate many varieties of concepts from simple to more complex. They are closer to functioning as illustrations more than they are icons. The .72pt to 1pt would cause many of pictograms to clunk up and challenge the integrity of the pictogram concept (like the city ones for example).
@mjabbink I wasn't suggesting to change the stroke-width from 0.72px to 1px, but referring to the calculated stroke-width of pictograms at a 48px size, which is currently 1.08px (0.72px at 32px * 1.5 = 1.08px at 48px).
If pictograms would be designed with a 1px stroke-width on a 48x48px grid, the rendering on non-high-pixel-density displays could be vastly improved. Here is an example of the duplicate file pictogram at 48px, rendered at 100% on a display with 109ppi:
(left: original (1.08px stroke-width), middle: 1px stroke-width, right: 1px stroke-width and aligned on pixel grid)
The middle example already looks a bit sharper than the original one due to the lack of bleeding into the next pixels. (top: original (1.08px), bottom: 1px)
The difference is in weight is quite marginal. (black is 1px stroke-width; blue is the currently additional 0.08px width)
Let me know what you think!
I see what you saying. I misunderstood. I think your suggestion is a good one. I wonder how it would effect the 64px size recommendation? It would also likely improve. Hmm. Now the question is how to achieve without @dudley-ibm exploding into thousands of pieces. We just updated all the pictograms to be a different stroke weight and output.
@janhassel so what we we need to change the 32px source too? From .72pt to .XXpt
@mjabbink Let me carefully ask the following while hoping to not making @dudley-ibm explore already. 😄
Is there are reason to design the pictograms on a 32x32px original size since the guidance changed and states 48px as the minimum size? 1px stroke width on 48px would result in a stroke width of ⅔px on 32px. Using a 48x48px grid to design the original assets would enable one to place all lines on the pixel grid and rendering the pictograms at full sharpness for that size. However, for any size that is not a whole number multiplication of 48px, pixels will not align on the grid.
Here is a comparison between the original pictogram (top) and the modified one with 1px stroke and aligned on grid (bottom) for the sizes: 48px, 64px, 80px, 96px, 112px, 128px
The modification seems to improve 48px, 80px, 96px and 128px, while 64px and 112px look better with the original asset imo. There will be no solution that renders all pictograms perfectly on all sizes other than manually designing each pictogram for each size (which is completely unfeasible) or limiting the recommended sizes a pictogram is displayed at (with 48px as a base this would be 48px, 96px, 144px, ...) which will probably make a lot of teams unhappy .
In the end it probably comes down to which sizes should be prioritized due to their usage in applications.
Don't worry, fellas. I won't explode.
@janhassel your example above uses a pictogram (Duplicate file) that reflects about 70% of current pictograms in the master (strokes only). Please excuse this if it's a silly question, but does any of this discussion affect the remaining percentage of pictograms in the master that are currently a combination of strokes and outlined shapes?
@dudley-ibm Yes it would. If we do what @janhassel is suggesting it would require all the outlined bit to be renown. The live stoke elements would be an easy change.
I’m not sure it makes a difference to change the original source file from 32x32 to 48x48 if we get eh stoke size right at 32x32 so if scaled or used at 48x48 the stroke would equal 1px. If we have to change the source artwork I think the project becomes out of scope.
@dudley-ibm The dots/circular outlines would not have to change though. Minor detail but would save a bunch of time. Only outlines based on stroke weight would have to be adjusted (mainly letters and some diagonal stroked lines we flattened the terminals on — e.g. bottom of the A)
@mjabbink @dudley-ibm I agree that the filled shapes like circles mostly likely don't need to change.
Regarding the original artwork size: To achieve the perfect sharpness on 48px, the pictograms would need to be designed on a 48x48 pixel grid and the lines would need to align to that grid. If an artwork is created on a 32x32 pixel grid, it will result in placing the lines in between pixels when rendered at 48px, making them render blurry.
Example: to achieve the pixel grid alignment on 48px (top), the lines would need to placed at very specific values in between pixels on the source 32px artwork (bottom).
There are two stages to an improvement in rendering though:
- Changing the stroke-width to be 1px at 48px (⅔px on 32px)
- Aligning the pictogram's lines and shapes on a 48x48 pixel grid
The first stage would get rid of the slight glow:
The second one would render the pictograms perfectly sharp at 48px.
Here is a scaled version of how each stage would render:
(left: current implementation, middle: stage 1, right: stage 2)
Thanks @janhassel This would require a complete redraw of over 1000 pictograms. I’m more in favor of adjusting the source stoke weight at 32 to achieve a better result at 48px
@mjabbink Sounds reasonable!
Maybe the redraw could also be a longer, staggered process. So updating some pictograms already to 48x48 for their source while others remain at 32x32 and pushing them over time.
Not sure if that could cause issues though for a) the designers working on differently sized source files b) the pictogram generator scripts (@joshblack you'd probably have a better understanding on that than me)
Some pictograms would also probably be more work to adjust for 48x48 source files than others. With the "Duplicate file" used in the examples above, the change was rather minor (narrowing the boxes by 0.5px). Though doing this for over 1000 assets is still a tremendous amount of work – hence the idea about staggering it.
(blue: original pictogram, dark overlay: updated pictogram)
It would also require us to change the guidance. Currently it’s not pixel based but rather vector stroke driven. The stroke line snaps to the grid line and sits directly on it where as the UI icons are pixels based thinking and one essentially fills the boxes/pixels with black. Two different logics. It”s also why we’re recommending designers to use them larger like 64px. If used small they become less distinguishable from UI icons and less effective. So pushing them to be used larger helps create the distinction between them. Most cases I see are pictograms being misused in product. Website a bit better but also many cases of too small. Me saying this makes me wonder if we should change the guidance to 64px minimum size.
Me saying this makes me wonder if we should change the guidance to 64px minimum size.
I think this would make a lot of sense actually and further differentiates the intended usage of icons vs. pictograms by skipping the 48px step altogether.
@mjabbink @joshblack What would be the next steps for this? Is it just updating the guidance on the website or are there any other actions needed?
@janhassel Based on this image above https://github.com/carbon-design-system/carbon/issues/6245#issuecomment-776741104 I would recommend we do one of two things. a) Nothing since at 48 the fuzziness is livable for many pictograms and use cases b) We adjust the source file stroke weight so that used at 48 it 1px to align better to pixels.
option b) will require @dudley-ibm to adjust the stroke weight over 1000 pictograms and manually adjust many expanded strokes that have had some adjustment. A lot of work and just after many weeks and hours of him recently changed the same elements to the current state. Basically duplicating the work effort immediately after completion of the same exact thing but different stroke weight spec.
Given other priorities and limited resources I cannot place this in any upcoming sprint so option b) will be placed in the back log.
In the meantime we can replace guidance to recommendation of 64px as minimum size. That will make some use cases we’ve seen break the rules and of course does not solve the fuzziness. I’m not sure that is the answer either. I’m leaning on living with fuzzy pictograms at 48px until we can execute option b).
@dudley-ibm Can you give me an estimate of your time to refactor all the pictograms with new stroke weight? I think the weight needs to still be specified at 32px so that at 48px it equals 1pt/1px. I guess make a pictogram 48px and 1pc stroke then reduce to 32x32 again and see what the pt size is. Once you know this scope we can plan accordingly.
Quick question for either @janhassel or @mjabbink: Based on the above comment, are we requiring that the strokes of all pictograms when enlarged to the 48px grid size should fall between the grid lines in addition to having a 1px stroke weight?
Oh, that is. good question. If just adjusting the stroke weight does not improve the issue then we will not make any adjustments. We cannot do any redrawing.