Page MenuHomePhabricator

Rules for Wikimedia icon additions
Closed, ResolvedPublic

Description

Collecting/revisiting/defining rules for creation of new icons within our icon repository:
So far we have the following rules:

Format

  • All icons are vector-based, in SVG format

Design criteria

  • Neutral
  • Simple

Technical specifications

  • Monochromatic (Fill color –if defined– is #000, background color –if defined– is #fff, otherwise transparent)
  • Feature rounded corners on single path strokes (to be clarified – where and when needs to be sufficiently guided)
  • Filled areas (as opposed to outlines to define shapes; to be clarified – doesn't apply to “Alert”, “Help” or “Info” for example)
  • Cross-out lines are from top-left to bottom-right (\). See T133076

License for contributor additions

  • Must be free licensed

Open questions:

  • Stroke width? Medium-thick strokes, but needs clearer guideline
  • Size of canvas? Currently 24px x 24px
  • Usage of canvas – full vs padded?
  • Are they added after SVG optimization, like with SVGOMG? Or are we (also) adding non-compressed source files into the repository?

Those rules were discussed here and made their way into style guide.

Finalized, agreed on rules:

  • Reduce to the essential form.
  • Universal rather than culturally-specific.
  • Avoid textual content within the icon.
  • Abstract forms or concrete objects depending on context.
  • Neutral point of view.

Visual principles:

  • Monochromatic. Solid color icons.
  • Geometric. Comprised of simple and ideally symmetrical geometric shapes. Symmetrical icons tend to be more universally applicable (an open book rather than a closed book with binding on left or right side).
  • Front-facing. Icons are flat and front facing, not multi-dimensional.
  • 20 x 20 dp default canvas. WikimediaUI icons are put on a 20 x 20 device-independent pixel (dp)[2] canvas per default.
  • Rounded corners. Corners are rounded to make shapes more friendly and welcoming. For the default canvas use 2 dp rounded corners. Note that rounded corners are applied only on the exterior of an icon shape, not interior corners.
  • Medium thick stroke. Lines and outline should be visible at smaller sizes without effort, for the default icon canvas use a 2 dp thick stroke as standard. Endpoints of lines are square in keeping with simple geometric shapes.
  • Diagonal cross-out lines. For icons that appear to be crossed-out, the cross-out line starts from the top-left of the icon and continues at a 45 degree angle to the bottom right (similar to a backslash “\”).

Event Timeline

Volker_E renamed this task from Rules for Wikimedia icon repository additions to Rules for Wikimedia icon additions .Jul 5 2016, 12:36 PM
Volker_E updated the task description. (Show Details)

My 5 (actually 3 ) cents:

  • Why we actually use #fff as background and not transparent, which would allow icons to be used on other backgrounds as well?
  • Definitely unpadded - padding can be achieved with CSS, but hardly or impossibly undone via CSS.
  • Definitely have source (unoptimized file) available, it allows better orientation in the icon construction.

@Danny_B Thanks for your inputs, fill color confusion were my fault, actually there is no fill color defined for the majority of current icons. Updated task description.

From the description

Are they added after SVG optimization, like with SVGOMG? Or are we (also) adding non-compressed source files into the repository?

Uncompressed SVGs don't have any information that is vital to the shapes or the editing abilities of the file. They are usually software specific comments, or cruft like unused layers.

This might not be as important for an image repo, but keeping these, makes the diffs harder to read too.

  • Definitely have source (unoptimized file) available, it allows better orientation in the icon construction.

In what way would this allow for better icon construction. AFAIK, information like rulers get lost as the file transitions from one vector software to another.

  • Definitely have source (unoptimized file) available, it allows better orientation in the icon construction.

In what way would this allow for better icon construction. AFAIK, information like rulers get lost as the file transitions from one vector software to another.

Optimizers typically "optimize" the way they convert everything to paths. So there is no longer stuff like "draw circle here, draw square here, draw arc here" etc... but one huge set of <path> points which is totally useless if you want to work with it further.

Optimizers typically "optimize" the way they convert everything to paths. So there is no longer stuff like "draw circle here, draw square here, draw arc here" etc... but one huge set of <path> points which is totally useless if you want to work with it further.

You're right. Some optimizer flags do that and we should avoid it.

The few icons that I have touched, the source files had a single path too and not circles, squares etc. Personally I often add and expand objects to get direct control over them. But I digress, that has little to do with the optimization discussion at hand.

We should optimize to remove only the things that aren't needed, like the cruft I mentioned in my previous comment.

I agree with both of your points, @Prtksxna and @Danny_B, on making the icons more accessible for editing.
It would be helpful IMO to have editable files that feature ruler guide lines and the original shapes, but we also need to make sure that we have a build step, that optimizes the hell out of the files (src vs dist directory), where users can just take the file and use as is in production.

As mentioned in T139347: What icon formats are we going to continuously support?, icons should be contained within a standard bound (or canvas) of say 24x24px or 48x48px.

This will help both enable better control of anti-aliasing of icons (allowing for better pixel-fitting);and for greater consistency in sizes of various icons.

On the second point of standardizing visual perception of circular icons vs square icons, I think we should provide some 'padding' area in icons. So for example, we may create a 20px diameter circle icon centered in a 24x24px canvas, leaving 2px padding all around. For a square icon to look visually similar sized to the circle, it would be a slightly smaller 18x18px size, leaving 3px padding all around.

@RHo Now I do understand the need and agree: Padding necessary!

@RHo Could you please elaborate more? I am confused about why circular icon should be bigger in its dimensions than square. Thank you.

Hi @Danny_B, if the square icon was the same width and height as the circular icon, the visual perception will be that the square icon is larger due to the greater surface area of the square.

Some further reference:

Thank you.

Can we instead set the canvas for the biggest dimension possible (i.e. here it would be the circle), iow no padding there, and other icons (square) would use the padding?

I would like to avoid padded canvas as much as possible due to reason stated above T139351#2429098.

@Danny_B Yes, from my perspective think that would work and helps to simplify the guidelines a bit too.

In conversation with @Jdlrobson, @bmansurov and @Nirzar we were referring to two useful rules:

  • 24x24 px canvas size, because it's already used in mw.ui and OOjs UI icons
  • 48x48 density-independent pixel click/touch area size carrying the icon as good-to-have guideline.

As pixels get fuzzy due to different target device pixel densities, following density-independent pixels (abbreviated as dp/dps) is the better approach. Material Design is using 48x48 dps as guideline to ensure a physical size of about 9mm. Explaining density-independent pixels:

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, the baseline density assumed by the platform (as described later in this document). At run time, the platform transparently handles any scaling of the dp units needed, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: pixels = dps * (density / 160). For example, on 240 dpi screen, 1 dp would equal 1.5 physical pixels. Using dp units to define your application’s UI is highly recommended, as a way of ensuring proper display of your UI on different screens.

A great resource and overview of different guidelines and studies of touch target sizes is this article by Luke Wroblowski from 2010(!).
Featured there are Windows Phone UI guidelines with an absolute minimum of 26px/7mm for touch targets. And as baseline through all different research of 9mm as recommended touch target size.

After applying a test of the proposed icon template (24x24px canvas, 0px margin for circular icons), I think we should reconsider the proposal.

Test here:

To summarize, the 24x24px canvas with 0px margin on circular icons when applied to existing UI, means updating and enlarging almost all icons so that when applied at 1x size to this sample existing UI, look oversized.

Whilst we could resize all existing icons to be scaled smaller than 1x (24x24px), it is less than ideal to require scaling for majority of places.

Thus, I propose using the 3rd page of the test pdf, where a circular icon is 20x20px, which has the added benefit in keeping to the same circular icon size as Material icons, so we could benefit from re-using these to extend our icon set, and it is also more in line with our existing icon sizes (generally speaking).
IMHO, it would be useful to keep the 24x24px canvas size since 24/48 are standard icon sizes (again used by Material) which have higher factors for neater resizing, but this would mean inclusion of min. 2px margin of whitespace around icons.
Alternatively, we could have the same sizing of icons applied but use a smaller 20x20px canvas with 0px margins, but uncertain how this impacts existing UIs downstream using 24x24px - will all of these need to have padding applied?

Is it worthwhile proceeding using 20px20px canvas sized icons? It would actually be fairly easy to batch update all icons to add 2px margins if we see it breaking in loads of places...

I agree with the general approach Rita suggests. I don't have a strong opinion on whether to use a 20x20px canvas or a 24x24px one.
Anyone finding issues with either approach, feel free to contribute examples to illustrate them.

For me the key part is about the rules for adjusting the margins according to the shapes. In the current proposal, a square shape has 1px additional margin around compared to a circle shape, while in material design the difference is 2px. I just wanted to note the difference since it also affects the overall size of the icons (making square shapes in material design to be 16x16px instead of the 18x18px square shapes in our case ) and the possibilities of reuse.

hi @Pginer-WMF – actually the square shapes in Material icons do use a 18x18px square and 20x20px circle. Attached some examples from their set:

- https://material.io/icons/#ic_check_circle
- https://material.io/icons/#ic_image
- https://material.io/icons/#ic_account_circle
- https://material.io/icons/#ic_account_box

hi @Pginer-WMF – actually the square shapes in Material icons do use a 18x18px square and 20x20px circle. Attached some examples from their set:

You are right. It seems I misinterpreted an examples of the material design guidelines.

Another aspect to consider is how we expect to apply icons to UI elements such as buttons and how that affects their size. I created some examples with buttons that use 8px and 16px for padding and 16px for font-size size for the cases of 24x24px canvas, 20x20px canvas, and just text.

Another aspect to consider is how we expect to apply icons to UI elements such as buttons and how that affects their size. I created some examples with buttons that use 8px and 16px for padding and 16px for font-size size for the cases of 24x24px canvas, 20x20px canvas, and just text.

@Volker_E, correct me if I am wrong: It should be possible, by way of using margins on elements (text and icon) rather than padding on the entire button to achieve the third outcome (not saying that it is desired, just saying that its possible) while still using a 24px canvas (which makes us more inter-operable with Material, right @RHo?).

@Prtksxna Yes, you're right from my understanding. We still want to achieve the best possible outcome which means our default SVG canvas should be optimized for the biggest use case. That's why we've come up with 20 x 20 px canvas.

Volker_E triaged this task as Medium priority.Jul 19 2017, 6:38 PM
Volker_E moved this task from Backlog to Done on the Wikimedia Design Style Guide board.
Volker_E removed a project: Proposal.