Procedure

1. Open the SVG in Adobe Illustrator.
2. Where possible, unite shapes with the same fill into compound paths.
3. Where possible, outline strokes. This will make cleanup easier when we dig into the code.
4. Remove any additional paths, bounding boxes, etc, that are not a visible part of the SVG.
5. Scale the SVG to intended rendering size (e.g. if it’s a 24px icon, scale the SVG to be 24px).
   If you want the SVG to be in a 24px "bounding box", then make sure the canvas size is 24px, and your svg is your desired size within the canvas. The canvas functions as your "bounding box".
6. Clean up sub-pixel alignments where feasible.
7. Save SVG.
   
   SVGX
8. Open the SVG that was just saved by Adobe Illustrator in SVGX.
9. Select “Optimized” tab.
10. Hit [Copy].
    
    VScode
11. Open SVG that was just saved by Adobe Illustrator in Visual Studio Code (VScode).
    At this point, it’s possible that no image displays in SVGX’s preview, even if there’s code. That’s fine. Copy the code from the “Optimized” tab in SVGX.
12. Paste the SVG code from SVGX below Adobe’s original SVG code.
    We’ll be using the code from SVGX, with a few tweaks based on the Adobe original.
13. (Optional) Turn on word wrap.
    
    VScode - SVGX-pasted code
14. Ensure the svg opening tag contains only xmlns and viewBox attributes.
15. Add title tag and string directly below (outside of) the opening svg tag.
    Do describe what the image is. Don't describe what the image can be used to represent.
    <title>Speedometer</title> - Do
    <title>Dashboard</title> - Don’t
    What the image represents will be handled separately with aria-label or alt-text, depending on the implementation.
    
    Single-colour SVGs meant to be used as icons
16. Do NOT declare the colour of any path(s) using the fill attribute.
    E.g. DON’T <path fill="#000" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
    This makes the svgs harder to dynamically colour.
    
    
17. Single-colour SVGs meant to be used as images
    Declare the colour of any path(s) using the fill attribute.
    E.g. <path fill="#000" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
    This is for SVGs used as images, where there’s no intent to dynamically change the colour
    
    Multi-colour SVGs
18. Declare the correct corresponding colour of each path using the fill attribute.
    SVGX-pasted code will often strip the first colour class, and fail to apply it to the first path associated with it. We’ll need to eyeball the path coordinates, and guess match up the colour in the class to the correct path.
    E.g. <path fill="#41B59D" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
19. Remove style tags, and anything in them.
20. Remove classes, and their values.
    We are replacing style and class with fill and the colour in the corresponding class.
    
21. Delete the original code from Adobe Illustrator.
    We only want the code we pasted from SVGX, and then cleaned up.
22. Save the SVG in VScode.
23. Open the VScode edited SVG in SVGX.
24. If the SVG looks as desired / expected - congrats! It’s clean! We can now add it to Iconset.

Troubleshooting

...why does my microwave have an icon of a farting cat with a clock for a face?

Is it because cats lick their bowls really clean? Oh well, I like cats.

Some ponderings as I learn the wonders of CSS-grid, fluid typography, and all the shiny new toys kids these days have.

Gosh, CSS has gotten so much nicer since the days when we had to haul water to the top of the hill both ways barefoot in the snow.

No, designers shouldn't code
I don't think designers need to be able to write production quality code. It stands to reason that I have a vested interest in this "no", as I haven't committed production code in over a decade. Plus, production quality code, especially at an enterprise-level, is a completely different beast from building a small static website. When it comes to enterprise code, scalability, maintainability, extensibility are all very important - and I prefer to leave them to the experts (my developers).

Yes, designers should code
Ideally, designers should have some familiarity with, and understanding of the basic "materials" used to build the digital products they design. Additionally, the "materials" will vary, even across digital products. Just because I can write js and css certainly does not mean I know the "materials" for native Windows, Mac, Android, or Linux.

With that as the caveat - being able to code just enough to know my materials is a very big plus. I did a basic Vue course fairly recently. Nothing fancy, just a single page app. However, what I learnt from that course gave me a much better idea of how Vue (and React, and Angular) work at a very high level, and how that can translate into implementation. It also made it collaborating with front-end web developers easier, as we had some degree of shared knowledge.

I've also been experimenting with the "new" (not so new, I know) CSS toys all the kids have these days. What's really cool about this is that unlike the Vue course, what I'm learning about CSS is changing the way I think and design - and think about design. These learnings change the bounds of what I know are possible.

For example, I have been reading about fluid typography on the web for a couple of years now - and before I started poking around the code, it's been a very abstract sort of interest. E.g. "Nice and interesting abstract concept, I should try to design for that when I have the opportunity". Now that I've poked around the code, and gotten a basic understanding of how things work, this has changed to a much more real and practical, "ZOMG now that I actually know how that bit of code holds together, I can actually set a typographic scale that way, and see it work. And I can see how I could make it work in so many places. Waoohh!"

Here's my supernoob code-pen, which I'm modifying on the fly as I learn more about css-grid and fluid typography.
All the noob inline comments, every noob inline comments!

See the Pen Flying Red Horse - CSS-Grid Experiments by JC (@nuggettyone) on CodePen.

From a rather interesting article from mckinsey.com - Leadership and behaviour: Mastering the mechanics of reason and emotion.

