镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

🎨 Initiative: Switch to outlined icons #53701

Closed
16 of 16 issues completed
Closed

Description

@kra-mo

Summary

Outlined icons generally look more modern and are more versatile. With an outlined style, one can indicate selection using a filled variant.

With this change, it would also be ideal to start a switch from the now retired Material Icons to the visually similar, but newer Material Symbols.

All of our primary competitors use both outline-by-default and filled icons to indicate selection.

A move to Material Symbols is secondary, indication of selection is tertiary. Moving to a more modern, outlined style should be the primary goal.

Selection

When a navigation item is selected, its icon should change to a filled variant. This should ideally be done automatically in some way. We should ensure that this is consistent across all of our navigation components.

Material Symbols

Symbols are variable weight, so we should use one that matches Icons, at least for the time being, to aid the transition and so that the two styles can coexist until we've finished porting them. The default style is the most fitting: https://fonts.google.com/icons

Material Icons also provide outlined variants if a switch is deemed too difficult for the time being, but as Google has moved forward with Symbols, we will need to find a replacement to Icons eventually.

Exceptions

There are exceptions to this. One is app icons, the other is media types. This is out of recognizability and convention.

Additionally, don’t outline any icons that are already not filled like e.g. the "+" icon or checkmark. In doubt, check how the Material Symbol version looks: https://fonts.google.com/icons

Activity

  1. moved this to 📐 At design in 🖍 Design teamon Jun 26, 2025
  2. moved this from 📐 At design to 👓 Design review in 🖍 Design teamon Jun 26, 2025
  3. ChristophWurst commented on Jun 26, 2025

    @ChristophWurst
    Member

    There are exceptions to this. One is app icons, the other is media types. This is out of recognizability and convention.

    Image

    another exception to consider: the + for new items

  4. kra-mo commented on Jun 26, 2025

    @kra-mo
    MemberAuthor

    There are exceptions to this. One is app icons, the other is media types. This is out of recognizability and convention.

    Image

    another exception to consider: the + for new items

    Ouch haha. I updated the issue description :)

  5. moved this from To triage to Confirmed in 🧑‍🤝‍🧑 Community triageon Jun 27, 2025
  6. 41 remaining items

  7. ChristophWurst commented on Aug 11, 2025

    @ChristophWurst
    Member

    Sounds good

  8. susnux commented on Aug 11, 2025

    @susnux
    Contributor

    Should be easily doable by adding active as slot attribute.
    Then all what is needed is:

    <NcNavigationItem>
        <template #icon="{ active }">
            <NcIconSvgWrapper :path="active ? mdiFolder : mdiFolderOutlined" />
        </template>
    </NcNavigationItem>

    This is backwards compatible from the component and probably ~5 lines of code.


    Yes, I know that for files this will need a change of the View API but for other apps this is really easy to change.
    For files we maybe should make the iconSvg property a callback which gets the active state passed and thus can return an SVG based on that. This would be backwards compatible with existing views.

  9. skjnldsv commented on Aug 11, 2025

    @skjnldsv
    Member

    Yes, I know that for files this will need a change of the View API but for other apps this is really easy to change.

    There's other places where it is complicated other than Files :)
    Anything that is backed by an API basically (settings, apps...)

  10. susnux commented on Aug 11, 2025

    @susnux
    Contributor

    Anything that is backed by an API basically (settings, apps...)

    Apps are fine, this is fully done on front end. But yes for API based icons this does not work that easy and needs some translation (settings and activity).

    Meaning we can provide this from the components, but apps need some more time than the time left until next week (feature freeze) to adjust.

  11. changed the issue type fromtoon Aug 11, 2025
  12. added and removed
    1. to developAccepted and waiting to be taken care of
    on Aug 18, 2025
  13. jancborchardt commented on Sep 1, 2025

    @jancborchardt
    Member

    Another possible exception seems to be the expand arrow in Collectives. Either it should stay filled, or change to a chevron (2 lines only). @kra-mo @marcoambrosini ?

    Image
  14. marcoambrosini commented on Sep 1, 2025

    @marcoambrosini
    Member

    I think that the chevron would look best, it's also consistent with what we do elsewhere

  15. jancborchardt commented on Sep 2, 2025

    @jancborchardt
    Member

    In the sharing sidebar the arrows are also inconsistent (2 different styles for 3 different places: dropdowns, action menus, expandable list entries):

    Image
  16. jancborchardt commented on Sep 10, 2025

    @jancborchardt
    Member

    We can consider this done now – any place where an icon is still filled can be considered a bug and filed separately.
    Great work everyone and really nice suggestion @kra-mo! ✨

  17. moved this from 👓 Design review to 🎉 Done in 🖍 Design teamon Sep 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions