Say you’re working on a website that uses an icon system. Lots of people who work on the site interact with the icon system. Designers create new icons, they tweak existing ones, they have ideas on what they want the icons to do. Developers building out the pages of the site use the system.
Say you’re the front-end developer. You’re implementing this system. You’re the middle man. You’re the creator and consumer of this system.
What do you ask of the designers?
Option 1) “Please do exactly these things.”
Something like:
Design your icons in all black on a 100×100 artboard in Illustrator. Save the file in this particular folder named “icon-NAME.svg” with this exact set of options. Make sure to optimize what you can in Illustrator first, like combining paths and reducing points. When a new one is ready, run `gulp svgstore` from the project root, that will ready the icon for production. Make commits to the project pertaining to new icons separate from blah blah etc you get the point.
Option 2) “Please follow these basics.”
Something like:
Icons on our site are single-color and square. We have a folder in Dropbox where we keep the originals. If you have a new one or changed old one, do it there and let me know.
Option 3) “Give me whatever, I’ll take care of it.”
Something like:
Work in vector if possible, but otherwise work however you best work and I’ll make it work for our system.
Have you been in a position like this? How are you orchestrating the team?
I’m the sole icon designer at my company. The leads typically ask for icons like your option #3, but when I deliver the icons it’s my fault that I didn’t read their mind and do XYZ. I was once berated because I didn’t know that an application couldn’t use ICOs and could only accept BMPs with a magenta background for transparency despite asking numerous times before hand. I think the cause of the problem is that I never get to talk to the actual developers implementing the ICOs.
For us, it’s a mix of option 1 and option 2, we have a set of rules for icons and exporting but we only require the designers to put them on a folder and let us know, all further optimization and pushing to production as well as versioning happen with the front-end guys.
We use gulp and an svg sprite for all of our icons, so it’s sort of a combination of the above
Whatever size and shape and colour you want/need
When you export them, follow some simple guidelines but make sure they are called “icons” (illustrator chucks whatever your artboard name is after the “file” name (e.g. icons_home.svg)
From there, as the FE Dev, I pick up those icons and chuck them in my sprite folder to use. If the icons change size, the CSS updates.
(For anyone insterested, we use gulp svg sprite for our SVG sprite compilation.)
I lean toward Option 3, because I feel like that’s the job. Let the designer work however they are most comfortable, in their world. I’ll do what I do, in my world.
Although there are plenty of things that could push a situation into #2 or #1 territory. Like the designer wants specific guidelines and workflow. Like the team is large enough that it needs guidelines so it doesn’t go off the rails. Like an incident comes up (as Jon described above) where misaligned expectations cause people problems.
The way I treat icons changes based on their purpose. I usually have what I would call a “utility” icon set: something like FontAwesome’s icons, used throughout the site for interaction icons (like a hamburger icon for the mobile nav) or for social icons.
For utility icons, I use IcoMoon to check the sizes and generate the sprite. (As a side note, I usually clear out excess horizontal space– otherwise, margin/padding usually gets thrown off when lining them up horizontally.) With IcoMoon, finding and adding a new icon is pretty simple.
I treat complex icons differently. These icons are used for display or descriptive purposes; places where a single-layer rocketship icon ain’t gonna cut it.
I’d keep those in a separate sprite from the utility sprite, I think, especially if complex hover/interaction effects are involved. It does require me to spend more time in Illustrator, yeah, but the complexity of the icons necessitates it.
Typically Option 3. However, if they aren’t working completely in vector, I try to remind them to work in a higher res format so they consider high dpi displays. Otherwise go nuts.
#3 is chaos, and frankly, garbage. I know that’s harsh, but the few times I’ve worked in that environment it became toxic fast. Anyone working on a team should have some guidelines for working on that team, however details or sparse they may be. It might work on a very small basis, but that’s more of a happy accident than it being a well-thought out system.
Imagine an engineer coming in and saying he wants to code in a different language and manage that code with a different version control system, because “that’s how he works best and is most comfortable”. No, that’s not an option. It’s the same reason teams implement linters: consistency is often more valuable that the gains of a single person employing different means.
#1 and #2 both are guidelines, they just vary in how strict they are. That strictness should be up to a given team to decide, but to not have guidelines as a team to work within? Anarchy.
My non-scientific, wholly anecdotal observation is that most of our clients at Cloud Four are in the options 1 or 2 camp. But I’d say we as an agency lean more toward options 2 or 3.
Ultimately, the only two things that matter are that the icon is well-designed (readable, scalable, harmonious) and that it’s implemented in a way that maximizes re-use and does not result in any unnecessary file size. As long as those two boxes are checked, it doesn’t really matter what apps, formats or process you used to get there.
We stick to #2. #3 is a mess, and #1 is a no-no for designers (not their job to run build tasks or commit to a VCS).
I sit somewhere in-between 1 and 2. Designers should be optimizing their assets (removing duplicate points, etc) since that’s a core part of their toolset. Otherwise, it’s often up to developers to interpret a designers intentions. My workday is more front-end development than it is visual design, but I can say with confidence that constraints placed on things like composition size and color aid in the creative process.
We followed option 1 at a bare minimal effort on the part of the designers – basically “export your SVG with these exact settings, this exact artboard size, and hand us the file”. I did tell the designers that if they combine paths, it makes things better in the long run, but didn’t require it from them. I also required that they use all one-color, but not specifically black. We kept the technical minutiae to a minimum.
From there, I would clean up the SVG code by hand – Adobe Illustrator likes to add a bunch of extra things. Made sure to strip out any colors. Made sure everything was in a square space. Made sure that the ID attribute on the SVG tag matched the file name. From time to time, I discovered things that were mis-aligned, so I talked with the designers and realigned them properly by hand. I am sure that a lot of the process could be automated, but I didn’t have the time to spend the effort on it (icons rarely changed, so it wasn’t such a frequent occurrence that automation would have saved much/any time). After that, it went into the code base which used grunt and the svgstore task.
In the instances that they needed an icon that had multiple colors, or if it was in a non-square shape; these we called “symbols” instead of icons, and they followed different rules. Icons could programmatically change their colors in an easy, standard way. Icons could display next to one another fairly easily, and scaling worked in a standard uniform way to support variously sized buttons. I didn’t do much pre-processing of the SVG file for a symbol, pretty much just threw an ID attribute on the SVG element. On the rare occasion that we needed a symbol inside a button, it was easy enough to treat it as a one-off while still reaping the benefits of standard icon implementation.
Designating types of SVG imagery as “icons” vs. “symbols” solved a lot of problems for us.
I think SVGOMG is what you need. Simplifies paths, removes unneccessary stuf. Last time I used it, it has removed 97% of an Illustrator SVG without any visual difference.
On the UI Team at WGU, we’re really striving for a fully-automated front-end framework that we can build into a living style guide, so we ask the designers for option 1 essentially. We have to run those icons through an automated Illustrator script that converts them to sprites, then through a Grunt process that generates the SASS and Base64 strings from those sprites.
The file name, the artboard, the structure of the SVG … it all needs to be right, and we’ve gone through significant rebranding to where we have dozens of icons and growing. The designers have to be on board.
Also, I’m crap at AI, so it’s faster for them to do it the templated way anyhow!
Here’s what we do:
Each icon is an artboard in a Sketch file names like myicon-24 (24 being the size).
That’s it, really.
A gulp task:
Exports all artboards as svg
Clean up using (svgo)
A symbol file is created with each icon prefixed with “-icon”
The resulting symbol svg file is named based on the file it is created
Both the file name and the file are pushed to git
Now,
The symbol file is either dumped in the html is the browser does not support using external symbols, or the symbols are referenced directly, e.g assets/icons-6373737.svg#icon-myicon-24
The developer does not or care what’s taking place really since an react component or an Icon php function take care of that.
This may look complex but is super simple and instantl really.
Since the screen designers and us frontend developers are two teams of the same department, we had a discussion on how the icon workflow should work, assessed the different ways to include icons in our pages in our company (inline svg for SPAs and background-image for normal pages) tried a few things, threw away some of them and united several approaches to something that works for us. Basically, #1, but it’s not us alone who requests certain formats. Automatical conversion is dangerous, because it can easily screw up the quality of sub-pixel rendering.
I work for a large financial institution. It’s much closer to #1 than #2 or #3. We have pretty strict guidelines and any new icons introduced would likely need a team approval.
I’d say in a perfect world, a designer knows exactly how to design icons for the web in a correct format, consistent, and optimized for performance and color requirements. The web is their medium too and there should not be a separate “world”. The days of creating statics in Photoshop and throwing it over the wall should be over.
Yet I know they are not, not everywhere. So in practice, I’d aim for option 1, be as specific as you can, upfront. What also may help is a public icon demo page where they are shown in a grid. If something is off, you should be able to see it quickly. One of the most prevailing problems is icons not lining up properly.
I work as a designer and a front end dev so I see (and have experienced) issues on both sides of the fence, that said I think its critical to understand there are two very different sides to the argument here, from a design point of view the icons should be consistent (Colour schemes, stroke weight, size, style etc) but those constraints are not related to development constraints. I struggle to find much of an argument from a development point of view, using svg and build tools such as gulp it should be easy to cope with a varierty of shapes and sizes (which is effectively all you have to worry about).
Decent Icons are a pain to design, they take a lot longer than you would expect and then you have to spend time manually hinting paths so that points fall on exact pixels – theres nothing more depressing than going through all that time and effort for a front end dev to use font-awesome instead!
Option #1 here.
(team has 3 designers, 3 front-enders, 4 back-enders)
Not only that, our designer already commits the icon in the right folder on Github (using the new drag-n-drop uploader).
Eventually something breaks. A file named incorrectly or a non-optimized icon is commited. But we prefer to fix sporadic issues than block everyone’s work.
Some basics to follow for designers, then a robust automation for everything I can :-)
Try option 1. Try option 1. Try option 1. Try option 1. Try option 2. OK… option 3 it is.
Me and my team are using Sprite CSS Generator and Adobe Illustrator. It’s a nice little thing and we can save our sprites as Illustrator-File and no Information gets lost. We can also rearrange the icons and the code will update the right positions. It’s nice and free: http://spritecssgenerator.formfcw.com
Our designer never listens to what we tell him! He does what he wants to do!!! Icons are different colors, sizes, and of course you can never expect him to give you an image sprite: “He’s too busy for that!!!”