Who is a JavaScript engineer’s favorite blues musician? Stevie Array Vaughan.

This is Real-Time Overview for Wednesday, October 31st, 2018 and a Happy Halloween to all of our listeners out there. This past Monday was episode 22 of The Drunken UX Podcast and we discussed the 5 year anniversary of the failed launch of HealthCare.gov, and what lessons we should take away from it when it comes to web project management. If you haven’t already caught it, just check in your favorite podcast app, it should be the next one right behind this episode. But, I know what you’re really here for, and that’s this week’s article roundup.

Starting things off, we head over to an article from Benek Lisefski at UX Collective that sets up the argument that Designers Who Can Code Are More Valuable.

This is a concept that makes the rounds every few months, and there are even courses dedicated to helping designers learn how to code like the one over at The Gymnasium that I’ll leave a link to in the show notes. It’s an interesting argument, because you rarely hear the argument that developers need to know how to design. It all stems from the idea of form before function.

Benek starts off with an anecdote that’s familiar to many of us, coming from a past where you had to do everything yourself, and the tools to help you out were rudimentary or non-existent compare to what we can work with today. To an older web developer, design and development naturally went hand in hand in a world where few companies started with more than one web developer. Fast forward to today, and these specialties have forked into their own disciplines, with even more granularity continuing to form.

We’ve gotten smarter, but also more complex. However, changing times or not, he makes the comparison that designers knowing how to code are like architects that understand the limitations and capabilities of building materials. It means you can create something that can be effectively built. Think about all those students studying architecture right now, churning out amazing assignments with beautiful structures that simply cannot be physically constructed. Design follows similar restrictions.

As he puts it, this all comes back to cultivating a toolbox that elevates you to being a great designer and capable business partner. Having a skillset that at least gives you insight into the work your counterparts do makes you more cost-effective and instills trust that you’ll create something the business can build in a budget and timeframe they can rely on.

You don’t have to be a great coder to accomplish that. It’s just all about cultivating an understanding of the skillsets needed across your industry to ensure everyone can do their job. You can catch all of his thoughts on the subject at his blog post over at UX Collective.

The Nielsen Norman Group is up next with a piece from Alita Joyce on Microinteractions in User Experience.

To quote their summary: “Microinteractions convey system status, support error prevention, and communicate brand. They are initiated by a trigger, are single-purpose, and can make the experience engaging.”

While it doesn’t come up in this particular article, microinteractions find a fond pairing with the idea of microcopy – small, single purpose words and phrases used to convey meaning, help, and information to the user. The idea behind both being they are small, meaningful nudges to help a user stay engaged and understand what an interface is doing.

And by the way, if you want to know more about microcopy, I’ll leave a link to Nick Babich’s article Microcopy: Tiny Words With A Huge UX Impact in the shownotes as well. It’s a nice read if you aren’t familiar with the concept and why little bits of text matter to user experience.

Of course, microinteractions can and frequently do include microcopy, but as its name implies, it’s very much about the response and feedback cycle a user has with an interface. They can tell you a specific error occurred, like a save button failing, or alert you to an update to an item. They can provide additional options that otherwise don’t have a place in the UI or simply indicate background activity is happening.

Alita even takes the use case examples outside of the digital realm, and explains how they have a place with day to day appliances you might interact with in the real world, which helps cement this idea of how things we work with do a lot of very small things to ensure they feel reactive to our interactions.

The Nielsen Norman Group is known for pumping out top notch usability resources, and this is no exception. Be sure to add it to your reading list for the week, and stop by their blog to check it out.

Allow me to pose a question to you: Is front-end development having an identity crisis? This is the question being asked by Vernon Joyce in his post by the same name.

This particular post offers an interesting supplement to our first suggestion in today’s episode. Whereas Benek’s article talked about the importance of having a diverse skillset, Vernon is looking at how that diversity is changing the way we think about roles like a “front-end developer.”

One of the important points he makes, however, is that this is more of a business problem than one we ourselves are creating as an industry. He discusses the challenges businesses have trying to fill increasingly complex needs, using recruiters or HR departments with poor understanding of the specific details of the job, which results in many things getting thrown into the pot of front-end development that probably shouldn’t be.

Case in point, he highlights two job listings side by side, both labeled as front-end, and both containing needs that are very specific, and very decidedly back-end focused.

