Fair warning, this one is bad. Not, like, inappropriate bad, just terrible. How did the doctor revive the developer? The dev wasn’t responsive, so the doc picked him up by his bootstraps.

This is Real Time Overview for Wednesday, September 19th, 2018, I am your host Michael Fienen. In case you missed it, be sure to go back and listen to episode 19 of The Drunken UX Podcast from Monday. Aaron and I tackled a trio of topics by looking at the announcement that Google is closing Inbox, the news that the EU Copyright Directive has passed a milestone, and then we dug in to what you might want to consider when looking into Accelerated Mobile Pages. We played with a new format for the show, and we’d love to hear about both how you feel about the approach and what your thoughts were on the topics. But for now, let’s get to the stories.

Our first stop takes us by Smashing Magazine, where they’ve just announced the latest installment in their book series, New Frontiers in Web Design.

This book marks the 6th installment in their library, and offers an alternative look at web topics compared to other like A Book Apart. Whereas A Book Apart tends to release more, smaller installments, the Smashing Book series offers a larger selection of topics in one book.

In this edition, they’re covering topics like CSS Grid, design systems, service worker s, augmented reality, and a whole lot more. Each chapter is contributed by a different expert in the field, like Laura Elizabeth, Rachel Andrew, Greg Nudelman, and others.

I know that folks can squint a little at the idea of buying books on web design these days due to the speed with which they can be outmoded, but Smashing Magazine’s efforts have always been well worth picking up, and while they might address certain technologies directly, they always include a hefty dose of process and theory content that can be useful years later.

Smashing Book 6 is available today through their website, and costs $19 for the eBook, or $39 for a beautiful hardback edition.

ProfitPress takes the plate next as they come to bat in defense of the march towards Gutenberg in WordPress 5.0. Regardless of your individual feelings on Gutenberg, there’s little denying that the old way of editing content in WordPress was in danger of holding it back, and ProfitPress thinks they can convince you that Gutenberg will be worth it.

They start by considering why page builder plugins exist for WordPress in the first place, and look at what Gutenberg stands to do to them as it adds in features designed to help standardize and expand the featureset for content authors. These plugins were created to handle the needs users had that WordPress didn’t address natively, but it was rare that it was done in a simple, convenient way.

The next argument they make is that by WordPress taking on some features of page builders, it will allow existing page builder authors to focus more specifically on the customizations they offer the users, rather than the layout. Their argument is that the layout question has been a means to an end for the plugins, and that the real value is in the individual customizations they offer. In Gutenberg terms, these would become blocks with various combinations of features.

They also address the idea that while we know there’s a lot of hesitation surrounding Gutenberg, they are attributing that to a fear of change more than genuine deficiency in the product when it finally launches. In other words, it’s new and different, so naturally people hate it. I think there’s certainly more to it than that, but I also don’t think they’re entirely wrong, either.

What are your thoughts? Will Gutenberg accelerate WordPress growth like ProfitPress suggests? Will page builders find new opportunity with blocks and customizers? Leave us a comment and let us know where you sit.

The GitHub Engineering team has made an interesting announcement that they have completed the work that removes jQuery dependency from the site. This is a big deal as conversations are increasingly moving towards questioning our need and reliance on jQuery as an industry.

This change comes after more than a decade of reliance on the JavaScript library at GitHub, where, like many sites, they had used it to construct interactive components of their site, build animations for elements, and provide AJAX functionality.

They also do a good job explaining how the value of technical debt changes over time, and the things we once found useful can slowly become something that holds us back rather than pushing us forward. Part of the reason jQuery existed, after all, was to make up for features that didn’t exist, and simplify the way to write code that required much more effort in older browsers. But that was then, and this is now.

All in all, this article provides a nice look at how a relatively complex site moved towards weening themselves off technology that no longer represented the values they wanted to reflect in their coding practices. They didn’t make a hard break with anything, instead, they worked on it over time, slowly peeling away the code. There’s a lot that can be learned from that technique, and the tools that helped them do it.

You can learn all about their story at the GitHub Engineering blog, and shoot us a message on Twitter and let us know what you think the future of jQuery is on the web. And stay tuned to The Drunken UX Podcast, as we’ll tackle that very topic in a future episode.

Usability of hamburger menu icons has been hotly debated in mobile development for years. Love it or hate it, it’s here, and it’s ubiquitous. Carrie Cousins tries to put us a little at ease with an article at Web Designer Depot that attempts to provide some balance between the pros and cons of embracing the pattern of using the icon.

Doing a search for “hamburger icon usability” on Google will yield a mix of results from a number of organizations that, depending on the way you want to interpret things, can either convince you to use it or stay away from it. The Nielsen Norman Group study, which we’ll share a link to, is one of the most cited as a reason to avoid it.

That being said, like using tables for layouts, sometimes bad things just manage to stick around, and some would argue that a bad pattern that’s consistent is better than no pattern at all. Many of the arguments in support of the icon focus more on the design application of the feature, rather than user outcomes, at least in my experience.

Carrie goes back and forth, outlining many of the complaints, but trying to provide some balance for how to make good use of it, if you must use it. She also outlines important points, like if we must use them, there’s no reason we can try to apply them well, and avoid designing them badly, overloading them with unrelated content, or making them difficult to interact with.

For my part, I agree with her. We might not like them, but we don’t have a lot of better options outside of simply slapping the word “Menu” in the corner. So if we must use them, let’s do it as well as we can, but in the mean time, we can still work towards finding a better solution for mobile navigation.

Finally this week, Two-Bit History has an interesting deep dive article on The Rise and Demise of RSS.

RSS has had a long and conflicted history on the web since its inception. The implementation of RSS was technically cumbersome and confusing for many early on, and the usability of it left much to be desired from the user end. Over time, we found additional limitations that proved to be problematic, like conveying more than simple article data to how to effectively track its usage.

RSS had a relatively straightforward goal though – allow a website to provide content syndication across the web. It was meant to be openly consumed as a gateway into the content created on your website. But, as is often a criticism of AMP, it can also be a barrier to getting people to your website. If we can read content without coming to you, that hurts your end product. It was a tough act to balance, and the solutions were often half-baked.

By most accounts, RSS usage would seem to be on a steady decline. Despite that fact that the feature is still natively supported in most platforms in some fashion, and major content creators usually offer feeds, those features can be hard to find and use, and the tools are slowly becoming fewer and farther between.

In our last episode of The Drunken UX Podcast, while we were talking about the death of Inbox, Aaron even directly referenced when Google killed off Reader, which to that point was one of, if not the largest RSS consumption platform on the net.

But still, it hangs in there. In a world where data control is making way for content APIs and microservices, plenty of people, like your favorite podcasts, still very much use and rely on RSS technology to get their content to users.

Stop by the website and let us know what you think the future of RSS is. How long before we give and switch entirely to something new? Or will it’s base simplicity allow it to hold on to a niche role just like other old services?

Thanks for listening to Real-Time Overview this week and we hope you found these selections helpful for whatever it is you’re working on. For the Drunken UX Podcast, I am Michael Fienen. If you want links to any of the stories in today’s episode, be sure to swing by our website at drunkenux.com, they’ll all be linked in the shownotes there. Don’t forget to follow us on Twitter or Facebook, you can find us at /drunkenux. You can also find us on Instagram at drunkenuxpodcast.

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