Hey folks, this is our next to last RTO of the year! Sorry it’s a little late this week, but as always, we think it’ll be worth the wait. This week, we start off with a piece on security headers on sites, which is the first in a 4 part series on website security. There’s a piece on business advice for designers, another on different techniques for naming colors, and a look at what Microsoft moving to Chromium means for the future of browsers. Finally, we wrap up with a piece on accessible form styling.

Followup Resources

  1. Hardening Website Security – Part 1: HTTP Security Headers
    1. Adding HTTP Security Headers to WordPress
  2. 7 things every designer should know about business
  3. What do you name color variables?
    1. Naming SASS Color Variables
  4. The State of Web Browsers: 2019 Edition
    1. The State of Web Browsers: Late 2018 Edition
  5. Inclusive Considerations When Restyling Form Controls


This is Real-Time Overview for Friday, December 14th, 2018. Thanks for hanging in this week for a late episode, I am your host, Michael Fienen. Earlier this week, part 1 of our season finale released, with part 2 coming to you in just over a week. Aaron and I are looking back on our first year of production and having some fun while doing it before getting ready for season 2 next year. So thanks for listening all these months, and here’s looking forward to another year. As for right now, I’ve got some articles for you.

As more sites readily move towards forcing HTTPS for all users, and the availability of tools like Let’s Encrypt increases, the topic of website security is something that you can’t spend enough time on. It’s not necessarily a fun or sexy subject, but it is a necessity, and one that you need to be familiar with if you plan to help anyone deploy a website. It’s one more cog in the machine that includes things like GDPR compliance and protecting your user’s data.

The Int64 Software blog has a starter article by Matt Stacey that opens up this subject by looking at a website headers, and how they factor in to securing your site. It’s a good place to start, too, because even if you’re just using a WordPress site on shared hosting, you can impact some of these issues, compared to someone running their own complete server, who needs to deal with the much broader subject of server security.

He starts by reviewing the most basic part of this subject, which is a rundown of which security headers will be important to you if you want to make sure your site is safe to use. It’s a good review that will help familiarize yourself with a number of topics you’ll see in the future, particularly content security policies.

Matt goes on to provide example header setups for a number of different approaches, whether you’re going to tackle it at the server level in Apache or Nginx, or at the application level using PHP or ASP. It’s not a deep dive into it, but the examples should give you a model to start with. After that, you can go further and learn more on website security by reading the other three parts in this four-part series.

If you’re a WordPress user, check out the shownotes and I’ll link a simple tutorial on how to add headers to your theme. Otherwise, run by the Int64 Software blog to learn about security headers.

Over time, whether as a designer or developer, we’ll usually spend some time coming to the realization that to be successful, you need to have skills outside your comfort area. This manifests in many ways, and thanks to the amount of freelance work out there, one of the most common areas is business.

If you head over to the Beyond Users blog, they’ve put together a guide that advocates for this, but goes one step further to suggest 7 Things Every Designer Should Know About Business.

After all, you’re almost certainly doing what you do to make money, and when you leave it on the table, you’re risking your future.

They’ve broken the guide up into seven sections that get progressively more specific, going from industry level concepts, to product level, with the idea of helping you understand how you break down the different areas to identify value that you could be tapping into.

From the iPhone to design metrics, you’ll learn how to craft and position ideas to users, as well as how to sell them to businesses.

While the title of this piece is targeted at designers, I think you can easily put equal value on this for the developers out there. The concepts aren’t hyper specific, and can be applied regardless of what your specialty is.

Hit up the Beyond Users blog to catch this piece and learn more about business strategy, and let us know your favorite tips by leaving us a comment at the shownotes.

If you’ve written enough CSS in your life, you know that when you graduate to SCSS, you inevitably run into the earliest questions involving variables – What Do You Name Color Variables?

This is a question tackled by Chris Coyier at CSS-Tricks this week in his article, which doesn’t so much prescribe one answer, but instead takes a look at many different techniques you might consider using.