Eric Maskin: Mechanism design recognizes the fact that there’s often a tension between what is good for the individual, that is, an individual’s objectives, and what is good for society—society’s objectives. And the point of mechanism design is to modify or create institutions that help bring those conflicting objectives into line, even when critical information about the situation is missing.

An example that I like to use is the problem of cutting a cake. A cake is to be divided between two children, Bob and Alice. Bob and Alice’s objectives are each to get as much cake as possible. But you, as the parent—as “society”—are interested in making sure that the division is fair, that Bob thinks his piece is at least as big as Alice’s, and Alice thinks her piece is at least as big as Bob’s. Is there a mechanism, a procedure, you can use that will result in a fair division, even when you have no information about how the children themselves see the cake?

Well, it turns out that there’s a very simple and well-known mechanism to solve this problem, called the “divide and choose” procedure. You let one of the children, say, Bob, do the cutting, but then allow the other, Alice, to choose which piece she takes for herself. The reason why this works is that it exploits Bob’s objective to get as much cake as possible. When he’s cutting the cake, he will make sure that, from his point of view, the two pieces are exactly equal because he knows that if they’re not, Alice will take the bigger one. The mechanism is an example of how you can reconcile two seemingly conflicting objectives even when you have no idea what the participants themselves consider to be equal pieces.

The 'best' user interfaces (UIs) are invisible.

The most effective UIs are the ones that make it easy, and even pleasurable for you to do what THEY want you to do.

And what a UI wants you to do may not be what you want to do. (I'll leave the question of 'best for whom' aside for now.)

For example...

Usability is ethically neutral - UI design isn't

There's an assumption that UIs that are user-friendly, and 'delightful' have our best interests at heart. From the examples above, this obviously isn't always true. It may not even often be true.

Casino UI is a great example of conflict between what we want, and what the UI wants us to do. We appear to be travelling on the same 'journey', but at the end of the day, the relationship is parasitical at best, and adversarial at worst.

Online Shopping UI has a less toxic relationship with us, as users. At least the UI isn't expressly designed to exploit our human weaknesses for profit. As a merchant's proxy, the UI very reasonably wants to make its goods attractive to us, and make it easy for us to buy stuff.

Clinical UI is what we tend to assume we're getting, even when that trust is unwarranted. It embodies the classic concept of 'best UI'. What Clinical UI wants us to do works hand in hand with what we want to achieve for our patients.

But even if the usability of all three UIs is the same, the ethical contrast between the three UI designs couldn't be more different.

When it comes to usability, it's important to remember that there's no moral value attached to how easy something is to use. Moral value comes into existence when ease-of-use and pleasure is harnessed to directing specific behaviours.

When we look at it that way, it's pretty easy to say: Casino UI is evil, Online Shopping is neutral, and Clinical UI is good.

UX and UI design are essentially the design of systems, products, and interfaces that encourage, reinforce, and reward specific user behaviours.

Whether the outcomes of these specific behaviours are beneficial or harmful to us - as users - is highly dependent on why the product was created in the first place.

So the next time someone tells you that all you do as a designer is 'make pretty buttons', tell them that the pretty buttons are just a small, unthreatening part of designing reward systems for sneaky mind control. ;)

This post annoyed me so much that I actually left a comment!

<.< A nugget rarely comments on design blogs, for some reason...

It's a nice, ranty comment, so I've reproduced it here, for my Rant Museum! ^_^

Today we are told we can rest assured that visual design is no longer so vacuous and superficial, due to the advent of flat design.

I take a different stance. 'Pure veneer' is not an insult in my book. Quite the opposite, it is the very definition of visual design. Thinking visual design is anything but superficial not only requires a profound level of ignorance, but it indicates an incredibly limited view of what visual communication can accomplish.

These rationalizations by newly turned modern minimalists are incredibly telling. If prominent practitioners are being honest with us in claiming that visual design was plagued by harmful decoration only up until the advent of flat design, then they are admitting that for years, for the history of the GUI, and perhaps even the entire history of design itself, designers have been putting on a sham project in order to dupe corporations.

Worse still, claims of visual design's insignificance tell us that design leaders never took their craft seriously. It truly undermines their credibility that it took the arrival of flat design for them to treat the entire spectrum of roles in product design with respect. Of course, as soon as that happened, they graduated from respecting traditional interface design principles.

This so-called 'maturation' in the vast majority of the design industry is in this way a major indictment of the professional history of these practitioners. If anyone should be condemned, it should not be those accused of the crime of visual design, but those practitioners who treat their job as frivolous.

Perhaps the design world breeds a form of narcissism due to its nature as a winner-take-all economy. That would explain the logic of this race to the bottom in which designers feel compelled to attack their craft before others assume they are 'bullshitters' too. In the words of Dr. Sam Vaknin:

By pre-empting society’s punitive measures and by self-flagellating, the narcissist is actually saying: 'If I am to suffer unjustly, it will be only by my own hand and no one else's.'

It is this masochistic status-striving that I find so ugly in this industry. That he who discredits his own craft is the most pious. That the most respected designer is the one who disowns beauty. This perpetual need to be the first to assign irrelevancy to one's own professional practice is the true impetus behind much of the puritanism of modern minimalist avant gardism.