All this being said, I don’t entirely agree with the way he breaks down the role and responsibilities of a front-end developer. I think that’s because he makes some statements about what they should and shouldn’t do that felt a little open to interpretation, and also got mired in some of the semantics of our industry – a topic for another time that I have plenty of opinions on.

All that said, his general point is well taken and worth stopping to read and consider to decide where you think you fall on the spectrum, and if maybe you aren’t due for rethinking what you actually refer to yourself as.

There’s a whole lot to unpack, not just in Vernon’s article, but in our industry when it comes to how we think about all the roles we fill. Not just front-end development, but UI, UX, interaction design, accessibility, devops, and more. Cross-pollination is unavoidable, but we might owe it to ourselves to stop once in a while and ask the all important question: are these people trying to hire me to do what it’s called, or are they really looking for something else?

You know as well as I do that the next few weeks are likely to bring a pretty constant flow of Gutenberg articles. This week, it’s Iain Poulson from Delicious Brains considering if Is Gutenberg the End or a New Beginning for WordPress?

It’s a good question, as the seas are really choppy right now for the old, celebrated content management system. This particular article looked at this topic back in January, and is newly updated this month, so if it sounds familiar, you might drop by and check out the update.

In particular, they’ve included updates on things like the accessibility firestorm that’s going on, and the departure of accessibility team lead Rian Rietveld. Iain used an interesting choice of words for all of this at one point, too, when referring to the development of Gutenberg – collateral damage.

It’s an interesting way to think about the anger and frustration going around about the usability problems Gutenberg has. If people abandon or at least delay the update, it’s also collateral damage. Users are collateral damage. The PR problems it’s creating is collateral damage. The problems within the core developer community is collateral damage. There seems to be a whole lot of collateral damage, and it leaves one to wonder how much of it is too much?

There’s no good answer, and the reality is, WordPress will probably survive in the long term just fine. At the same time, ClassicPress, a Gutenberg-less fork of WordPress, is chugging ahead full steam to address people’s concerns. ClassicPress has chosen as its tagline the phrase: Powerful. Versatile. Predictable. It’s that last word that really stands out as signal to users that they aren’t going to take the sort of risks WordPress is right now.

Iain covers a ton of ground in this article at Delicious Brains, and it’s worth stopping by to read if you’re interesting in what the future holds for WordPress.

And finally this week, we have one more piece coming to you from UX Collective by Goncalo Andrade with advice on how to make a dynamic design system.

Design systems influence pattern libraries which reinforce style guides. In the end, they all work towards trying to standardize and maintain a design so that it is repeatable and consistent as your site grows and matures. The challenges arise when elements are put into usage in situations slightly outside their specs, and a developer hasn’t anticipated the use case.

This is the challenge of translating a design into a usable element. Developers often think very literally about the thing they are building. I think in general, we’re getting better at remember to ask questions about things, like “What happens if this headline is three rows instead of two?” But, it’s still very easy to see something and not take everything into account. Or to consider using variants on a whole block instead of flexible elements inside of it. It’s an incredibly fine line to walk.

His argument is that we are missing the forest for the trees when we create our systems. We build the elements that we’ll reuse, but we don’t set up the rules and guidelines that support them and will explain how they should adapt to different conditions.

An example is presented that involves a button. A button is a simple element. Easy to design. Easy to predict. But the full, context-aware presentation of that button can often be missing from pattern libraries. Buttons exist in things. They should be positioned a certain way, and we often forget to consider that and establish rules for where the button goes, not just how it looks.

While the advice in this article is about how rules can make your design system dynamic and supportive of flexibility and reuse, I’d argue that a design system that doesn’t do this isn’t even a system at all. It’s just a pattern library. A static resource that shows you a bunch of elements and the code to use them, but lacking in the rules and logic necessary to explain their purpose and overall treatment within the design itself.

If you want to consider your system to be an actual system, that underlying ruleset is integral. It will answer questions, fill in the gaps, and explain your design without ever needing to ask a designer. It can be handed off to a third party to help you produce something on brand and seamless with your existing work. The more it can do that without additional human interpretation, the better a system you’ll have moving forward.

Thanks for checking in with us on 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 them all in the shownotes there. I hope you’ve been enjoying Real-Time Overview this year, and if so, there’s a couple things you can do to help us out. First off, make sure to smash that share button in your podcast app so that you let others know how useful our segment is for you. Then, if you can spare just a minute, go to iTunes or podchaser.com/drunkenux and leave us a rating or review. It only takes a second, and we would appreciate the heck out of it.

Until next time, keep your personas close, and your users closer.