Most of the time, it's as simple as making the text a lightish colour, and the background a darkish colour. But all that fails when you use transparencies in images.

Here's a quick example. Using the GitHub app in dark mode, I visited a repo which used a transparent image as an illustration:

Yikes! I can't read most of that text, even if I whack up the brightness on my screen.

Here's what the image looks like in an editor:

As you can see, the majority of the background is transparent - indicated by the traditional checkerboard pattern - with occasional blocks having a background colour.

Background transparency is be great if you can guarantee the background colour! But the web is wonderful; browsers are intended to be the user's agents. This means you can substitute the page's design with your own. Change fonts, make things easier to read, flip colours, whatever you want.

To account for dark mode - or any user changed interface - you have two main options:

1. Remove transparencies
2. Stroke outline

The first is obvious - just put in a background colour. The second is a little harder to explain.

Text can have a colour - fill:#000 paints the text black. Text can also have an outline - known as a stroke. stroke: #fff; stroke-width:2px; paints a 2 pixel white border around the text.

Here's an example SVG (I've mocked up the transparent background):

My suggestion is - put a high-contrast stroke around any object where you expect the background colour to be shown through a transparency.

Here it is, an SVG calendar which always display's today's date:

The background image is derived from the Twitter TweMoji Calendar icon - CC-BY.

Text support in SVG is a little awkward, so let me explain how I did this.

SVG supports JavaScript. This will run as soon as the image is loaded.

<svg onload="init(evt)" xmlns="http://www.w3.org/2000/svg"
aria-label="Calendar" role="img" viewBox="0 0 512 512">

Next step is to get the various date strings. I'm using the en-GB locale as that's where I'm based.

<script type="text/ecmascript"><![CDATA[
function init(evt) {
  var time = new Date();
  var locale = "en-gb";

I want to display something like "Sunday 25 FEB" - the locale options allow for short and long names. So you could have "SUN 25 February".

  var DD   = time.getDate();
  var DDDD = time.toLocaleString(locale, {weekday: "long"});
  var MMM = time.toLocaleString(locale,  {month:   "short"});

Finally, we need to add the text on to the image.

  var svgDocument = evt.target.ownerDocument;

  var dayNode = svgDocument.createTextNode(DD);
  svgDocument.getElementById("day").appendChild(dayNode);

  var weekdayNode = svgDocument.createTextNode(DDDD);
  svgDocument.getElementById("weekday").appendChild(weekdayNode);

  var monthNode = svgDocument.createTextNode(MMM.toUpperCase());
  svgDocument.getElementById("month").appendChild(monthNode);

}
]]></script>

Text positioning is relatively simplistic. An X & Y position which is anchored to the bottom of the text - remember that letters with descenders like g will extend beyond the bottom of the Y co-ordinate. This is also where we set the colour of the text, its size, and a font.

A monospace font makes it easier to predict the layout.

<text id="month"
  x="32" 
  y="164" 
  fill="#fff" 
  font-family="monospace"
  font-size="140px"
  style="text-anchor: left"></text>

A word on anchoring. To centre the anchor, use style="text-anchor: middle"

A quick test shows that this works on all desktop browsers and Android browsers. I've not tested on iPhones or anything more exotic.

Enjoy!

• GitHub repo
• Discussion on HackerNews

I'm not a graphic designer. I find it hard to get into the mindset of excellence through beauty.

I understand user flow, interactions, happy paths, delighting the user, humane design, and so on - but when it comes to the art of making something look nice I'm all at sea. I understand that, as Aral Balkan so perfectly puts it, design is not veneer - but that doesn't stop my confusion.

This is a failing of mine - one which I'm trying to rectify - but recently I've had the sneaking suspicion that some designers may have a touch of "Emperor's New Clothes" about them.

I'm going to pick on two examples. I don't think the people behind them are bad or wrong - I just don't understand how their eyes and brains work :-)

A Question of Scale

Jack Groetzinger writes about the challenges faced when trying to scale down images for different iPhone models.

My first attempt at turning one of my 2x comps into a 1x version was to just decrease the image size in Photoshop. That was naive. Some elements don’t scale well when simply downsized; they require special attention.

Here is the image in question (used with kind permission):

(Click for full sized)

I know I'm not a designer - but I simply can't see any difference here. Ok, one button is orange - but that's it. There's nothing here which screams "terrible design!" at me. I'm looking and don't understand what "special attention" either would need. Were that to be presented to me as a user, I'd know where to click and not be distracted by inappropriate design. As a product manager, I'd ship either.

I've deliberately removed the naming on the screenshots - can you tell which contains the elements which "don't scale well"?

To better understand this, I've created an animation to show the difference between the two screenshots. This simply flips between the two images, there are no fades or anything else.

Ok... Now I see some differences. On one, the buttons are slightly larger, the colours slightly more nuanced, the shading is subtly different. If I zoom to an extreme level, the font on "ebay" in slightly smoother.

I get that there is a strong need for design. I understand the need for a clear and unambiguous environment. The desire for beauty is strong with some people - and I appreciate that.

