How to make squeaky clean SVGs for use in applications

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

When I open my VScode edited SVG in SVGX, some paths don’t have the right colours.
It can be tricky to assign the right fills to paths, especially if there are a few of them. Try outlining strokes, and/or combining shapes with the same colours into compound paths in Adobe Illustrator before working with SVGX and VScode.

SVGX is showing a blank preview when I open my VScode edited SVG.
Test the paths by declaring a fill, like so.
<path fill="#41B59D" d="M22 11.8h-3.6V13h3l5.5 8.3h1.4z"/>
If you’re making an SVG that needs to be dynamically recoloured, remember to remove the fills after the preview looks good.

SVGX looks fine, but when I import into Iconset, it just shows a black square/circle/shape.
There may be an additional invisible bounding box / path from the original SVG, which is now being filled, and resulting in a black square/circle/shape. Either locate the invisible path in the SVG code and delete it (this can be hard), or delete the invisible path in Adobe Illustrator, and try again.



That old chestnut again: Should designers code? No... and yes. ;)

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.

Mechanism design and the invisible influence of culture and power

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 bit I quoted above really struck me as either lazy thinking, or unintentional blindness.

It bugs me that Eric Maskin uses children in a room with cake to generalise about human behaviour, without specifying important stuff.

Such as:
Where are the children from?
What are their cultural norms?
What is their relationship to each other?
Will their actions have any repercussions beyond getting less cake?

Happily ignoring all those things, Maskin goes on to apply this concept to management and organisations. Which means that power differentials and politics are also ignored, along with what I previously listed about cultural norms and relationships. It also focuses on an extremely short-term goal.

If the cultural norm is to appear generous...
...then Bob will cut an obviously smaller piece, which lets Alice choose the bigger piece if she wishes to. She may not, she may also wish to appear gracious, and take the smaller piece. But regardless of what happens, it's doubtful to me that the cake would be divided equally.

If Bob has more power - maybe he has the ability to beat Alice up without being scolded for it, even if he doesn't actually want to
...then Bob will cut whatever he thinks is fair, and count on Alice's fear of him, and understanding of the difference in power, to control which piece she takes. Which means that if Bob cuts an obviously smaller piece, he'll get a nice big piece. And if he cuts an even portion, then he'll get to feel good about himself. And in both cases, Alice's 'choice' isn't really a free choice.

Srsly Nugget? It's just cake!
You could argue that Maskin stated that 'Bob and Alice's objectives are each to get as much cake as possible', but it's pretty obvious that cake is a metaphor for money (or resources).

The fact is, in the real world, choices are rarely so clear and simple. There are always trade-offs. Of course every worker wants to 'get as much cake as possible'. ;) But maybe some workers will take less cake now, if it means a more reliable supply of cake in the future. (I.e. a foreign worker on a temporary visa will likely settle for less 'cake' until they're able to get a permanent visa.)

Humans are complicated. It's never just cake. ;)

The most effective user interfaces aren't invisible. They're sneaky.

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

Catchy statement, right? After all, UIs like those are the ones you don't notice, cause you're busy getting stuff done.

Except that it isn't true.

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...

Casino UI
Ahh, hello human, I want you to stay with me, and spend money continuously, for as long as possible, so that my owners can profit from you. :D

Human
I want to win! Winning makes me feel great! I'm sure my next big win is just around the corner!
This is rather different from you, the human, saying, I want to stay in this place and spend money continuously, for as long as possible.


Online Shopping UI (E.g. Fashion)
Hi there human, I want you to desire everything I have on offer, and spend as much money as possible, so I'm gonna make buying as easy as possible. As far as I'm concerned, you can't buy too much! :D

Human
I wanna look good to other humans! And I don't wanna be ripped off while I... ooh shiny! I need this! And this! And this! Ooh and this!



Clinical UI (E.g. Doctor)
Hey doc, I want you to accurately record all the relevant information about your patients, so that your patients can get the best care you're able to provide. :D

Human
I want to make sure that I get everything down accurately, so that my colleagues and I are able to help our patients achieve the best outcomes possible.


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. ;)

UX Rant: Oversimplification and overgeneralisation... plus supportive technology!

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! ^_^

This article kind of annoyed me, possibly because it’s too general, hyperbolic, and somewhat preachy.

It’s all well and good to say:
We will design processes, not screens.
We will design systems, not individual pieces.
We will design less “using,” and more getting results.

But…
How do you propose we ‘design processes’, WITHOUT designing the screens, assuming that the medium is digital, on a screen?

How do you propose we ‘design systems’, WITHOUT designing the individual pieces?

How do you design ‘more getting results’ without LOOKING at the ‘using’ process?

It’s all very well to say, users just want things to magically happen!

Sure they do.

But only in very narrow fields, or very very wide budgets and fields (self driving cars, container automation, subway train scheduling) can you implement something that allows that kind of responsibility-free magic, while absolving users of responsibility.

In many fields, we still REQUIRE the user to go through the process, interact with the product, perform myriad actions, because the onus of responsibility and decision must lie upon them. Because the interactions aren’t simple, and may cause harm. (I currently work in enterprise healthcare software.)

For me, as a designer, what I’d love to see more of (and to work on more of) is the ‘supportive’ system. A good example of this is computer-aided Chess Grandmasters. Where the sum of the two is superior to either one alone, even if the goal is still ‘winning’.

Computer-assisted healthcare professionals, with the goal being better patient care and outcomes. Now that’s something I want to see happen, but it’s still going to involve work on the part of the user, as well as the computer (the supportive system). And that’s the way it should be.


The Flat Design Trend & Silly Catty Designer Behaviour aka I <3 Eli Schiff

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.

- From Eli Schiff's last article in an amazing 5 part series, Fall of the Designer

Details way better than I could have how the unnerving thing about 'flat is the bestest and the coolestestest and the maturestestest' is in truth paying only lip service to serving our users' needs, while actually serving as a designer's wank.

Go read it, read it all!