Many (most?) web sites use some sort of icon library such as Font Awesome to create icons of various types. This is a big improvement over the early days when every icon was a separate <img> file. I recommend picking a library of icons as part of MVP. We can then assign certain specifics (perhaps for Search, Users, Menu, etc.) as part of the CSS design specifications/Co-design but in general it will provide a consistent and easy way to add icons in a consistent manner, which is important for a quality user interface.
There are a bunch of different options. My recent experience is all with FontAwesome, so that is what I will suggest but others may have different ideas. Things to consider:
License:
FontAwesome has 2 flavors - Free & Pro. The Free version (which is I think the only one we should consider as Pro would be limiting for anyone else who makes their own Codidact instance) has the actual Icons under CC-BY-4.0 and the code is MIT.
Hosting:
This gets a bit confusing. The original typical FA setup (I think) allowed basically loading anything (within the Free icons) anywhere, anytime. They have changed things to try and monitor stuff (FontAwesome Kit - pageviews, etc.) My understanding is that you can still use it directly thanks the the CC-BY-4.0 license - i.e., if we include the icons & code as part of our package (subject to license compatibility, which is not my expertise) then there would be no monitoring and no issue. That would also be better from a “can anyone put Codidact anywhere” standpoint as well.
Quality:
FontAwesome is regularly updated and personally I think the quality is fantastic.
Anyone who has serious experience (my experience is relatively limited - primarily on some “internal” limited-use web sites), good or bad, with FontAwesome or alternatives, please comment.
@Contributor Can we discuss this a bit more and make a decision? There was another suggestion in Discord for icomoon I don’t care (much) if we use that or FontAwesome. Both have plenty of free icons. Both are scalable. etc. But we are (finally!) at the point where some front-end code is starting to be written, and these types of icons are an important part of the UI.
Other suggestions? Any major pros/cons for icomoon or FontAwesome?
So I’d like someone with a design background look over the icon list and make an educated guess if the free icons are sufficient. That’s only 1,500 of 7,500 icons.
They do offer to contact them for plans for open source projects though. In case we like this lib, one could get in contact with them. Maybe they have good plans for open source projects.
and it may be (in fact, quite likely) that we will only need a few (10? 20? 50?) icons. In fact, where we’d be most likely to need more icons is to support specific communities - i.e., the kind of thing where on SE they had their own designer come up with logos & backgrounds & buttons (the buttons being the only part we’re really talking about here) come in. If a particular community wants to add some icons that aren’t free, they can design some themselves or get a paid FontAwesome (or whatever) - it doesn’t actually affect the code (provided the identification of such icons is handled properly so that they don’t need to enter the codebase) and therefore licensing is a non-issue (i.e., would not affect AGPL or GPL or MIT or whatever the code is…)
What I am more concerned about is usability for our purposes. I have learned (repeatedly) that the stuff I often use in small projects won’t cut it here (“too big”, “not flexible enough”, whatever) - in fact about the only specific technology that I totally agree with (and that I have significant experience with) in Codidact so far is PostgreSQL. So I don’t care if the choice is not FontAwesome, but I’d like some of the people involved with the front-end design to say “FontAwesome” or “icomoon” or whatever, so that we can move forward and start incorporating professional quality icons into the UI.
The challenge with icon libraries is in essence, their size. They are expensive - the benefit if something like icomoon is that you can taylor-make your own set.
The other option is that we create our own which i’m partial to. We can use icons from open source libraries such as font awesome but make the size much smaller and also will give us flexibility to change as well
I am extremely interested in time-to-completion. If the concern is about size, my understanding (I could be wrong) is that with FontAwesome we could easily (just take the whole free batch) and legally (I just checked, CC BY SA 4) use it. Then at a later time we could rework to compress the library down to “only what we actually need/use”. But I don’t like creating our own “from scratch” - we have a ton of stuff to do. Let’s make use of what other people have already done, when quality is high and license is good.
But what I really don’t want to do is end up with junky looking pages because we end up with (for example) trying to mess around with a bunch of CSS to turn one character into an icon when we could take someone else’s that is already “done”. Which is why I think we need to pick something and let all the front-end people know what they can/should use.
I’ve used material icons in a few apps in the wild. It’s a bit sparse. There’s a lot of icons but I always feel like I’m trying to find other icons
Thank you. This is a minor piece in the grand scheme of things, but I know we’ve got some people ready to jump in on Front End Dev. and actually seeing some of that with a really polished look, even if it is not functional yet, will go a long way to assuring people that we’ve got a real project under way.
What’s wrong with using traditional image tags for icons? I’m sick of icons that only show up when JavaScript is enabled (and particularly, if what is shown instead is an invalid Unicode character that you cannot even guess what it means — while often the Unicode character set would contain a character that explicitly depicts what the icon depicts as well).
From looking at the linked github page, I think that would be exactly this type of icon (the link to the material.io server won’t show anything at all without JS, which I didn’t bother to enable).
The icomoon and FontAwesome pages linked earlier in the thread also don’t work without JS (well, at least the latter one at least cared to state that explicitly instead of just showing a broken page), so I fear for the worst.
The material.io icons I used are simply one SVG file each – couldn’t be simpler – and can be coded using <svg> in the HTML (and tweak their colors using CSS).
SVG might I don’t know be better for different screen resolutions, I like SVG too because you can change their color (e.g. by using a elements attribute like class plus CSS), for example if a icon is disabled or a notification is active oslt.
I guess the idea of packaging as a “font” is, if you have a ton of different icon types in the app, then you might like the browser to download them as (in) a single file.
So my impression from the GitHub page was wrong — good.
Needing support for SVG is fine (I think; is there any reasonably recent browser that doesn’t support it? The page you link do provides browser versions, but for most browsers I don’t know to which release date they correspond). Certainly it’s not something I’d see a reason to block.
I’ve little practical experience with fonts – except that my online resume uses icons from fontawsesome, and there’s no JS required/included to view those/that: it’s only a CSS.file.
In the quoted text, I referred to the web sites themselves. Since I didn’t bother to enable JS for the sites, I couldn’t evaluate whether the actual icons would need it as well (I wouldn’t have seen it right away anyway, it would have had to be documented on the site).
If you mouse-hover over the browser version it will popup the release date and % popularity – that popup requires JS though (I can’t imagine why you disable JS, I “can’t be bothered” to disable it).
IE6-IE8 are apparently down to “0.13% global usage”.
Disabling virtually all web-based attacks (no cross-site scripting, no covert bitcoin mining, …)
Disabling most tracking technologies (I don’t solely rely on JS blocking for that, but every bit helps).
As a free extra, it also blocks most ads.
It also generally reduces loading times and energy usage.
It prevents a web site from “hijacking” key combinations that I use for other purposes, be it browser built-ins or keys defined by browser extensions. As a simple example, I use Ctrl-L to get to the location bar (yes, I know that there is some Fx key that also does that, but Ctrl-L generally works and is easier to reach). But on Stack Exchange (one of the few sites where I decided that I lose more by not enabling JS than by enabling it), it gets me an “insert link” dialogue instead.
Also, with JS disabled, I know for sure that I can get to the browser’s right-click context menu by, well, right-clicking.
Also, back when I still used Google as my main search engine, I intentionally disabled JS to get rid of their “search while you type” feature. Despite that being annoying because I had to continuously switch between “allow Google” for maps and “disallow Google” for search (indeed, this tremendously helped me in my decision to switch away from Google as my default search engine). The insta-search annoyance was simply bigger than the switch-all-the-time annoyance.
For the browser year popup, I wonder whether the developers of that web site ever heard of the title attribute.
Personally, I am very much in favor of JS. It powers so many fantastic sites and many sites that work “OK” without JS work much better with it. But that is NOT really the discussion here. In fact, we have already decided elsewhere that the basics of the site should work without Javascript enabled for a bunch of reasons.
My concern with this specific Forum Post is: What do we do about icons?
Nobody has suggested “no icons, just plain text”. So the question is how do we do icons. I am saying “don’t reinvent the wheel by creating our own set of icons for save, upload image, upvote, downvote, new question, help, etc.” How we do that can include a bunch of different pieces:
Fonts
Images
Javascript
CSS
I am not expert enough in this specific field to tell you how FontAwesome vs. icomoon vs. Material do this. For my own projects I have (recently anyway) used FontAwesome, but those are limited scope projects - i.e., a captive user base that can be told “you must enable Javascript, you must allow images, etc.”
Based on the JS discussion, it seems this comes down to actually two separate questions:
Graphic Design:
Which libraries/systems/whatever have a wide enough assortment of free (appropriate license) icons of high enough quality to suit our near-future needs?
Technical Suitability:
Which libraries/systems/whatever will function reasonably well for both:
Typical user (Javascript enabled, modern browser) - should provide “optimum” viewing & functional experience
Plain vanilla user - this includes “deliberately Javascript disabled users” and also “search engines” - should provide a functional and readable experience - e.g., icons can’t all just show up as an “unknown character box”
Why some users with reasonably powerful computers and modern browsers choose to go to “plain vanilla” mode is irrelevant. The reality is that it is a market we need to include, even if it is a relatively small group.
OK i had a good review of our options. We will be going with fontawesome.
I used to not like them but they’ve seemed to have improved installation options now (no more nasty <i> elements if you don’ t want)
License is open source so we are good to go there. Doesnt require any special attribution. Icomoon is amazing as it allows you to self generate our own lib but it looks like we wont be going down that route.
If we don’t end up using a lot of icons, ill probably just get us to use inline SVGs instead of loading the whole library so there’s some flexibility there.
