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.
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.
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.
“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.
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.
All text being skipped unless the author tags it for inclusion doesn't seem like a failsafe default, assuming that excessive information is generally preferred over insufficient information.
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?
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.
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.
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.
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
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.
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.
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.
> 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.
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.
Again, assuming you're a professional that's just part of the job. So you will get paid for it, just include it in the estimates/your quotes. It's not optional. And really, it's not that hard to do..
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.
>VR versus pancake typically has nothing to do with disabilities
Keyboard and mouse as inputs leave you essentially physically disabled. Not having a full range of motion is just an much of a disability as being blind.
No, my response is 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.
Ok, and what does that change? Are you gonna invent that software for those people? If it already exists, are you gonna give them a license? All because you didn't feel like spending half an hour thinking about accessibility.
It's not my job to work on your screen reader. Complaints about its effectiveness should go towards the developers of the screen reader software. If everyone's screen leader software sucks then there is likely a business opportunity for someone to make a better one. Also you are trivializing it by saying half an hour. Even if that was true it would be half an hour for every single website in existence. That doesn't scale. What scales is making a better screen reader.
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.
I make websites in my free time for fun. I don't find it fun spending time developing and testing for configurations that I won't personally use. I have better things to do in my life than fiddle with CSS.
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.
Good point about DOM size. I wonder if using external SVGs would have had the same effect? I don't know enough about browser rendering to know if that matters.
Semi related but there was a HN post a few weeks back about a tool that would scan your site and then modify the font file to only include the characters or icons you actually used. I still think SVGs are a better option.
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?)
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).
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.
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.
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.
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.
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.
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.
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.
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
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.
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 :)
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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!
> 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.
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.
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.
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.
> But I think people have a survivorship bias (we remember the good examples over the bad ones)
Exactly! Survivorship bias is great, we get to only pick the examples that we know were good enough to survive! Why on earth would we want to have a truly random sample that gave us a whole bunch of terrible icons we'll ditch within 3 years?
I also think that "instant universal recognizability" is only one potential reason to use icons, and a fairly limited one. It's also great to have fairly abstract icons in a particular application that are used consistently within that application, so that people can use them as a mnemonic.
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.
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.
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.
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.
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?
It's sort of the default state of assumption about the world in my opinion. "Everyone is an idiot except me" makes the world incredibly simple - frustrating, but simple. "Other people are incredibly bright and talented" is a scarier thought at a first look, plus it's vastly more complex because then the second question: "Why are there still problems in the world" arises instantly.
Personally I think it's wildly comforting and explanatory to assume other people (typically) know better than I do. Means I can focus on my little corner of the world and I don't need to tear it all down and rebuild it. Design, fashion, modern art; there are loads of domains engineers tend to assume are full of idiots - and yet we don't seem to dominate them like you'd assume we would if they were, indeed, full of idiots.
> 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.
> 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.
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!
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.
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.
> 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.
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.
It's not just for the practical purpose. Jan Tschichold writes: "Two constants reign over the proportions of a well made book: the hand and the eye." Indeed, large margins give a feeling of quality, luxury, and openness. Compare older books with spacious margins to tight ones in modern books so as much text can be crammed to save on printing.
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.
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).
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.
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.
I am going to heavily agree. The current set of useless garbage is not different from the next. And any and all creativeness is sirens in copying and being like apple and google.
The flat abstractions are garbage that only a selected few understand. Instead of being a language that is representative of something, literally the meaning of "icon", it is a flat 2d projections of a 3d shape in a 2 color scheme.
A floppy disk became the icon for saving because it represented "write to disk". Now, it would be a square in the name of flat ness and easy to read or some other optimization. This is not to be conflated with survivorship bias.
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...
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?"
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.
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.
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.
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.
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.
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.
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.
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.
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.
Maybe. They have a Facebook one and a few for some other social platforms. I'm not sure why there isn't one for Twitter and GitHub. I'm not saying there is any strategy going on, it's just interesting to see what is and isn't included in icon sets.
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
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.
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.
> 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.
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.
this looks like it's very early beta. lots of the outlined icon are filled, and lots of the icon change shape proportions dramatically between the different kind, say, filled and rounded, making it impossible to use the stiles together like you could with font awesome
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)
Also, never use Google’s CDN for loading fonts or icons — always self-host them. The CDNs are used to track your users.