[HN Gopher] Icons - Google Fonts
___________________________________________________________________
Icons - Google Fonts
Author : zuhayeer
Score : 291 points
Date : 2021-03-03 10:10 UTC (12 hours ago)
(HTM) web link (fonts.google.com)
(TXT) w3m dump (fonts.google.com)
| avipars wrote:
| i use font awesome and material design icons daily!
| reaperducer wrote:
| I like that the SVGs are available under the Apache license.
| Because of that, I may actually get some use out of these.
|
| Does anyone know if Apple's SF Symbols are available under a
| similar license? I looked at Apple's web site, and it only
| mentions not using them in trademarks.
| hundchenkatze wrote:
| I don't think you're allowed to redistribute them. Apple
| considers them system-provided assets, so you can only use them
| on systems that provide them.
|
| > Availability of individual symbols and features varies based
| on the version of the system you're targeting. When you export
| a symbol introduced in SF Symbols 2 as an SVG template and
| bundle it with your app, you can use it in apps that target iOS
| 13, Mac Catalyst 13, tvOS 13, or watchOS 6
|
| > All SF Symbols shall be considered to be system-provided
| images as defined in the Xcode and Apple SDKs license
| agreements and are subject to the terms and conditions set
| forth therein.
|
| https://developer.apple.com/design/human-interface-guideline...
|
| Link to the sdk terms:
|
| https://developer.apple.com/terms/
| momothereal wrote:
| Not a fan of how the entire page is squished when clicking on an
| icon. All the icons get displaced and it's a pain to find where
| you were in the list...
| 1f60c wrote:
| And a slick new design!
| wgx wrote:
| I have Google Fonts blocked in uBlock Origin now, and it's really
| helped pages load quicker and feel more snappy.
|
| I added these lines to uBlock: fonts.gstatic.com
| fonts.googleapis.com
|
| Occasionally some icons break on a few sites, but mostly it's
| plain sailing.
| mnadkvlb wrote:
| would something like that also work on a pihole ? that would be
| perfect for the other devices too that dont have possibility to
| use ublock
|
| thanks
| wgx wrote:
| Yes - you can block domains at the network-level with a
| pihole.
| Jach wrote:
| Something I still find hilarious is that after a product I
| worked on started to enforce a content security policy, the #1
| blocked source was always for google font resources. Of course
| users could whitelist the domains, but many didn't and anyway
| their sites looked fine.
| matkoniecz wrote:
| Is it supposed to be added to "My filters" tab in settings?
| wgx wrote:
| Yep, just add those lines in there and save.
| mortenjorck wrote:
| This will probably end up left unfinished like Google Fonts'
| variable font support.
|
| I don't understand how they commission high-quality fonts from
| professional foundries, then turn around and neuter them in the
| Google Fonts UI - take a look at the family called Commissioner:
| https://fonts.google.com/specimen/Commissioner
|
| Can you tell from this page that the font contains italics? Or
| that it has a semi-serif flared-terminal variant? These are
| additional axes that simply aren't supported, so there's no way
| to know they exist unless you visit the foundry's GitHub page.
| rememberlenny wrote:
| They are actively working on this.
|
| I worked on Google Fonts, and you'd be incredibly surprised how
| few people run the entire service. If I recall correctly, ether
| ratio is something like one Google Fonts team member is
| responsible for the equivalent opt hundreds of millions of
| requests a day.
|
| The main focus they had in the variable fonts roll out was
| making the internet faster. The process of choosing when to/not
| serve variable fonts behind the scenes was oriented around the
| font-weight axis, so they could reduce the number of requests,
| and hence speed up everything from Google searches to YouTube
| and every other website using Google Fonts.
|
| Sadly the UX around displaying axes isn't straight forward.
| Since the Google Fonts wants to setup a conservative interface,
| that doesn't result in users requesting an entire variable axes
| with every request, especially when it's not being used - there
| needed to be more work than just showing the font's design
| space on a specimen page.
|
| There is an incredible amount of behind the scenes effort from
| an incredibly talented team.
|
| Huge props to each of them.
| artur_makly wrote:
| Seems like someone should launch an open-source pro-WCAG icon set
| ;-)
| SquareWheel wrote:
| The real benefit here is that you can export these as SVG. Please
| do this instead. Icon fonts are convenient, but they're really
| bad for web performance. It needs to download the entire font
| even if there's only a handful of icons on a page.
|
| SVGs have excellent browser support, and decent CMS support. You
| can enable them in Wordpress for example with a little tinkering.
| If you want to make your site faster (and I hope you do), then
| definitely consider SVGs.
| EveYoung wrote:
| Or get the SVGs from Github directly:
| https://github.com/google/material-design-icons
| jokoon wrote:
| How do I download the png?
|
| The PNG are all in several subfolders...
| [deleted]
| jfk13 wrote:
| I see they promote the ligature approach: <span
| class="material-icons">face</span>
|
| where the font is expected to ligate the characters 'f', 'a',
| 'c', 'e' into a single <face> glyph.
|
| This can be problematic on the web, as it means that if a user
| _doesn 't_ get your webfont for any reason (download failed,
| browser settings that disable webfonts, accessibility options
| that override fonts for clarity, etc) the entire word will appear
| in a fallback font, often totally disrupting the layout. (Can
| _your_ site adapt nicely to a word, or even an entire phrase --
| e.g. "format list bulleted" -- appearing in the toolbar where
| you expected a single icon?)
| chrismorgan wrote:
| Also, most of the time icons should instead fall back to
| _nothing_ (and should be hidden from screen readers). The main
| exception that one will observe in reality is a toolbar of
| icons only with no labels; it's well understood in usability
| circles that that's a dangerous pattern at best--text labels
| and icon-and-text labels both almost always simply work better.
|
| I deem the ligature approach bad because it encourages leaving
| something in the document and accessibility tree that shouldn't
| be there, and most commonly in a non-semantic way (e.g. a send
| button might end up showing something like "paper airplane",
| which is terrible, or with this specific font, "Learn more -"
| might become "Learn more arrow_right_alt"), or with semantics
| that you'll definitely break at some point (e.g. report_problem
| is , but if you use that for an alert icon it'll mislead anyone
| that ends up reading report_problem; in short, any new
| semantics you desire for an icon, you _need_ to create a new
| ligature for it if the user can possibly ever be exposed to
| it).
| tobyhinloopen wrote:
| I just set overflow: hidden and a width of 1em (so it's a
| square)
| jfk13 wrote:
| In which case the layout may survive, but I expect the
| "labels" that appear when the icon font fails will be cropped
| to their first couple of letters or so: not a great fallback
| in terms of helping the user understand what they're meant to
| be.
| dragonwriter wrote:
| If they don't load the icons (whether they are image icons or
| font icons or svg icons), the presentation is badly busted in
| any case.
| echelon wrote:
| Neat.
|
| I've got a wild idea.
|
| What if instead of trying to destroy the web [1], Google tried to
| become the very best company for web developers? You know, take a
| play from Microsoft's "Developers Developers Developers" playbook
| after it was handed off to Nadella. The hip Microsoft that built
| VSCode, bought Github, and has the #2 cloud.
|
| Maybe a first class web has "native apps" that work on desktop
| and Android and don't require an App Store. That might handicap
| their rival Apple, because writing for web once targets two of
| the biggest three platforms.
|
| Get "distribution/promotion" through Search. Their ecosystem
| works, ties together, and makes sense.
|
| If Web wins and Google is #1 at it, then nearly all of their foes
| lose power. They can sell tools, build a flywheel, moat, all in
| one. And they wouldn't even have to be assholes anymore. All the
| cool kids stop hating.
|
| I don't expect their leadership to come up with this grand idea,
| however. We're just going to get more of the same. More wood
| behind all the arrows, none of which hit the target and all of
| which get cancelled in two to five years.
|
| [1] (Chrome, AMP, killing adblock, knee-capping HTML5, ruining
| semantic standards, making search a hard problem)
| v7p1Qbt1im wrote:
| They do push for that though. Via PWA/WebAssembly.
| Phillips126 wrote:
| For ReactJS developers, this is always my go-to: https://react-
| icons.github.io/react-icons
|
| Tons of SVG icons from popular packs and using ES6 imports, you
| only bundle the icons you use.
| emarthinsen wrote:
| Interesting that they have icons for "nordic walking" and
| "electric rickshaw", but nothing for twitter or a tweet.
| Macha wrote:
| Seems pretty clear they're avoiding icons that specifically
| reference 3rd party brands.
|
| What would a generic icon for a tweet be that differs from a
| "message" icon?
| vagab0nd wrote:
| Google Fonts used to have this great feature where I can select a
| number of fonts and view them all on a single page. It was super
| useful because I can type in any text and preview the text in
| these selected fonts.
|
| However, I can't seem to find this feature any more. Right now if
| I select fonts, they just show up in the sidebar. But I can
| preview them in any way.
|
| There's gotta be something that I missed?
| crazygringo wrote:
| It still totally works that way on Google Fonts homepage,
| nothing has changed.
|
| The icons page is just a separate page that works differently
| from the rest of the fonts.
| tomasroggero wrote:
| After you selected a few, you can review your selection in the
| Share page.
|
| For example,
| https://fonts.google.com/share?selection.family=Akaya%20Teli...
| visarga wrote:
| A foundational effort, this will help many.
| stevewillows wrote:
| I really wish they'd bring these in for Google Sheets, too. There
| are times where I want to sex up a sheet but don't want to bring
| in external images.
| eurasiantiger wrote:
| The provided usage example is bad for accessibility: the name of
| the icon, e.g. "check_circle", will be announced by screen
| readers. If there is other contextual information that explains
| the icon, the icon can be hidden from screen readers using aria-
| hidden="true". However, in cases where the icon appears stand-
| alone, it needs to contain a human-understandable text that
| explains its meaning.
|
| Also, never use Google's CDN for loading fonts or icons -- always
| self-host them. The CDNs are used to track your users.
| laurent92 wrote:
| "Check-circle" is exactly the amount of information that the
| able reader has. Sight-deficient users are as much used to
| those weird words as able users are used to unintelligible
| icons.
| eurasiantiger wrote:
| No. A sighted user can perceive the placement of the icon
| within its context, e.g. a checked circle within a row in a
| table, and deduce that it represents confirmation of whatever
| information the column of the table represents in the context
| of the row. This information is not available to a screen
| reader user unless the visually hidden text makes it
| explicitly available to them.
|
| By the way, your comment shows an ableist bias: an analogous
| assumption would be that a person who cannot walk is content
| because they are used to a wheelchair.
| hunter2_ wrote:
| If the image stands alone such that sighted users must parse
| it, then your logic is correct. But if the image is merely
| decorative due to adjacent text such that sighted users gloss
| over the image, aria-hidden affords users of screen readers
| that exact same efficiency instead of wasting their time.
|
| In other words, eyes can skip over decorations without the
| developer needing to flag them as such, but audio can't auto-
| skip.
| antpls wrote:
| Wouldn't it make more sense to have everything "hidden" by
| default and have an explicit "aria-include" ?
| greggturkington wrote:
| No the reader has "account_balance_wallet" (no dashes). It
| will read as "account_balance_wallet account balance wallet."
|
| It would be trivially easy to use ARIA attributes to indicate
| which span is the icon's label. Not something most people
| consider, but this is _Google_. At least they have an
| accessibility _icon_?
| eek04_ wrote:
| > Also, never use Google's CDN for loading fonts or icons --
| always self-host them. The CDNs are used to track your users.
|
| Any evidence of this claim? Also, given that the Google CDNs
| allow caching for 24h, it seems extremely ineffective even if
| it was done.
| legitster wrote:
| Yeah, seconding this. The main benefit of using a Google CDN
| is that there is a huge chance it's already cached on the
| client device. Which would mean that there is less useful
| tracking information.
| charcircuit wrote:
| >However, in cases where the icon appears stand-alone, it needs
| to contain a human-understandable text that explains its
| meaning.
|
| Why? It's the screen reader's job to inform users of what's on
| their screens. It's not my job to give descriptions to things.
|
| >The CDNs are used to track your users.
|
| Do you have any evidence to support this claim?
| madeofpalk wrote:
| As a web developer, it literally is your only job to make a
| website that is usable by people.
| adflux wrote:
| By which people? I think thats up to the developer to
| decide.
| Gene_Parmesan wrote:
| If you are making web sites for public use, the law
| disagrees with you.
| monsieurbanana wrote:
| 1. Not always
|
| 2. Obviously mostly yes, but in hn people just assume
| that you're a somewhat good person who wouldn't knowingly
| restraint internet access to people with disabilities
| bigfudge wrote:
| No - in most western countries it's decided in law that
| reasonable efforts should be made to support most people,
| those with disabilities like visual impairment included.
| thinkxl wrote:
| Of course that's up for the developer to decide. You
| can't force a developer to make a website accessible to
| all people regarding of their capabilities.
|
| But you have to remember the initial goal of why the
| Internet started as open and what was the initial goal,
| to make all information accessible to everyone, that's
| why accessibility standards were there since the
| beginning.
|
| That was the entire goal of the web, to be open and
| accessible to EVERYONE.
|
| But if you want to go full head on capitalism and argue
| it doesn't matter for business, accessibility is
| literally search engine optimization, which is great for
| business. Googlebot is blind and doesn't use a mouse to
| surf the web.
|
| From any perspective Accessibility is a requirements for
| any website or web application. Of course, nobody can
| force developers to make websites accessible.
|
| Wait, yeah they can:
|
| * https://www.reuters.com/article/us-usa-court-dominos-
| pizza/u...
| charcircuit wrote:
| I design websites that are to be used with primarily
| desktop screens. If you want to use an unsupported
| configuration such as a tiny screen or with no screen then
| it is not my fault if it does not work well.
|
| Similarly, if I make a VR game I am not going to design it
| in a way that makes creating a pancake version of the game
| easier to use. If someone does create a pancake mod for the
| game, they should not complain about how weird the controls
| are or how they can only use one hand. They should take
| those issues up with the pancake mom developer and not with
| me. If people find it hard to use my website through a
| screen reader then they should complain to the screen
| reader developer to improve it. It's not my fault if there
| software sucks at what it is trying to do.
| Kaze404 wrote:
| Ticket: "Your website isn't very accessible to people
| using screen readers. Could you improve it with aria tags
| please?"
|
| Response: "It's not my fault you're blind. Ticket
| closed."
| charcircuit wrote:
| No, I am saying that your screen reader sucks. For
| example a bad screen reader might require that an image
| of an apple has to be labelled apple for it to work, but
| a good one could just see that image and recognize that
| it is a picture of an apple.
| matsemann wrote:
| > _I design websites that are to be used with primarily
| desktop screens. If you want to use an unsupported
| configuration such as a tiny screen or with no screen
| then it is not my fault if it does not work well._
|
| In lots of countries you are obliged to make the site
| accessible for what you call "unsupported
| configurations". E.g screen readers, heavily zoomed sites
| etc. So yes, it will be your fault, and you are liable
| for what you deliver. If you're a professional web
| developer, this should be known.
| charcircuit wrote:
| Sure, throw me in jail for not wanting to waste my time
| developing stuff I have no use for in websites that are
| freely accessible. If countries want me to develop and
| support stuff that I don't want to they should pay me for
| it.
| hunter2_ wrote:
| VR versus pancake typically has nothing to do with
| disabilities. Display versus screen reader does. It's
| fine to exclude people who can choose to be included, but
| it's good to avoid exclusion when choice is not part of
| the equation.
|
| If you're talking about building something that couldn't
| possibly be of any use to a blind person, that's one
| thing, but most websites do not fall into that category.
| reaperducer wrote:
| _I design websites that are to be used with primarily
| desktop screens. If you want to use an unsupported
| configuration such as a tiny screen or with no screen
| then it is not my fault if it does not work well._
|
| It's good that you're this steadfast in your
| righteousness. That way you know why so many businesses
| don't consider hiring you.
| SquareWheel wrote:
| > Do you have any evidence to support this claim?
|
| Seems they have request logs and publish the aggregate
| statistics. There's no indication of tracking otherwise.
|
| > Google Fonts logs records of the CSS and the font file
| requests, and access to this data is kept secure. Aggregate
| usage numbers track how popular font families are, and are
| published on our analytics page. We use data from Google's
| web crawler to detect which websites use Google fonts. This
| data is published and accessible in the Google Fonts BigQuery
| database.
|
| https://developers.google.com/fonts/faq#what_does_using_the_.
| ..
| corty wrote:
| And special-purpose-font/script CDNs don't improve load times
| any more because browser caches are partitioned by domain
| nowadays. So using a CDN for fonts or scripts just increases
| your downtime probability and your GDPR headaches.
| EveYoung wrote:
| I guess it depends on where you're currently hosting your
| site and if you're using a CDN already. For smaller/private
| projects, a potential downtime of Google's CDN and GDPR are
| probably not too much of a concern.
| wodenokoto wrote:
| So now users need to download several megabytes of font to
| display check marks and search icons or is there something I'm
| misunderstanding?
| paul_f wrote:
| It is a 42KB file for 600 icons.
| michelb wrote:
| I would have expected it to work like the fonts, where you
| only query the things you need, and not everything. For
| performance reasons I assume people would still make a custom
| font/SVG set with only the icons they need.
| jug wrote:
| And which would additionally, I assume, replace the use of
| bitmaps.
|
| I'm surprised this question was even raised because vector
| graphics is the most size efficient way to do simple graphics
| on the web.
| Hasnep wrote:
| From the developer guide:
|
| > The icon font weighs in at only 42KB in its smallest woff2
| format and 56KB in standard woff format. By comparison, the SVG
| files compressed with gzip will generally be around 62KB in
| size, but this can be reduced considerably by compiling only
| the icons you need into a single SVG file with symbol sprites.
|
| So not that large, but I still prefer SVG icons.
| happymellon wrote:
| It's nice that they provide a git repo for this font with all
| the icons in SVG format
| sandreas wrote:
| Sounds a bit like MAUI* for dotnet... I'm very skeptical about
| one framework / project to solve UI problems on all common
| platforms but it is nice to see, that there is effort to improve
| the developer experience in more than one language.
|
| * https://github.com/dotnet/maui
| systemvoltage wrote:
| I am sorry but I am going to be _that_ guy. Iconography has
| regressed so much, it 's all the same optically to me. Designers
| keep pushing minimalism and line-graphics to "reduce crud" like
| its some sort of a religion. We can't distinguish icons well.
| There is no effort put into making them more unique and
| recognizable. What a horrible cult.
|
| Check out these glorious past remnants that we've forgotten
| about, they were so uhhh _iconic_ :
| http://www.famfamfam.com/lab/icons/
|
| We love to see someone take Fam Fam Fam icons and create SVG
| versions of them. Iconography takes time and effort and enormous
| amount of patience, skill. You can't do this in a week in
| illustrator which is how it seems most icons are designed today.
| We've become lazy, want free stuff and no one is incentivized to
| spend 2 years creating amazing icons. The market for paid icons
| doesn't exist and we've done this to ourselves because we're
| addicted to free stuff.
|
| Google services icons? All impossible to tell apart now. Apple
| macOS dock? They use to be different shapes and sizes, now they
| are all chicklet squares in macOS Big Sur. Apple fired the guy
| (Forstall) that was the brilliant mind behind Apple's approach to
| UI way back in 2013. Since then, Apple UI design sucks.
|
| It is all getting worse, day by day, icon by icon. Iconography
| was a discipline people took seriously before 2010's. Windows 95,
| 98, XP icons were so amazing. They thought deeply about it. No
| one gives a shit anymore.
| marcosdumay wrote:
| Ok, your comment made me open the site instead of just taking a
| glance at the comments and moving on.
|
| When I got there, the icons were... actually not that bad. They
| have very diverse outlines (even more than your example), large
| features (again, more than your examples), and very precise
| meanings. Why do you say they are hard to tell apart?
|
| The only thing missing is color and gradients, but that is for
| good reason, as hard-coded colors do interfere with usability
| and accessibility, and currently we have no way to encode color
| independent gradients (that's a huge oversight, by the way).
| jwr wrote:
| I think most UI and industrial design has regressed a lot in
| recent years. Two big issues are:
|
| 1. Obsession with "minimalism" and "clean design". Taken to the
| extreme by Jony Ive, where we started fearing what else Apple
| would take away in new revisions of their hardware and
| software. Scrollbars disappeared, buttons started blending into
| the background or becoming invisible, everything was "clean",
| utterly undiscoverable, and annoying to use. It only looked
| good in the keynote demo.
|
| 2. Fashion. Designers love following other designers and
| fashion trends run rampant. That's why on our phones we are
| beginning to get a bunch of icons that all look the same, every
| one is an abstract geometric pattern using at least 4 saturated
| colors. And we can't tell them from one another.
|
| I am so hoping for a reversion of both trends. You don't have
| to design like everybody else!
| dangwu wrote:
| You seem to be confusing these Google Font icons with app icons
| (Google services, macOS dock icons). The former are meant to be
| simple, resizeable, used by other apps, work in dark/light
| mode, and able to be part of any design language. Compare them
| with Apple's SF Symbols.
| systemvoltage wrote:
| Not an expert in this. In some fundamental way, icons have a
| specific function. To convey action, or status, etc in a
| small compact graphical form. Semiologically, photoshop tools
| palette icons and app icons are functionally the same. They
| are both used to perform an action whether that's to select a
| tool or launch an app.
|
| Edit: one key thing I forgot about iconography - familiarity.
| The floppy disk icon is ubiquitously understood for historic
| reasons.
| deckard1 wrote:
| > Google services icons? All impossible to tell apart now.
|
| Google went for maximum idiocy when they tried to use logos to
| serve two distinct roles: branding and utility. Which is why
| they look like complete unreadable ass.
|
| They forgot the simple fact that if you want branding, logos
| must look unique. And if you want utility, icons must be
| _representative_. It 's a classic case of wanting impossible
| design. I suspect there were no actual designers involved in
| the top-level direction at all. I've certainly done worse
| things for a paycheck.
| ridaj wrote:
| Seems like they went with branding at the expense of utility.
| Not sure they were trying to do both.
| core-questions wrote:
| > when they tried to use logos to serve two distinct roles:
| branding and utility.
|
| But you can do this. MS Office has done so one way or another
| for decades - the icons in the product family have similar,
| distinctive design language, but each also clearly conveys
| which product it is with shape, colour, and a clear letter
| logo.
| crazygringo wrote:
| On the one hand, I absolutely agree with you. I tremendously
| lament the fact that outline, color, and shading have been
| thrown out so now we're trying to decipher little rounded-box
| hieroglyphics based on lines being subtly different.
|
| But on the other hand, the problem is that icons took _so much
| work_ to create before, and also because they had such a
| recognizable identity /brand they weren't easy to reuse. Now
| the icons are so generic that they might as well be letters of
| the alphabet. They kinda are. A right-arrow is just a right-
| arrow -- it's not a Microsoft Office style right-arrow, or
| Windows 95 style right-arrow, or Mac Aqua style right-arrow,
| etc.
|
| These icon fonts make sense for when the icon is meant to be
| essentially decorative typography -- e.g. a share icon next to
| the word "share" or an "opens in new tab" link arrow. They work
| very well for websites.
|
| However, I _hate_ these icon fonts when they 're used _without_
| a text label besides them -- specifically in toolbars. That 's
| where I wish desperately we could go back to colorful textured
| icons that were easy to tell apart. Even after years, I _still_
| find Gmail 's toolbar of monochrome blob icons to be entirely
| unusable for this reason.
| systemvoltage wrote:
| Yes, it attaches a particular theme/brand/aesthetic to
| iconography. I think we should push designers to do the due
| diligence and not just get something from material.io and
| dump it in the app. It won't happen because $$$, ship ship
| ship and MVP culture, agile, etc.
|
| Careful, meticulous, rigorous, disciplined, thoughtful work
| is old fashioned.
|
| We produce broken, shitty apps because early feedback
| culture, not finishing things, market validation, the entire
| startup culture, etc. I see benefits in this but also
| negatives. Remember when SEGA games were shipped 100%
| complete and almost bug free? That's unheard of these days.
| They had no way to know if the game is going to be
| successful. No early access. They took _risks_.
| brudgers wrote:
| Most designers can create a good icon. Or two. But a
| cohesive set of one fifty is going to have a few that are
| not so good. And some that are outright crap.
|
| If a designer is designing icons, the designer is probably
| solving the wrong problem. Either because the "client"
| doesn't know what the right problem is. Or because
| designing icons is more for the designer than solving the
| right problem.
|
| Icons are hard because...well, all the reasons a floppy
| disk is the standard save icon. What I mean is that
| designers will default to their own experience and a floppy
| disk was it when the first sticky save icon was designed.
|
| Now it means save. A designer who wants to change the
| floppy disk is solving the wrong problem.
| systemvoltage wrote:
| I discussed this here:
| https://news.ycombinator.com/item?id=26332553
|
| I agree with you. We should take advantage of existing
| historical context such as the floppy save icon. This is
| what the Fam Fam Fam icon set does. The main issue is not
| to redesign them, but to design them in such a way that
| it is recognizeable. You can design floppy disk in many
| ways to fit your design aesthetic. Just that it should
| not be confused with 10 other icons. If you use
| monochrome line graphics, its hard to tell instantly.
| bckygldstn wrote:
| FYI there is a setting in gmail that turns the mystery icons
| into text labels:
| https://support.google.com/mail/answer/2473038?hl=en-GB
| crazygringo wrote:
| Wow it never even occurred to me there would be a setting
| for that.
|
| Thanks!!
| micdr0p wrote:
| Thank you for this!
| legitster wrote:
| I'm going to disagree.
|
| I deal with a lot of legacy interfaces with brightly colored
| icons and they can be just as confusing if not more confusing
| than minimalist icons. But I think people have a survivorship
| bias (we remember the good examples over the bad ones), as well
| as a familiarity bias (I like the things I grew up using!).
|
| I think the benefit of flat, monochrome designs is that they
| force you to offload meaning into the layout and flow of the
| application. You actually have to pick out a nice, meaningful
| spot to put the button, and make sure it makes sense in the
| context, and make sure users can discover it easily. Compare
| that to an open source application that just throws a bright
| green plus sign at the end of a row of icons and expects you to
| know what it does.
| tablespoon wrote:
| > I deal with a lot of legacy interfaces with brightly
| colored icons and they can be just as confusing if not more
| confusing than minimalist icons. But I think people have a
| survivorship bias (we remember the good examples over the bad
| ones),...
|
| I don't think anyone's disputing that you can do colorful
| icons poorly, but that's not an argument against them as a
| concept.
|
| > ...as well as a familiarity bias (I like the things I grew
| up using!).
|
| One of the cardinal sins of modern UX is fixing things that
| aren't broken, often just as you were getting used to the
| last "fix."
|
| > I think the benefit of flat, monochrome designs is that
| they force you to offload meaning into the layout and flow of
| the application. You actually have to pick out a nice,
| meaningful spot to put the button, and make sure it makes
| sense in the context, and make sure users can discover it
| easily.
|
| Nothing's stopping a designer from doing that with colorful
| icons.
|
| I think the real reason for flat, monochrome icons is
| designers prioritizing the _overall_ visual look /style of an
| application over its usability. It's almost like a less
| extreme version of designing a "computer interface" for a
| movie.
| legitster wrote:
| I would argue that we are not "fixing things that aren't
| broken". Technology is being adopted by more and more
| people. It should make sense that we find ways to make
| improvements to reach more and more users. I think software
| people run the real risk of designing interfaces only they
| like.
|
| I'm currently dealing with software that uses old style
| icons and menus and users just thoroughly do not understand
| the interfaces. The problem is that when every icon is
| brightly colored and bold, none of them are meaningful to
| the user. They all look equally important even when not.
|
| We're finding with flat, simpler icons we have a lot more
| control about making certain icons more important than
| others. We can still give them color! And it will be more
| meaningful! We can make them pop out when we need to!
| tablespoon wrote:
| > I would argue that we are not "fixing things that
| aren't broken". Technology is being adopted by more and
| more people. It should make sense that we find ways to
| make improvements to reach more and more users. I think
| software people run the real risk of designing interfaces
| only they like.
|
| What I meant by that comment is redesigning interfaces
| for aesthetics reasons: skeuomorphism is out, now
| skeuomorphism is in, now it's out again. Whitespace is
| out, whitespace is in. Google has a new icon set out so
| now our icons are "out of date," etc.
|
| Furthermore, there are real costs to obsoleting users'
| expertise with an existing interface, and those costs may
| not be outweighed by marginal improvements in a new
| design. Also expert users and beginning/casual users have
| very different needs, and I think there's often too much
| focus on beginners.
|
| > We're finding with flat, simpler icons we have a lot
| more control about making certain icons more important
| than others. We can still give them color! And it will be
| more meaningful! We can make them pop out when we need
| to!
|
| And that totally makes sense and I agree with it. What I
| disagree is rejecting color and depth in an interface for
| reasons of aesthetics, ideology, or fashion.
| systemvoltage wrote:
| It is interesting. I will need to check sources (Samir Zeki's
| vision book is amazing), but color detection happens way
| sooner in the v2/v3 region than symbol interpretation which
| is a higher level function. This is why stop signs are red,
| traffic lights are not icons (even if distance wasn't a
| concern, icon based traffic lights would take too long for
| human vision system to process). Evolutionarily, certain
| colors such as red indicate threat, injury, decay or food
| (blood) and we're hardwired to detect it effortlessly and
| within 100 ms or so. Before the interpretation (v4/v5/limbic
| system) happens. Baring color blindness concerns, monochrome
| iconography is objectively worse in every way except for the
| reasons I'll discuss below.
|
| If you study mission critical systems, even a fork lift,
| colors are everywhere. EMO button is red. CNC control panels
| have lots of colors.
|
| The reason why we use flat symbols (recylcing symbol on a
| milk jug, hazard labels on chemicals, bathroom symbols and
| airport signs, and road signs) is a practical consideration
| about printability and ease of application (single printing
| ink, stencils ), color fastness in the sun, etc. It's not for
| the reasons you're alluding to, although some of those
| concerns are orthogonally valid - layout should be logical
| and flow should be intuitive. Color icons are far superior,
| if someone can publish a scientific study, I would bet on it
| with real money. They might be ugly, not against
| brand/identity/etc. but I am strictly speaking of their
| utility.
| ncallaway wrote:
| I guess I don't understand this critique because with a
| monochrome iconset, I can style them to have the semantic
| color that's relevant at the time.
|
| A dangerous or destructive operation can be made to be red,
| to indicate the danger of the action.
|
| A primary action that I expect the user to do can be made a
| primary action color.
|
| If the icons are _built_ with color, then I can't change
| the color based on the semantics of how the icon is used.
| If you give me a monochrome icon that I can style, then I
| can match the color to the placement and functionality of
| the icon.
|
| So, yes, _in the application_ the icons shouldn't be
| monochrome. But in the _iconset_ I would generally prefer
| they be.
| legitster wrote:
| But you can do colors with icon fonts! In fact, one of
| their benefits is that you can do context specific colors.
| So only have things be red or green when it's most
| meaningful.
|
| I think the problem is in having all icons be bright and
| meaningful all the time - too much visual information can
| be worse than too little.
| SebastianKra wrote:
| What is it with HN being so hostile towards design?
|
| So many smart designers are carefully considering how to make
| genuinely ideal interfaces.
|
| But fuck them, they're just too lazy to put effort into complex
| interfaces, they're just following trends. They don't know what
| there doing. But Winamp-Themes where you can barely even see
| the buttons - yes, those are great.
|
| Sure, mistakes are made, and overcorrections happen. Everyone
| was tired of skeuomorphism a while ago (ironically, OP seems to
| have forgotten that). The response was a vast overcorrection
| and we're still recovering from that. But if you honestly think
| that we're off worse now, then I can only shake my head.
|
| (EDIT) But why is this hostility so prevalent in the developer
| demographic? Apparentlyy everyone else is okay. (unless you
| want to argue that there is some secret designer cult that
| imposes their will on everyone). Is it age? Are we just damaged
| from looking at a terminal too much?
| JKCalhoun wrote:
| Minimalism has a place -- esp. with reduced screen real-estate.
| An icon I would display in my tool bar or on a button is
| different than an icon I would display on the desktop.
|
| My beef with Google's icons is the seeming random decision to
| use rounded miters on some art, sharp miters on others. Very
| mish-mash.
| systemvoltage wrote:
| > reduced screen real-estate
|
| Don't get me started on how much space we waste on any UI
| these days. Apart from HN UI, pretty much every website and
| desktop app has wastage of space.
|
| I suspect, we stopped using borders - thanks to minimalism,
| that we need to use copious amounts of negative space to
| separate them. So, now paddings and margins are liberally
| applied everywhere.
| duckmysick wrote:
| > Apart from HN UI, pretty much every website and desktop
| app has wastage of space.
|
| By HN, do you mean Hacker News? Because it has whitespace
| on the sides (since the <table> element has width of 85%).
| It still looks fine if you change it to 90 or 95, so one
| could argue there's wasted space there too.
|
| But I'm not that one. I recognize empty space has its place
| in design. And it's not a fad either. Pick up a book - any
| book - and you will notice plenty of negative space there.
| Borders are used sparingly, if at all.
| systemvoltage wrote:
| Books have a purpose for negative space on either side of
| the text. It's to allow you to hold it without obscuring
| the text. It is also to allow spine to be tightly bound.
|
| For reference, here is a good book that goes in-depth of
| what and whys of book design, it is hard to find it
| though: https://www.amazon.com/Designing-Books-Practice-
| Jost-Hochuli...
|
| Most negative space on the websites is merely designers
| going "it looks clean".
| strokirk wrote:
| What's wrong with a design being clean? Normally that's
| high praise!
| Xevi wrote:
| Another reason is that we design websites for mobile users
| primarily, which requires more spacing due to touch input.
| And it's easy to just leave it in there for the desktop as
| well. It's also often more visually pleasing at first
| glance, even though it's less functional.
|
| I got to say that HN does not provide a nice mobile
| experience in my opinion. I've clicked the wrong link many
| times due to lack of white space. However I agree that a
| lot of sites add way too much spacing between everything.
| x3c wrote:
| Great to see Social distancing related icons in the list.
| jansan wrote:
| Or sad, depending on your point of view.
| crazygringo wrote:
| Wow. I wonder what this means for the future of Font Awesome.
|
| I know plenty of people are anti-Google, and also prefer SVG's
| over icon fonts for valid reasons (though you can download these
| as SVG's as well).
|
| But now that this is _easier_ to embed than Font Awesome, has
| basically the same number /range of icons as Font Awesome's free
| tier, doesn't come with the 10K pageviews/mo. restriction that
| Font Awesome's free tier comes with, and so many sites already
| use Google Fonts for their display and/or body text...
|
| ...I'd be very surprised if this doesn't quickly become the new
| de-facto standard icon font.
| bredren wrote:
| Font Awesome's product has long been destined for
| commoditization. Which is probably why they have diversified to
| offering custom icons and other differentiating behavior.
|
| I suspect google won't be the only one to offer icon sets like
| this, so in general I agree this will continue to erode FA's
| market share.
|
| Fwiw, It has felt like FA's most recent release fell far behind
| schedule.
| a1o wrote:
| Whenever Google makes something too easy to use for development I
| get a feeling they are moving on from it - in this case Material.
| _nalply wrote:
| Because it's not a distinguishing factor anymore, so let's give
| it to the masses.
| joshgoldman wrote:
| And moving towards what?
| ChrisArchitect wrote:
| Announcement blog post:
|
| https://material.io/blog/google-fonts-material-icons
| jfoster wrote:
| Are Google serious? Simultaneously pushing websites to be highly
| efficient (Core Web Vitals), at the same time as introducing the
| methods that can make them less efficient.
|
| Also, about these icons, they mention "please don't try to sell
| them", immediately followed by "Apache license 2.0". Well,
| Google, which is it? Do they actually mean to say "you have
| permission to sell them, but please don't?"
| joshgoldman wrote:
| I'll try selling them
| throwaway3699 wrote:
| You'd prefer Google throw them under a proprietary license
| instead of asking nicely?
| eurasiantiger wrote:
| I don't care since the icon font approach is technically
| inferior to SVG icons: it's monochrome only, whereas SVG
| supports colors and transparency.
|
| Icon fonts also suffer from a plethora of rendering issues
| across platforms because fonts are usually rendered with
| speedy display of long text in mind.
|
| It's strange Google would invest in a years-old kludge tech.
| jfoster wrote:
| Well, it's a good thing it's under Apache 2.0, then. Maybe
| someone will convert/trace them as SVGs and sublicense
| them...
| scoot wrote:
| They're available as SVGs. They link to the GitHub repo
| at the top of the page, and if you select any icon,
| there's a download SVG button.
| mappu wrote:
| Fonts can actually contain coloured glyphs now, originally
| for emoji. Although it does seem like a layering violation.
| ilogik wrote:
| y...yes? they should use an appropriate license
| dragonwriter wrote:
| Not every undesirable behavior can be blocked by firm rules
| without catching non-problematic behavior. Using a license
| which that errs on the side of being permissive rather than
| restrictive at the boundary and using social pressure to
| try to mitigate undesirable behavior in that boundary area
| seems a reasonable approach. (True for law, too, and lots
| of other domains.)
|
| There's some domains where you need to (given that perfect
| calibration is unattainable) err on the side of being
| restrictive, but that's definitely not always the right
| choice.
| jfoster wrote:
| It's incredible that one of the biggest companies in the
| world can't manage to appropriately license their stuff.
|
| Apache 2.0 is also a strange license for anything that's
| not code, too; it refers to "source" and "object" form
| throughout. I imagine they could've chosen it for license
| simplicity & compatibility reasons, but again, if they just
| wanted these to be used as widely as possible, they
| could've just gone CC0.
| dragonwriter wrote:
| > Apache 2.0 is also a strange license for anything
| that's not code, too; it refers to "source" and "object"
| form throughout.
|
| Fonts are code. And very often have a clear source vs.
| object form.
| throwaway3699 wrote:
| All Google is saying is don't scam others by reselling the
| same stuff that is freely available. Licensing it under
| something more restrictive (or custom) would make this a
| non-starter for other companies to reuse or remix.
| jfoster wrote:
| They can ask nicely, but I expect it will have very little
| bearing on how people use these. Determining how things get
| used is what licenses are for.
| amelius wrote:
| So WingDings but by Google. GoogDings?
|
| Did anyone convert them to SVG yet?
| momothereal wrote:
| When you click on an icon you can choose to download it as SVG
| or PNG.
| codepsycho wrote:
| AFAIK it hasn't "added support". We've used material icons for a
| year or two now from Google Fonts. Good to see this getting
| adoption but it's been available for some time
| tonoto wrote:
| All those icons and no icon for +1 ?
| rafaelturk wrote:
| Seriusly if you care just a little for your users Dont use this!
|
| Use SVGs.
| viktorcode wrote:
| This looks like it was created for Android app developers. Having
| a single set of most used icons across different apps improves
| consistency, which will be welcomed by the users.
| TonyTrapp wrote:
| Regular reminder that icon fonts are bad for accessibility and
| are technically troublesome also in other ways:
| https://github.blog/2016-02-22-delivering-octicons-with-svg/
| lpage wrote:
| The SVGs used to generate the icon fonts are Apache 2.0
| licensed: https://github.com/google/material-design-
| icons/tree/master/....
| ChrisArchitect wrote:
| (2016)? How about not using an ancient article to make a claim
| about a fast changing space like web dev?
| TonyTrapp wrote:
| Every single reasons for switching away from icon fonts
| mentioned in that article is still valid. Icon fonts were
| _already_ a bad idea in 2016, and they still are a bad idea
| in 2021.
| petters wrote:
| When developing, the fact that icon fonts follow the size and
| color of the surrounding text is nice, though. E.g. when
| tweaking the text color of a button.
|
| At least in my limited frontend experience.
| DangerousPie wrote:
| SVGs can do the same thing.
| tobyhinloopen wrote:
| That SVG does have to be inline though, which drastically
| increases your HTML page's size. You cannot style an SVG
| loaded in an IMG element.
|
| Imagine rendering 50 rows with each 6 icons, 1kb each.
| There are 6 unique icons, so it's only 6kb each loading
| them from the server, but inline you'll have 300kb of SVG
| icons
| duhi88 wrote:
| Most icons are generally tiny. Millage will vary, but
| they can speed up your site. Fewer requests for a
| slightly large page size.
| DangerousPie wrote:
| You can use an "SVG sprite" with <use>. No need to inline
| the SVG every time.
| tobyhinloopen wrote:
| Oh? I have to look that up
| leipert wrote:
| We are using this at GitLab: https://gitlab-
| org.gitlab.io/gitlab-svgs/, using svg-sprite to build the
| sprite file: https://www.npmjs.com/package/svg-sprite
| DangerousPie wrote:
| Took me a while to figure it all out, but it works
| surprisingly well. I have been using https://icomoon.io/
| to generate the sprites. They also provide a JS polyfill
| to support IE.
| jarek-foksa wrote:
| You can also use Boxy SVG to create and edit SVG sprites:
| https://boxy-svg.com/#tour-symbols
| reaperducer wrote:
| Boxy says "15 day free trial" but there's no information
| about how much it costs.
|
| Dora anyone know? I'm not going to sign up for something
| without knowing what I'm getting into.
| jarek-foksa wrote:
| Linux desktop app is free, macOS desktop app costs 9.99
| USD (one-time payment), web app costs 9.99 USD / year (no
| cloud services) or 9.99 USD / month (with cloud
| services). The complete pricing table is shown in the
| footer area of the home page when you open it with a
| Chromium-based browser.
| jefftk wrote:
| _> when you open it with a Chromium-based browser_
|
| Looks like they're using the experimental CSSStyleSheet()
| constructor [1] to display the pricing table. Ugh.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/CSSStyleShe...
| jessaustin wrote:
| _Some_ one has to push us to the future! Why wouldn't a
| business be happy to exclude 30% of browsers?
|
| https://www.npmjs.com/package/construct-style-sheets-
| polyfil...
| faeyanpiraat wrote:
| But how do you actually apply the styling? Just add a
| class to the <use> tag which contains "color:red;" ?
| 8lall0 wrote:
| You can export your SVGs with fill="currentColor" and
| your color attribute onto the SVG tag or its container
| would work.
|
| Since at $JOB i'm using SVG icons with more than one
| color, i use fill="var(--svg-color-base)" or
| fill="var(--svg-color-accent)" so i can precisely set
| which color i want, in a perfectly scope-able manner.
|
| The greatest advantage is that you can reference
| externally your svg with xlink.href on top of your
| website: you have to make one more request, but it's
| cacheable. Pick your tradeoff :)
| nikkwong wrote:
| You're saying you can embed all the SVGs onto one page,
| and then reference them on other pages/domains by using
| xlink.href? I haven't heard of this?
|
| So what you're describing is having site.com/page1 which
| has markup: <body> <svg id="icon-1"> ... </svg> </body>
|
| and then on site.com/page2 having
|
| <body> <svg> <use href="/page1#icon-1"> </svg> </body>
|
| Or something of this manner? Haven't encountered this,
| but sounds awesome; especially since you'd get the power
| of both inlining and caching the asset.
| f-word wrote:
| Either fill: currentColor or fill: var(--iconColor,
| currentColor) should do the trick. I prefer the 2nd one
| because it lets me change iconColor whenever I find it
| appropiate
| jarek-foksa wrote:
| This should work as long as the SVG shapes have the
| "fill" and/or "stroke" set to "currentColor".
| Mauricebranagh wrote:
| compared to the massive Js CSS and Images included on
| almost all 99.9% of pages a bit of SVG is trivial.
| d0gbread wrote:
| Everything's a bit in isolation, that's how they get ya.
| Easily to bulk up, hard to trim back down.
| Mauricebranagh wrote:
| _sigh_ tell me about it
| Aeolun wrote:
| 1kb is a lot for a simple svg icon.
|
| That said, if you have a single page app already, you can
| render as many icons as you want, since you'll only
| download them once anyway.
| tobyhinloopen wrote:
| I wonder how React copes with a whole bunch of inline
| SVGs. Seems expensive
| RobertKerans wrote:
| Copes totally fine and it's trivial to memoise them
| anyway.
| kps wrote:
| But if you want 5 icons, 5K of SVG beats 55K of WOFF.
| bagacrap wrote:
| I can't see how these would be bad for accessibility. The
| markup is a<span> with a human readable word like "home" in it.
| Kaze404 wrote:
| https://github.blog/2016-02-22-delivering-octicons-with-
| svg/...
| TonyTrapp wrote:
| Raw icon names (that you cannot influence) often don't make a
| good replacement for proper alt text. Quite often they should
| not be read out at all. Furthermore, people forcing websites
| to use a font like OpenDyslexic will see these non-
| descriptive icon names instead of the real icons.
| senux wrote:
| Just to complement other's responses, accessibility is a
| spectrum.
|
| We ought to believe someone chooses to use an icon for
| aesthetics AND usability reasons. If the icon can't be
| rendered at all, it defeats it's purpose despite it having a
| "description".
|
| Ultimately, if a well designed, user-friendly system doesn't
| work the way it's intended to, it is an accessibility issue
| of some degree. Albeit, some times more trivial than others.
| greggturkington wrote:
| The content "trending_up" is almost useless, a voiceover will
| not interpret the underscore as a space.
|
| There are no ARIA attributes that link any of the text to the
| buttons.
| [deleted]
| benrbray wrote:
| It seems like the solution is to improve the accessibility
| tools. The information is all already there.
| greggturkington wrote:
| That's not the solution. The solution is adding the
| correct attributes to the markup. Attributes that are
| universally recognized and _already_ work with a11y
| tools.
|
| In this example we'd add an aria-labelledby to the button
| which references the span with the correct info.
| nagisa wrote:
| To illustrate an issue this article describes,
| https://i.imgur.com/TzMXgUd.png is what the linked page looks
| like with a forced/limited font selection on Firefox.
| Tagbert wrote:
| If you block fonts, this is not a surprise.
|
| Using a fresh in stall of Firefox, the linked page displays
| the icons correctly.
| forgotmypw17 wrote:
| that,s the point. not everyone WANTS to load them or CAN
| load/see them.
| [deleted]
| Solvitieg wrote:
| So is Javascript but that hasn't stopped anybody
| forgotmypw17 wrote:
| not true. many design their sites THOUGHTFULLY and as a
| result they can be accessed without js. case in point: site
| i,m writing this comment on. counterpoint: almost anything on
| google.com domain these days.
___________________________________________________________________
(page generated 2021-03-03 23:01 UTC)