Color lends itself to this question in an interesting way, largely because colors can frequently change on a website, and we tend to have a wide array of them that can be very similar. At scale, it can become inefficient trying to change all the references to a single color. So, when we turn them into variables, it allows us to make one change that filters everywhere.

It’s funny to me reading this article, because as Chris goes through the different approaches, I find myself realizing I’ve used a frightening number of them at different times, especially as it would apply to a monochrome palette. For my part, I’ve recently settled on using the abstracted color names closest to what I’m using to maintain the differences between shades.

Which pattern is right for you will partly depend on how you work, and what you are working on. For instance, using numbered levels or a light/medium/dark approach can become problematic if you find yourself inserting shades over time. Likewise, using color names is better when the shades might change slightly, but still gives you the same find-and-replace hurdles you’d face just hardcoding the colors because of their specificity.

Shoot us a message on Twitter and let us know which pattern works best for you and why, we’d love to hear what folks are doing.

Your long read of the week comes from Ferdy Christant with a piece from his blog looking ahead at the future of browsers in a world with Chromium domination, now that Microsoft will be adopting it.

This is a followup to a previous article he wrote that we’ll link to in the shownotes that looks at the somewhat challenging landscape of browsers today.

While his first article had a somewhat… blunt tone to it about the problems Chromium domination brings with it, this one takes a more positive look ahead at how things will likely be changing for both developers and users.

For instance, the increasing homogeny in rendering engines means users can expect a lot of the web to work as intended with consistency. It also means less testing time for developers which means fixes can get in front of people’s eyes faster.

Those things, however, don’t come without some amount of risk. He also discusses the challenges involved when one entity has power and control over the market in a field driven by standards. This can be tempered by the small players in the field though, and a reminder that Microsoft’s commitment to Chromium is an ironic contrast from a company that itself was once the leader in the browser market.

At any rate, be sure to check out both articles at Ferdy’s blog. They aren’t short reads, but they are deeply interesting and take a valuable look at how browser engines impact the work we do in our field. It may well impact your own strategy and workflow in the coming years.

And finally this week we have a piece on accessibility at the 24 Ways blog by Scott O’Hara – Inclusive Considerations When Restyling Form Controls.

So, speaking of rendering engines, one of the most consistently frustrating and time consuming processes you go through as a front-end developer is styling forms and trying to get them the same across devices, especially when the design asks for very particular styling.

This challenge becomes even more detailed though when you start trying to ensure that those styles are also accessible. After all, making something match a design is only part of the battle.

Sometimes this discussion sounds a little silly, because some parts of forms, the most common ones, are relatively easy to style. But when you start dealing with fields that imply different behavior, that’s where we learn just how hard the process is.

For instance, I’m talking about date fields, sliders, file uploads and others. It’s a common tactic to replace date pickers with custom JavaScript solutions in order to meet design requirements, but you can also implement those in a way that can break the underlying feature for users that don’t get the special feature you deployed.

That’s where accessibility and inclusive design factors into your design strategy. Scott looks at a number of these use cases and form elements, providing a discussion of how to style the elements, what the limitations are, and the accessibility considerations to keep in mind when working with it.

Definitely swing by the 24 Ways blog and give this a read before you build your next form to make sure you’re considering all the best practices before moving forward.

Thanks for listening to Real-Time Overview today and we hope you found these selections helpful for whatever it is that you are working on this week. For The Drunken UX Podcast, I am Michael Fienen. If you want to get the links to any of the articles from today’s episode, be sure to swing by our website at drunkenux.com, we’ll have all of them linked in the shownotes there.

Tune in this coming Wednesday for Build Process number 7, where I sit down to talk with Caleb Smith and John Kuefler from DevSquared about how they got into web development and the advice they have for young developers. You won’t want to miss it.

For now, the last thing I can think of to leave you with is to keep your personas close, and your users closer.