But here's the thing. That design is going to be held around 50cm from the user's eyes, drawn on a screen which is caked in sweat and grime, which is reflecting the ambient light in the room, and is - in all likelihood - cracked.

Worrying about the exact scaling of a button, and the nuances of shadowing is what we in computer science would call "premature optimisation".

How Soon Is Now?

If a developer comes to you and says she can shave 5ms of every transaction, you have to decide whether this is a suitable use of her time, and whether it will cause problems later on.

For example, if this transaction is 5ms per user - it's unlikely to be noticed. If it's a back end process used millions of times, that optimisation may be worth it.

If rewriting that code to make it more efficient comes at the expense of readability and reliability, a call has to be made on where you want to make sacrifices.

Finally, if it will take her 3 weeks to make the optimisation - how long will it take to recoup that investment?

With design, it's no different. Will users notice that images aren't a bespoke designed for their platform? Will they care? Will you have to create an entirely new workflow to generate images specific to one platform? How will you manage image assets - especially when they need to be updated?

In fairness, Jack realises that this is a step too far and says:

Perhaps it isn't worth optimizing for 1x. [...] you're spending a lot of time catering to small group of users. The crudely downsized version isn’t pixel-perfect, but it’s still usable.

Again, I'm not trying to mock Jack or any other designers. I'm just trying to understand what drives the innate desire to be "pixel-perfect".

Ultimately, the question I'm asking is - does this even matter?

For You Blue

There is a (possibly apocryphal) story about Google engineers trying to think like designers.

Google is stuffed full of people who just love to experiment on its users. For instance, Google Mail uses a very slightly different blue for links than the main search page. Its engineers wondered: would that change the ratio of clickthroughs? Is there an "ideal" blue that encourages clicks? To find out, incoming users were randomly assigned between 40 different shades of links – from blue-with-green-ish to blue-with-blue-ish. The Guardian, Wednesday 8 July 2009 18.00 BST

Here we have - supposedly - a quantifiable metric for how design impacts performance. If you have billions of interactions, and you can see a statistically significant uptake between designs, then maybe it is worth worrying about every last pixel.

In today's "ship it and see" environment, we may not have the luxury of thorough testing before launch. Even after launch, there are hundreds of large changes and features which could improve usability before we start to worry about whether #2A5DB0 beats #2A5DB1

Crazy or Misunderstood

Musically, I'm tone deaf. I just can't tell one note from another. That sucks. Graphic design wise, it appears that I'm equally out of luck.

I know that most developers are not like their users. I am deeply aware that while I'll happily use a website in Lynx, many users need and appreciate beautiful design.

I'm I the crazy one? Is there such an apparent difference between the above screenshots that I should go out and buy a guide dog now?

Does determining the exact shading on a hyperlink sound like a good use of resources when compared to all of Google's other problems?

My brain doesn't work like that of a designer - I know that. But should I even try to think like them?

It appears to show a group of police officers gathered around a blue box. No one seems to know what the box is for. I'm sure it's got a rather prosaic function - but that doesn't stop the speculation!

As soon I saw it, I could think of only one thing; chroma-key! (Or Colour Separation Overlay if you're the BBC). It's more commonly known as "blue screen". It's the special effect which allows you to remove the background and replace it with something else.

So, using my rather unimpressive GiMP skills, I created this version of the image with the blue box removed.

Mike Stead created this quick image.

And I produced this (rather obvious) effort.

You can download the original image or my alteration with the transparency.

This leads us in to the amusing territory of "hiding" human readable data in the code.  I say "hiding" because we are hiding it from the scanner - not from the human.

One of the more famous examples of this is Duncan Robertson's BBC logo.

What works particularly well is the fact that the BBC logo is already black and white, and fairly blocky.

Aliens!

After my sojourn alien hunting in Paris, I realised that there is another blocky character which most people will recognise - the humble Space Invader!

In this first code, I've made the Invader small and hidden her in some blank space. Because she's around the same size as the surrounding pixels, any error she generates is cancelled out.

We can also use Duncan's technique and obscure part of the code.

How Not To Be Seen

While the boys of Monty Python can tell you how not to be seen, for computer vision, it's rather different.

Essentially, what most QR scanners do is look at a greyscale view of the image in front of them.  The lighter the colour, the more likely the optical recognition algorithm is to see it as "white".  This allows you to put dark coloured QR codes on to a light coloured background and still have them read.

So, in theory, we could fill up every pixel of white space with a different light colour and still be perfectly readable.

In this example, I've filled in some of the white space with light green. When seen in greyscale, the green is discarded and no extra error is introduced.

Other Examples

Optiscan have gone a whole lot further and coloured in the entire code

They claim that their app will quite happily read this code. As it's iPhone only, I wasn't able to verify - but as a rule, increasing the colour complexity will reduce the chances of a phone being able to successfully read your code. It's a fine balance between readability and aesthetic improvement.

The excellent QR Monkey has a blog post detailing several different techniques for prettifying your QR Codes.

Another example of how far you can go is this QR Quilt from Rubi Studios.

In short - you can go pretty wild with your QR designs. Just remember to up the error correction and make sure that contrast between the colours you use is sufficiently high for most scanners. When in doubt - test!