An interesting thing that I’ve noticed over the past few years of internetting is how we’ve established conventions around like, favorite, &c. buttons, and how frustrating it is when sites break those conventions. The meaning of such a button is largely determined by its context; saving for later (say bookmarking, or wishlisting) for an e-commerce site, acknowledgement or praise for social media, and somewhere in between those two for blogs and other content consumption platforms. This isn’t a hard rule, obviously. Twitter, for example, has a bookmarking function, but also lets you easily browse through liked tweets. Bookmarking is a more buried option, as its intent isn’t to display praise, and I would guess that because of this intentional design decision, a lot of people simply use likes in lieu of bookmarks.
Iconography is also generally pretty standard, often hearts or stars. This defines context in its own way; users famously had concerns when Twitter moved from stars to hearts. Which makes a lot of sense – slapping a star on the tweet ‘My cat Piddles died this AM, RIP’ has a pretty different vibe than a heart. Since this happened retroactively to everything anyone had ever starred… it was certainly jarring.
Other iconography certainly exists; bookmark-looking things clearly define their intent, pins do the same to a lesser extent, bells indicate notifications, and sites with voting systems will often use thumbs-up/down or up/down arrows for this tri-state toggle. Medium, notably, went from a straightforward ‘recommend’ (heart) system to ‘claps’, a convoluted variable-praise system represented by a hand. While dunking on Medium is not the purpose of this post, I think it’s worth mentioning that this shift was enough to essentially prevent me from ever reading anything on the site again. Having to rate any given article from 1-50, and then sit around clicking as I worry about that decision is anxiety-inducing agony, especially when I know it affects authors’ rankings and/or payouts. It also feels incredibly detached from the real-world phenomenon it’s supposed to mimic. Clapping for a performer in an isolated void is a very different experience than reacting in real-time with the rest of an audience. But to get back on track, clapping additionally violates our expectations by no longer being a toggle. It increases, maxes out, and if you want to reset it to zero, you have to hunt for that option.
Which brings me to my point, and my frustration. These things are usually a toggle between a hollow heart or star and a filled one: ♡/♥︎ or ☆/★. This is very easy to understand, it mimics the checkboxes and radio buttons we’ve been using on computers for decades. Empty thing off, filled thing on. So long as we know that this icon has meaning, and that meaning brings with it a binary on/off state, a hollow or filled icon indicates what state the content is in. If a user can’t toggle this (a notification, say), it’s simply an indicator. If a user can, then… well, it’s a toggle, and there’s likely a counter nearby to indicate how many others have smashed that like button.
This is great, and intuitive, and it works very effectively. Which is why it’s extremely frustrating when sites violate this principle. Bandcamp, for example, uses a hollow heart at the top of the page to take you to your ‘collection,’ a library which is a superset of your wishlist. Wishlisting is represented by a separate on/off heart toggle. This toggle, on an individual track/album page, has a text description next to the heart; the collection button at the top of the page does not. This is utterly backward, as the toggle works intuitively, and the button… has no meaning until you click it. Etsy, on the other hand, uses a hollow heart at the top to bring you to your favorites page. But it does two things right: it has a text label, and it brings you only to things that are directly connected with a matching heart toggle.
GoComics is an equally perplexing mess of filled hearts. A comic itself has both a heart (like) and a pin (save). Both are always filled, with the toggle being represented by a slight change in brightness: 88% for off, 68% for on. It’s very subtle and hard to scan. These are actual toggles, however, unlike in their comments section. Their comments also have filled hearts to indicate likes, but they only serve as indicators. To actually like a comment, you must click a text-only link that says ‘Like,’ and isn’t even next to the heart. At this point, the text does the same absurdly-slight brightness shift from #00A8E1 to #0082AE. While it’s difficult to scan the comic’s heart icon’s brightness shift, the comment’s ‘Like’ text’s brightness shift is nearly imperceptible. A comment’s heart icon doesn’t even appear until there’s at least one like, and clicking it just brings up a list of users who have liked it. Suffice it to say, I click this accidentally on a near-daily basis. Humorously, GoComics understands the hollow/filled standard: they use it on their notifications bell icon.
These are just two examples in a sea of designs that prioritize aesthetics over intuition and ease of use. Medium tacks a filled star on after the read-time estimate for no apparent reason. Lex has both a functional heart and star toggle on every post, but no immediate explanation as to what differentiates them. Amazon seemingly has a heart toggle on its mobile app, but not its website, and it’s unclear what differentiates this from the regular wishlist. Ultimately, I don’t think this is a space that needs innovation (like, arguably, Medium’s claps), or one that merits subtle aesthetics. Folks have largely realized the perils of excessively abstracting ordinary checkboxes and radio buttons, and this relatively new breed of binary toggle should intuitively work in exactly the same way.
One of my favorite accessibility myths is this pervasive idea that alternate text is some kind of accessibility panacea. I get it – it’s theoretically a thing that content creators of any skill level can do to make their content more accessible. Because of these things (and because it is technically a required attribute on
<img> tags in HTML), it seems to be one of the first things people learn about accessibility. For the uninitiated, alternate text (from here on out, alt text) is metadata attached to an image that assistive tech (such as a screen reader) will use to present a description of an image (since we don’t all have neural network coprocessors to do deep machine-learning and describe images for us).
This is all very good, if we have a raster-based image with no other information to work with. The problem is, we should almost never have that image to begin with. Very few accessibility problems are actually solved with alt text. For starters, raster images have a fixed resolution. And when users with limited vision (but not enough-so to warrant use of a screen reader) attempt to zoom in on these as they are wont to do, that ability is limited. Best case scenario, the image is at print resolution, 300dpi. This affords maybe a 300% zoom, and even then there may be artifacting. Another common pitfall is that images (particularly of charts and the like) are often used as a crutch when a user can’t figure out a clean way to present their information. Often this means color is used as a means of communicating information (explicitly prohibited by §508), or it means that the information is such a jumble that users with learning disabilities are going to have incredible difficulty navigating it.
For someone rooted in graphic design and illustration, I typically hate running across visuals on the internet. Aside from being numbed by ads, the fact of the matter is that a large percentage of the graphical presentation on the web is just bandwidth-stealing window dressing with little impact on the surrounding content. Part of my plan with this blog was to avoid graphics almost entirely, and yet over the past month or so, I have littered this space with a handful of SVGs. I think, for the most part, they have added meaningful visual aids to the surrounding content, but I still don’t want to make too much of a habit of it.
I’m far more comfortable with SVGs (or, vector graphics in general) because I find it easier to have them settle onto the page naturally without becoming jarring. I could obviously restrict the palette of a raster image to the palette of my site, and render a high resolution PNG with manageable file size, but scaling will still come into play, type may be mismatched… aside from being accessibility issues, these things have subtle effects on visual flow. I’m thankful that SVG has been adopted as well as it has, and that it’s relatively simple to write or manipulate by hand. Following is the process I go through to make my graphics as seamless as possible.
Generally speaking, the first step is going to be to get my graphic into Illustrator. Inside Illustrator, I have a palette corresponding to my site’s colors. Making CSS classes for primary, secondary, tertiary colors is in my to-do list, but I need to ensure nothing will break with a class defining both
fill. Groups and layers (mostly) carry over when Illustrator renders out an SVG, so I make a point of going through the layer tree to organize content. Appearances applied to groups cascade down in the output process, so (as far as SVG output is concerned) there’s no point in, say, applying a fill to a group – each individual item will get that fill in the end anyway. I use Gentium for all of the type, as that is ideally how it will be rendered in the end, though it’s worth quickly checking how it all looks in Times New Roman as well.
Once I get things colored and grouped as I need them, I crop the artboard to the artwork boundaries. This directly affects the SVG viewbox, and unless I need extra whitespace for the sake of visually centering a graphic, I can rely instead on padding or the like for spacing.
Once in the SVG Save dialog, I ensure that ‘Type’ is set to ‘SVG’. I don’t want anything converted to an outline, because I want the type to visually fall back with the rest of my page. I never actually save an SVG file from Illustrator, I just go to ‘SVG Code…’ from the Save dialog, and copypaste it elsewhere for further massaging. This involves:
height="15em", or somewhere near that as far as height is concerned. This keeps the images centered and prevents unsightly scaling issues on mobile.
- Removing all references to
font-family, which ensures that my page’s font cascades down. Generally this means that it’ll render in Gentium as when I was designing it, but if the page falls back for whatever reason, the graphic will too.
- Ensuring unique IDs are used. If I didn’t name layers, etc. in Illustrator, I could wind up with several objects on a page with
id="Layer1", which would obviously violate HTML spec.
- Getting rid of any empty groups. Sometimes Illustrator just throws in a bunch of
<g></g> at the end for no discernible reason.
- Grouping similar objects, as best as possible, applying shared attributes to the group instead of individual objects
- Deleting empty
<rect>s, which Illustrator creates around text boxes. Presumably this is because, in Illustrator, text boxes themselves can have appearances applied to them like any other object. It would be nice if it was smart enough to only carry this over if there was some sort of appearance, though.
- Adding a
<title> if a description is necessary, or
aria-hidden="true" to the SVG if the image can be ignored by assistive technology.
- Likewise, if the graphic is being ‘read’, adding
aria-hidden="true" to (likely) all of the text elements within. In my diagrams, assistive tech users certainly don’t need to hear a bunch of random numbers without context, especially when I’ve provided a
Illustrator seemingly outputs SVG with the intent being structural accuracy if the file is read back in for editing, which is often counterproductive for web use, which would prioritize small filesize without a sacrifice in selection ordering or visual accuracy. To be fair, I just installed 2018 and haven’t tested its SVG waters yet, so we’ll see how Adobe managed to
mess that up handle that.
Finally, it’s worth mentioning SVGO (and the web-based SVGOMG). Very customizable optimization, definitely more useful once one starts dealing with more intricate, complicated SVGs. I’m happy to optimize mine down by hand, and stop there – but I’m keeping them to a handful of kilobytes anyway.
How we’re presented with data skews how we interpret that data. Anyone who has read a lick of Tufte (or simply tried to make sense of a chart in USA Today) knows this. Many such commonly-encountered misrepresentations tend to relate to scaling. Volatility in a trend line minimized by a reduction in scale, perspective distortion in a 3D pie chart, a pictograph being scaled in two dimensions such that its visual weight becomes disproportionate – technically, the graphic may accurately line up with the values to be conveyed, but visually the message is lost.
In taking mandatory domestic violence training at work recently, I was thrown completely off by a statistic and accompanying graphic. The graphic (albeit using masculine and feminine silhouette images) resembled:
…with the corresponding statistic that one in every four women and one in every seven men has experienced domestic violence. While the numbers made sense to me, it took me a while to grasp them, because the graphic was simply showing more men than women. It’s something akin to a scale problem, our brains are going to see the obvious numbers – four and seven – instead of readily converting the graphics into their respective percentages. How to fix this, then?
If we simply repeat our graphics such that the total number in either set is a common multiple, now it’s much simpler to process the information that we’re supposed to process. We might not immediately recognize that seven in twenty-four is the same as one in four, nor that four in twenty-four is the same as one in seven, but we do know that seven is greater than four (which caused the problem in the first place earlier), and now we’re not dealing with mentally constructing percentages from a simple visual.