Pixel perfection
Pixel perfection: the idea that designers and developers can have pixel-level control over how things are shown on the screen. At worst, it's an illusion. At best, the time and effort invested to try and achieve it may not be worth it. Heydon and Stephen ponder our reluctance to accept the web as a non-static medium, what our "real" deliverables are, and whether the quest for pixel perfection provides the value we tend to think it does.
The article on "hard and soft grids" that we discussed is:
Touhey, James. ‘The Bottomline on Measuring Hard and Soft Grids, Part I’. Medium, 10 August 2018. https://uxplanet.org/the-bottomline-on-measuring-hard-and-soft-grids-part-i-7ff52d7bc458.
Transcript permalink
00:37 Heydon: Well, I have another one of my classic introductions written, so I'll start with that. There's actually a lot of long words in this one. Which... I'm fine with writing long words, but I'm wondering whether... well we'll see if I'm able to say them without stumbling over them. Today we are talking about pixel perfection, a curious expression. Can anything truly be considered perfect? No, it's an abstract; an ideal. Should we pursue perfection anyway? Possibly. It is not the only pursuit in life that is futile, so why not. What is a perfect pixel? And why do we hold pixels to a higher standard than we hold ourselves? Are we just fetishists, obsessed with massaging digital ephemera into imperceptible states of regularity? And if so, can we let go and focus on more important things... like what our designs are actually there to communicate? Wow, I managed to say all of that in one go, fairly well. I nearly fell over, but I got there.
01:39 Stephen: That was, er, that was really reasonable.
01:42 Both: [laugh]
01:43 Stephen: I expected something... I don't know, I wrote an introduction, which we talked about a few minutes ago, but it was a lot more provocative in the sense that... I think it's stupid, pixel perfection. And I think that when people do it, I think it has a lot to do with ego. And it has a lot to do with working in your silo, because you can always say, "hey, the developer messed up my vision". Right?
02:14 Heydon: Yeah, yup
02:15 Stephen: So, I noticed that pixel perfectionist designers seem to focus on intermediate deliverables, so their perfectionism is focused on their tooling, like Sketch. So they're doing everything in Sketch and it's all perfect, then they hand it to a developer, and the developer doesn't do it exactly as they expected. So their perfectionism is based on this proxy of Sketch, right? Which is a poor proxy of what happens in browsers, devices, versions, operating systems, user capabilities, user specific limitations, all these different things that make up the context of when a particular person is using whatever it is you make. It's like we get to ignore that in our bubble of pixel perfection because that's the area we control completely, is this really poor proxy, right?
03:27 Heydon: So this is interesting; the way you've framed it. It's this dialectic, this relationship, between front end developers who implement a design, and designers. And from my understanding, it's the designers who are working in sketch, and have this unrealistic goal of perfection and it's the front end developers who are burdened with trying to reproduce that impossible ideal. Is that a fair enough representation of what you mean?
04:03 Stephen: That's what I've experienced in many different teams. And especially: the larger the organization, the more this phenomenon shows up.
04:12 Heydon: Yeah, okay. So, weirdly — and I think that certainly is a phenomenon that is problematic, the fundamental incompatibility with a static medium where, you know, it's not just the alignment of pixels to a grid, but also the idea that anything, like content, would be unchangeable. You would choose words to best suit the design that you're trying to exemplify. And of course, in the product, you have dynamic names, and words, descriptions, coming in from changing databases and what have you. So there are all sorts of incompatibilities there. But I guess I see that, within the role of the front end developer, I find that some people are not particularly interested in, or obsessed with the idea of pixel perfection, and others who are. And you'll have front end developers who will claim to do pixel perfect design, as in they claim that they can use whatever technique, or layout framework, or methodology to be able to reproduce pixel perfect static designs. And I'm kind of annoyed by that, but I also feel sorry for them that they have to do that.
05:44 Both: [laugh]
05:46 Heydon: It's like they state their whole career on not one, single pixel being out of place, and then as soon as it is, their CV and entire experience is a nonsense. They've let themselves down. And I think it's odd: as I said in the introduction, perfection isn't really something that can be achieved really anyway. The other dimension is... have you ever heard of the universal pixel grid?
06:20 Stephen: Er... no, I don't think so.
06:22 Heydon: So this is something that Terence Eden did an article about recently, where he was basically he was busting the myth of the universal pixel grid. It's this idea that you can kind of... the grid you work to, can somehow be calibrated so that it's an exact reflection of the pixels that make up the device's screen or whatever. So you can fit artifacts in your design exactly to pixels, in such a way that they will display optimally. And, the trouble is pixels are not uniform or even alike, really. Erm... 'pixels' is a term, I suppose, that refers to a single unit of the display. But then pixels are made up of subpixels, and those subpixels represent the different colors — usually RGB, or what have you. Now, there are all sorts of different configurations and geometries for those. We think of pixels as square things, I think. It's a bit like when you study chemistry, erm, and you have this crude representation of an atom with these rings around it. And it's a dumbed down way of seeing what it is. In practice, a pixel — a device pixel — is often not square, and frequently not symmetrical. So the idea that you can fit your design exactly to pixels is just not possible, and even if you were able to do that for one screen at one resolution and one zoom level, then as soon as the user zooms, or you move to a different screen which has a different pixel geometry, things are simply going to look different, and those pixels are going to conspire to make your design in a different way. So I think it's literally not possible to work to a universal pixel grid, because a universal pixel grid doesn't exist any more than the Earth is flat. Do you see what I mean?
08:48 Stephen: Yeah, I think that's a good comparison, because I wasn't familiar with the term but it just seems like something like the flat earth theory. It just doesn't seem to make sense to me at all.
09:01 Heydon: It says a lot about human nature. I've had conversations with people, where I've said: because of these reasons that I've just described, you are chasing rainbows if you think you can design to this very dependable, stuck-to-a-pixel-defined-grid way. And it turns out that people have been thinking that they've been doing this for years, probably because they only test on one device. So they tweak things until they do look "just so", like they do appear to fit exactly within the pixels for their specific device. And then, of course, they make the mistake of thinking that's representative of all devices. And so they can go on for years and years thinking that they are making "pixel perfect" designs, when they've really only tested on their own machine. It's kind of like a just-works-for-me thing. And telling them that is what they have been doing, and that what they have been doing is a completely futile endeavor, is not something people want to hear. So they will double down and say "no, no, it's true". I mean, I have had people who have told me they make SVGs at different sizes.
10:14 Stephen: Oh my gosh! Okay.
10:15 Heydon: Yeah, right! They have SVG, then SVG x2, you know, for retina or whatever. But that's a scalable format!
10:25 Stephen: That's also something I've never heard of. Yeah, the whole idea... the S in SVG is supposed to solve that problem, right?
10:34 Heydon: It's right there in the name, yeah.
10:36 Stephen: It is in the name. That is so weird. There is some really interesting methods, and ways of looking at things that I've noticed people do on the web, that make absolutely no sense, but are just a kind of side effect of people just not really understanding the medium and the technologies they're using. And what worries me, more than people trying to achieve some kind of perfection — because everyone wants to do good work, right — it's not the thinking about trying to do really good work that worries me, it's more the thinking that people are missing by trying to achieve this pixel perfection.
11:24 Heydon: Absolutely, I'm glad you said that.
11:26 Stephen: Yeah, so what kind of thinking are people missing? I would say that, if you really wanted to learn how to design for the web well, the thinking that you need is algorithmic thinking, systems thinking, contingency thinking. So, you have to assume that things will not work the way that you expect them to. And you need to try to emulate those situations, as much as possible and then account for them somehow. And that doesn't mean you have to account for them in the exact same way, and even if it's accounting for people using a screen reader. Or if it's accounting for people using a keyboard. Small devices, large devices, old systems. Whatever it is, you just have to assume these things. They are part of your playground; they are part of the constraints you have as a designer. And if you don't consider those, then you are basically ignoring those aspects of the medium. That's odd to me. If you're designing anything else; if you are designing clothing, fashion, then probably you are going to be concerned with things like what certain colors do, what certain dyes do, what the material does. And if you just ignore all those things, then basically you are venturing into the realm of art, where you're... I think Brendan Dawes said, "design is answering questions, and art is asking them"? Something like that?
13:19 Heydon: Oh yeah, I quite like that.
13:21 Stephen: Yeah, I like that as well. And I think that when you ignore constraints, are you really designing? Design is kind of about making something within constraints, and how well can you do that.
13:36 Heydon: So art has its own expression for this, which is "formalism", isn't it? I think this pixel perfection thing is this overly formalist way of judging an interface or design, or something that's visual that's made for the web. It's why I touched on fetishism in the introduction. Formalism is poring over the material and the way it's put together, and the worst excesses of formalism is where you care more about the semblance and the aesthetic than you do about the purpose of the thing. I always break things down in terms of priorities, because you only have so much time to do anything, erm, because of deadlines and responsibilities, and everything else. And if we're spending our time pushing pixels, or attempting to, then we're not worrying enough about the message, or the functionality. We're not worrying enough about accessibility, and those sorts of provisions.
14:47 Stephen: Right! That's the difference with art, is that you could argue that art has no predefined function, but when you are designing a website there is some reason for this to exist. I was also trained as an artist, and that's the nice thing about art: you can define art however you want and you're never wrong. But you can create your own functions and your own constraints, and then... so these are not laid upon you, and basically you're the audience, and if anyone else happens to feel something after the fact, and feel some connection to it becomes your audience. Whereas, as a designer you have a potential audience, a target audience, and a target function. A lot of these things are determined beforehand, and you need to make this thing come to life. So there's a fundamental difference there. During art, you can kind of change what you want. If you're trying to make a photo sharing application, the whole premise is photo sharing. You could possibly transform that into a fast food delivery service somewhere along the way but that would make no sense. You touched on something interesting, and that's the wasting of time. If you're moving things around — and I keep going back to Sketch because I feel like a lot of designers I know that are really perfectionist, they spend a super inefficient amount of time in Sketch, moving things around and making them just so.
16:44 Heydon: Absolutely.
16:45 Stephen: And basically, you're just going to throw it away, right?
16:48 Heydon: Yeah, because that is not the actual product.
16:52 Stephen: That's not the thing! Right? You're gonna give that to a developer, or you're going to collaborate with the developer, and that's the thing you're going to work from. But it's an intermediate deliverable, and once the product is finished it doesn't matter. And this idea that you have to have these perfect Sketch files that are completely fantastic in every way, is ridiculous, because we know that at least 80% of them you'll never even open again! And if another designer opens it, they will not understand what the hell you've done. It's a huge waste of time, and I bet companies could probably shave off part of your design team, just by having people think differently about these intermediate deliverables. And not be so perfectionist. Some things just don't matter because people just won't see them.
17:46 Heydon: Yes, absolutely. And I want to go back to the original notion you presented towards the beginning to do with the ego. And I think that the pursuit of trying to make things look "just so", just making things look nice, the reason we do that as designers, the reason some of us are obsessed with that as designers, is because we don't want to be judged as slapdash by our fellow peers. Other designers are going to notice if we're slightly, like a couple of pixels out of place along the left hand side; the left hand margin or something like that. But they're not our audience really; they don't matter. I've never done any user testing where a user has said, "I don't trust and I cannot use this product" because the kerning between these two letters is one pixel off or something like that. It's the kind of thing only designers see, and I think it's a shame that we see each other as our audience more so than we see the people we're building the products for.
19:17 Stephen: Yeah, well, that does make sense for things like hiring. Some people in their hiring practices will look for that eye for detail, and see that as a positive characteristic of a candidate.
19:35 Heydon: But that's like an analog of the whole whiteboard thing, isn't it? In programming interviews you get these kind of abstract exercises that you're supposed to do, but which are completely unlikely to apply to your actual, everyday development. It's a similar case of judging things by the wrong standards, I think, or caring about the wrong things.
20:02 Stephen: Yeah, I think things like kerning — I see all that stuff. I was trained in typography, that was one of my favorite aspects of design and I see those things all the time. But, there are times when you need to worry about kerning, and there are times when you don't. When you don't need to worry about kerning is in Sketch. You want to worry about it when it's in the end result. There's something I've been going around the office preaching, which is that the only thing that matters is the end result. That's another difference with art. With art you can be all about the process; you can be all Jackson Pollock on this thing, that's what it's about. Then you have this artifact at the end, and you either like it or you don't. That's not the case with most of the work we do on the web. The end result really matters, and all the stuff that you did to get there matters less. It only matters because it gets you to that end result. So when you see something in that end result, which is one of the best reasons to get into a browser as quickly as possible is that you can say, okay, this is really the problem; this is something we have to fix. And you have to fix it, not necessarily perfect it. It just has to be good enough. And that's hard for a lot of people to swallow. And it's one of the things, I guarantee you, where if you go to a job interview and you show you're really good at pixel perfection, and candidate B comes in, and it's not pixel perfect but they can show you what kind of impact they can have.
22:09 Heydon: Right! Impact.
22:11 Stephen: That's what it's about. What does it do for people? It may look slightly different from the original sketches I did, but... this works for blind people, color blind people, people who broke their wrist while they were skiing; it works on a watch, it works on a phone, it works on a laptop. All these things: that's pretty incredible, so you could say we, during this redesign, increased the user base by 50% or whatever. You can start focusing on the value of what you're doing, and when you focus on value that kind of gives you a framework to decide if something is worth spending your time on. And I think spending your time on kerning when it's not necessary. I mean, you should be putting real content in the Sketch file too...
23:18 Heydon: Yeah, think about the actual content.
23:17 Stephen: It's funny to me. The only thing that counts is the end result, and that's the thing where you'll start learning about "how does the interaction really work, as opposed to these wire frames that were drawn?" "How does kerning really affect the experience?" Or color, or layout, or any of these things. We might want to touch on the work you've been doing for the past few years, which is more the algorithmic type of layout. I think it's really, to me, THE way to think about visual design, and the layout of things on the web. Because it's more thinking in terms of a system, and you're basically accommodating the fact that everything will not be as you expect. You have to account for all of these different scenarios, and how do I design something that just works in many of these scenarios and not worry so much.
24:26 Heydon: It's like you're not designing a layout, you're designing FOR layout. You're designing like an algorithm, or a system that's in place to allow whatever the device, whatever it happens to be, to place things in such a way that they're within the actual viewport, that they're not obscured, that they can be seen. It's ultimately the end user's device and browser that is going to take care of that. So, the artifact that you have is meaningless...
25:06 Stephen: I don't mean to plug your... I know you and Andy have your Every Layout thing.
25:10 Heydon: Woah! You can plug it as much as you like!
25:12 Stephen: I know I CAN plug it. I think it's worth people checking it out, just to get a feel for the way of thinking. And, you know...
25:26 Heydon: Just to be clear, it's a paid product, but there's a lot of free content on there too. And one of the things I talk about early on is units, and I talk about pixels being problematic. I cover everything I've said before about pixel geometries, but I also talk about how there are CSS pixels and device pixels. A CSS pixel is this kind of abstract way of quantifying how the size of something on a screen, but then on a retina / high resolution screen that CSS pixel can be subdivided into nine device pixels — which is the closest thing to a physical pixel. They're the funny, geometrically divergent little things made of colors. And that's another thing about pixel perfection that bothers me: people seem to still like using pixel units for everything. And it's not just a problem because fonts and things that are set in pixels don't scale, which is true. I mean, with "full-page zoom" any artifacts set in px will scale, so if you press CMD + or CTRL +, that's fine. But people still use their settings; they still use their browser settings and operating system settings to change the default base font size. And if you do that? Px doesn't respond to that. And I think we've decided that it's not a problem anymore, because of full-page zoom. But inclusive design 101 is knowing that not everyone is going to use that method. You need to anticipate that people will do things differently. There are plenty of people who change their font size settings in the operating system or browser. And yes, there is that technical issue, but on top of that you have this thing where, by seeing that px unit in front of you all the time, you can kind of fool yourself into thinking you are literally making something which is 400px wide, in terms of device pixels. And, that simply is not true. Then, when you zoom, it's going to come out of that grid, in a zoom factor that is not going jump up in size in line with your grid's expectations anyway, so things are going to start falling off this imaginary grid you think you are working to very, very quickly.
28:24 Stephen: I agree. You mentioned CSS pixels, and that's one of the big misunderstanding I think, on the web for many designers. The first years that maybe I was working on the web, you'd have people come over and they wouldn't see pixels as a relative unit. But CSS pixels are a relative unit, and they really always have been, even though in many cases effectively they kind of matched to the viewport, so long as you didn't have people enlarging their fonts etc.
29:12 Heydon: Which people will do!
29:17 Stephen: But if you just ignore that fact — and many people still ignore that fact — then, in the past, effectively 1 CSS pixel seemed like one device pixel. But it's always been a relative unit, as opposed to something like millimeters. So, that's an issue! Let me throw something out there, and then I just want to get your thoughts on it, right? "The Four Pixel Grid".
30:00 Heydon: The Four Pixel Grid... so it's two by two?
30:03 Stephen: Yeah... so do you know what I'm talking about? You have the 4 and the 8 pixel grid. Everything on mobile, you have these mobile designers are like, "everything has to be on this grid".
30:16 Heydon: This is the "universal pixel grid" that people talk about, I guess... People say there is a 4 pixel grid that you... and I'm assuming this means that everything they're designing...
30:40 Stephen: Has to line up!
30:42 Heydon: This is what I mean about this kind of collective hallucination about universal pixel grids. Everything has to, well you know, so carry on...
30:53 Stephen: Yeah, so I just wanted your opinion on that. A lot of people call it the 8 pixel grid, right? The 8 point grid?
31:06 Heydon: Well it says something that people can't decide between 4 and 8 in the first instance...
31:10 Stephen: Well... so the way I see it is that 8... is built from 4? [laughs]
31:16 Heydon: [laughs] Oh right, okay... so it's modular.
31:17 Stephen: So you might as well call it the 1 pixel grid? [laughs] But okay. As far as I know, this comes from how, once you have high pixel density devices, basically one pixel is the equivalent of 4. That's the whole CSS pixel versus device pixel thing. If you say you have one pixel, it's actually built out of 4 device pixels and then. Okay, most people are calling it an 8 pixel grid, I'm seeing here... and they're using that on, say, mobile apps often. You have your viewport, and they have that viewport in Sketch, and then they put an 8 pixel grid there, and everything has to line up on this 8 pixel grid. Which is not a layout grid like we learn in design, but literally a grid. So it's a lattice-work of 8 pixel squares. So you line things up on that. And you can put a layout grid on top of that to say, "okay, if you have a column of images on the left-hand side, those are each 4 times the 8 pixel unit"... right?
32:50 Heydon: So they literally are working with the specific device's pixel geometry and configuration, as much as possible.
33:01 Stephen: Well, I would say that maybe is the universal pixel grid you were talking about. There is some universality assumed with that. I've met mobile designers who, no matter what device they're designing for, they are adhering to this 8 pixel grid.
33:20 Heydon: Okay, well that I... that's folly. I was halfway there thinking, well that sort of makes sense if you're just designing for a specific model of an apple phone. At the very least, when it starts to look right — and ultimately you're only going to be able to do it by eye — but when it starts to look right, at least then you know that on an identical device it will look the same as it looks to you. But when you're dealing with the web, and even just with different mobile devices, then surely that is a nonsense that that is even possible.
34:11 Stephen: Yeah, so I don't know the history of that or where it comes from. I just Googled the 8-point grid, and you've got some articles. I'll read a couple of title here. "The 8-point Grid: Typography On The Web", "Speed Up Your Sketch Workflow Using An 8 Pixel Grid", "Why Our Company Uses An 8-point Grid: The Bottom Line On Measuring Hard And Soft Grids, Part 1"
34:41 Heydon: Hard and soft grids? What the hell is that?
34:43 Stephen: Let me dive into that one!
34:45 Heydon: This is like when you discover the Flat Earth community online, honestly. It's like... what are you talking about?
34:53 Stephen: Yeah, so here's a sentence out of that article about the hard and soft grid: "In the midst of that conversation, my colleague said: we're actually using a 4 pixel baseline grid, not 8. That really got me thinking. Had we set up our grid templates for failure? Would changing everything to a 4 pixel baseline correct the issues we were seeing. I really wasn't sure, so I started doing some research to find out."
35:20 Heydon: Wow, what a rabbit hole to throw yourself into.
35:25 Stephen: And here's hard grid: "You an use oddly sized elements within a design, and just reduce or increase the size of the surrounding block elements to fill the space within the grid structure. The soft grid mirrors the programming environment more closely because programming languages don't adhere to a hard grid structure."
35:46 Heydon: Programming languages don't adhere to a hard grid structure? It's like... it's like they're speaking in tongues to me.
35:54 Stephen: I don't understand it. But I guess I have to investigate... So, now I see pictures here... There's an 8 pixel hard layout, and a 4 pixel hard layout, and in the 8 pixel one, even though the textiles use line-heights divisible by 4 pixels, each new copy block begin on the 8 pixel baseline.
36:17 Heydon: Oh wow...
36:19 Stephen: And then, on the 4 pixel hard layout, all objects and rows of textiles align neatly to the 4 pixel baseline, allowing for tighter grouping of objects. So...
36:32 Heydon: So... is a soft grid just a grid that you don't have to conform to? Is that what they mean? So a hard grid is where you do actually care about the grid, but if you're using a soft grid it's just, like, whatever? "Maybe it'll land on the grid... or not".
36:45 Stephen: Yeah, I think so. So someone says here: "I'm generally a fan of soft grid layouts, and respecting the code as a source of truth. I will use spacing elements in my files to help layout a baseline grid, but I generally just measure element to element. I use an 8 point grid as a relative spatial system, not a strict grid." Ah!!! Okay, they're saying soft grids are relative. So let's say you're using an 8 pixel soft grid, the way I'm reading it here is that, if you have a container element and another container element, and then you make sure that they have 8 pixels between them, and no matter where those 8 pixels show up, it's relative. It's just between them, no matter what they align to, like if you were to put an invisible 8 pixel matrix on the background, it might not align to THAT but they are relative to each other. And with a hard grid, if I understand it correctly, then you are actually looking at that lattice-work, and you are lining things up with the lines of that.
38:05 Heydon: So... so one is futile, and the other is... more futile, I think. The thing that I come back to all the time: people are very careful that there is an exact space between things — whether or not you are actually trying to line things up to pixels, folks will try to make sure the vertical rhythm for instance is absolutely spot on. But it's not possible... and the reason it's not possible is because of font metrics. Different fonts have different intrinsic metrics. When you lay out one font, you'll find that one line of that text is going to have different spacing above and below the letters themselves, just because of the metrics of the font. There is nothing you can do about that in CSS, so things are never going to look exact. The very bottom of your display font is not going to match the very bottom of the line as such, and when you bring in another font, that font will have more internal spacing, and so you're going to see, relatively speaking, different kinds of gaps just based on the kind of typographical choices you make. So that on it's own makes it completely futile to try to even just make things even CLOSE to being divided up accurately in terms of pixels
39:50 Stephen: Yeah, I sent you a link, because I think you'll find it interesting to read. But I do agree with you... we'll probably have to find some topics we disagree on. I think that would probably make things more exciting...
40:03 Heydon: [laughs]
40:05 Stephen: But in this, I think there are people who would disagree, like those who wrote these articles. But if I scroll down a little bit... and look at the examples they are giving? None of them are in a browser. So, one of them is in InVision, and the other one is in Sketch. And then they're talking about, "Do all the designers on your team use the same digital production tool? For example Sketch, Studio..."
40:40 Heydon: I'm looking at the pictures here! And they're drawing these lines exactly on the baseline of the fonts. That just doesn't happen.
40:48 Stephen: I think... yeah. I have a visual designer in my team, and they're a super talented guy. When you do print work as a designer, you can line up your baselines exactly — you can do that because the tooling is there for that, the static format that you're making means you can achieve that.
41:16 Heydon: You can do it with more success, but I still think that if you're using different fonts with different metrics...
41:26 Stephen: Yeah, but then you adjust your baseline.
41:28 Heydon: Yeah, so then you're literally pixel pushing, aren't you? You're compensating for the design of the font itself, and artificially adjusting it in a way that, yeah, browsers wouldn't do for you. Unless, I mean, you could do that in a browser, but imagine doing all that relative positioning all the time. I can't bear to think about it.
41:57 Stephen: But for, say, a book you could. I think designers were used to doing that, and then — especially graphic designers when they come to the web—they kind of want to work in the same way, so they're measuring things from the baseline. This is really... I think this article really gets into what we mean when we say "pixel perfection". They're talking about 4 pixels, right? Or eight... in this case. But I think they're arguing that the 4 pixel grid is better than 8 pixel grid, because then you're even more pixel perfect [laughs]
42:38 Heydon: [laughs] Surely you're more pixel perfect with 8 because there's more pixels to play with? I don't know.
42:44 Stephen: Why don't we just propose the 1 pixel grid, so you can really make it perfect, right?
42:48 Heydon: Mmmmm.
42:49 Stephen: The 4 pixel grid is basically 4 times worse as far as perfection goes, compared with the 1 pixel grid. And most people are like 8 times worse. That's 800% worse, than the 1 pixel grid.
43:03 Heydon: [laughs] 800% worse!
43:05 Stephen: So that means, anyone using an 8 pixel grid... they're terrible at their job. They are not pixel perfectionists at all.
43:13 Heydon: So that's the end of the podcast [laughs] So actually, er, I did a bit of research myself, and I didn't find anything along those lines. But I did find a website called pixelperfection.in, and I feel bad picking this out... but I don't know who these people are, it just came up in my search results. But, er, I'll tell you something for free: pixelperfection.in is NOT pixel perfect. I checked. So, you're inevitably making a false claim aren't you? In fact, it has one of those things where you have, like, calls to action and when you hover on them they kind of expand, and kind of jump out towards you...
43:59 Stephen: Okay, I'm seeing a "coming soon" page, is that right?
44:04 Heydon: Oh right, that might be a different one. Let me just double check. Oh yeah, it does say coming soon, but if you press the massive plus button... you'll see the boxes, yeah?
44:19 Stephen: Oh those things, yeah.
44:20 Heydon: Can you see what's happening when you do that?
44:22 Stephen: Yeah, there's like... well I'm getting a semi-transparent grey box with a plus sign... which is supposed to be in the middle, but is actually...
44:34 Heydon: That's not pixel perfect, first of all because it's probably about 24px out. At least!
44:43 Stephen: I think working on the 1 pixel grid would have helped them, in this case.
44:46 Heydon: [laughs] If they used just 1 pixel, maybe... but more of a concern for me is when you hover and zoom—and this may just be in Firefox—but the text is obscured. So where it says "mobile your business"... which is not pixel perfect, but IS bad grammar. Er... when you focus on that, the text actually gets cut off. The "B" in business disappears. Can you see that?
45:20 Stephen: Yeah, yeah.
45:22 Heydon: Yeah. So, not just not pixel perfect but... I think a better term would be... broken [laughs] It just goes to show that when you... I try to manage expectations, and I wouldn't claim to be making things pixel perfect, erm, because I know that it's impossible. It's easy to make fun of people who call themselves pixel perfection, and that's cheap, but I'm doing it anyway! [laughs]
45:53 Stephen: Yeah, so, okay. So we're not just two grumpy dudes complaining about pixel perfection, what are some things that people can do to let go of that a bit? In my team at the moment, I have one designer I'm working with, a super talented person... I mean, I have more than one designer, but this particular one has this idea they want to get this perfect, and I said , "if we work together for a year, I'm going to cure you of that. Right now, you feel dirty, right?" I tell him, "don't do this one thing perfectly, do it quick!" And actually what really works—and I'm offering the first tip here—is to set a time limit. We had this project, and I said: "In one hour we will leave this room, and it will be done, and then we're not going to touch it". And that forces you to get into this mode of thinking...
47:12 Heydon: You have to prioritize! You have to prioritize the important stuff, and get the important stuff done. You can't afford to pore over individual pixels, anymore.
47:21 Stephen: Right. And I understand that, for someone who really tries to make something "perfect" all the time, they feel bad. I get that sometimes. A lot of us are perfectionists in the broader sense... and that's not a good thing. It's more like a sign that you're never quite happy with the work that you've done, and we need to get to a point where you can say, "I did a good job, it's fine".
47:54 Heydon: We just need to find better ways of measuring it, don't we really?
47:58 Stephen: Yes!
47:59 Heydon: And things being very ordered and regular and insipid, let's face it, is not a good way of judging it.
48:07 Stephen: Right, so you think that thinking about which metrics you're using to decide whether your work is good enough can help?
48:18 Heydon: I think that's another thing, isn't it? I think that's tip number two: to think about what your goals are. And I liked your use earlier of the term "impact". The exactitude with which you aline things to a 4 pixel hard grid, even if that were possible, would be imperceptible to a user. They are not looking at your service formalistically. You need to reevaluate what you're actually aiming for, and what impact it is you're trying to have. So, you know, in terms of measuring it in terms of exactly where the pixels are, measure it in terms of... I mean, we're getting into UX and user-centered design territory, but actually measuring it in terms of what value people can get from it.
49:20 Stephen: But if you're... let's say a visual designer—and I hate the term "visual designer", it's almost like you put some kind of decorative sauce on top of the meal, and you make it taste better...
49:33 Heydon: Communication designer is probably better, isn't it?
49:35 Stephen: Yeah, well, I mean graphic design, which is what I studied in school, those were designers who really solved problems, it wasn't just a visual thing. But the visual aspect is really important. So...
49:51 Heydon: Yeah, but it's a question of, whenever you do something visual, it's asking yourself what that actually offers in terms of a message. So, if you're doing something visually and it helps to convey the message or the purpose, then it's important that the visual artifact, or dynamic, should be there. But, I mean, a massive arrow pointing towards something so that people know that thing's there, and that it's important? That's a visual design decision. But, the exact width and height of that arrow in pixels, or whether or not it adheres to the vertical and horizontal lines of your 4 pixel grid... does not fucking matter.
50:46 Stephen: [laughs] I may be speaking out of turn, but I think that may be the perfect way to end this episode. What do you think?
50:57 Heydon: Cool. I've enjoyed it again.
50:59 Stephen: You wanna repeat it?
51:00 Heydon: We'll do another one. I don't know what on!
51:02 Stephen: No, do you wanna repeat the conclusion?
51:05 Heydon: Oh no... I don't think I'll be able to say it again, it just came out. It was an ejaculation.