What’s a programmers favorite place to go hang out in the evenings? The foo bar.

This is Real-Time Overview for Friday, October 26th, 2018. I am your host and currently jet-lagged traveler, Michael Fienen. Thanks of being patient on this week’s late episode, as I just got back from HighEdWeb in Sacramento, and my brain is still dripping with all the smart juices it got from the attendees there. Though that metaphor sounds way grosser than it probably needed to. But, this is just how my brain works, so, you’re welcome. So, before I go any farther down that rabbit hole, here comes the news.

For many web developers, their history in design trends largely begins during or shortly after the Web 2.0 movement of the early 2000s. But, we’ve been building websites much longer than that, and the way in which we’ve done it has changed dramatically since the late 90s.

Line 25 has an article posted about this called The Evolution of Website Web Design Trends from the 90s to Now that takes us back in time to look at not just how things were two decades ago, but how those times gave way to what we’re doing today.

There are certainly more in depth, academic resources for this out there if the concepts pique your interest, but this one is nice because it gives you the broad strokes of different design periods at a high level to get you started if you’re still learning about the progress of trends over the years.

There’s also an article I’ll link from Bob Kruse at 2440 Media along with this one that covers this topic, though he takes a more granular year by year look that closely parallels what Line 25 has put together.

One thing I think we need to improve on as an industry is teaching the history of how we’ve gotten to where we are. Design programs still tend to gloss over all but the latest trends, and fall short of other areas of study like architecture, advertising, or engineering, which all spend quite of bit of time going over the foundational and formative years as the fields matured and grew.

My favorite thing about the Line 25 article is how they very concisely sum up what brought on each period, and what led to the transition away from it. So if you’re looking for a little web design history this week, run by the Line 25 blog and take a peek back in time.

For the last couple of weeks, accessibility issues surrounding WordPress Gutenberg have taken center stage. The issue is one that could determine WordPress’s trajectory as a product in the near future, and Joni Halabi has come to the plate at her blog with an article that takes A Very Informal Look at Gutenberg Accessibility.

While it’s true that most parts of Gutenberg have undergone accessibility tests individually over time, we also know that many of those things weren’t tested together in an entire experience, and some of the features have changed over time. The challenge for user experience that this creates is one that basically misses the forest for the trees.

This topic has been very interesting to me as well, and you might recall a couple of weeks ago I devoted an entire episode of Real-Time Overview to it. My message then was one that was perhaps more hopeful than I was shortly after more news came out about the intentions to shelve, if only temporarily, the ideas of an external audit – an announcement that seemed to reflect the worst decision at a bad time, and one that makes it hard to defend the direction Automattic is entrenching themselves in.

This is where Joni comes in, taking the initiative to do a write up as a mostly-abled user, and reviewing the results of a Siteimprove accessibility extension’s report on the back end to determine what superficial issues remain, along with looking at her own experiences. Her title says it all – this is informal – but I think there’s something very valuable in looking at authentic experiences for users.

Her journey started with one of the most telling tasks, as well – to simply create a post using nothing but the keyboard. It’s by no means an scientific process, but it’s something you can easily do yourself against the classic editor to get a feel for which direction things have gone. The results, perhaps unsurprisingly, didn’t come back with a glowing recommendation.

This is a similar result to a comment that I seem to recall coming up on the GitHub thread about the audit – that if recreating the plugin’s example Gutenberg article with only the keyboard is more difficult that doing the same basic thing in the classic editor, then WordPress is taking a very dangerous step backwards in usability. I can’t help but agree, and I’m saying that as a relatively capable user who frequently uses a mix of mouse and keyboard controls to produce content.

I encourage everyone to go read Joni’s impressions as a starting point, then try things for yourself. That’s as good a starting place as any, and maybe with your help, WordPress can get Gutenberg back on the right path.

Before we change gears, it’s also worth noting that in the world of Gutenberg accessibility, Rachel Cherry has just announced that WPCampus is putting out an RFP to get a formal, external audit of WordPress’s new editing tool.

You might remember Rachel from when we featured her on episode 4 of Build Process. She is the director for the WPCampus organization, and is pushing forward to do the thing that Automattic seems resigned to leaving by the wayside.

Their need stems from one that affects higher education, but also any organization that by law has to use tools that conform to Section 508 standards for web accessibility, a requirement shared by most groups that operate through any facet of the US government.

WPCampus is planning on accepting RFPs into November, and hopes to have a vendor selected by the end of that month. Funding of the audit will likely be determined based on the cost of the group chosen to do the work.

On one hand, it’s really great to see an organization stepping up like this to try and help out the community and fill in the information gaps that currently exist as it applies to the WordPress platform. And honestly, I’m not sure there’s a better champion for that than Rachel. On the other hand – and I’m gonna be real blunt here – they shouldn’t have to. Automattic should be doing the audit, they should be paying for it, and the results should absolutely factor into the release date of 5.0 – and the fact that it isn’t is incredibly frustrating. Automattic as a company doesn’t have the luxury of playing fast and loose with these concerns as it applies to WordPress. Like it or not, that’s the cost of running what might arguably be the internet’s most important content management system.

At any rate, if you or an organization you know wants to submit a proposal to review the accessibility issues with Gutenberg, you can run by the WPCampus website to get a copy of the RFP. Submissions are due by November 7th. If you’re just interested in the results, stay tuned to their site and they’ll release the report once it’s complete. And stay tuned to Real-Time Overview, as soon as we have more updates on this news, we’ll be sure to pass it along as well.

If, after all of that, you thought I was done with WordPress news – well, you’re wrong. It’s not my fault though. WP Engine announced Thursday on their blog that they had acquired Array’s theme catalog and will be adding it to their own offerings moving forward. This comes on the heels of their acquisition of StudioPress earlier this summer.

The purchase of Array is notable, largely because they were also behind Atomic Blocks, which was already positioning itself to be the first big, go-to plugin to extend the options available to Gutenberg content editors. It was a great use case for how Gutenberg would be customized by plugin authors, and I readily admit to having already installed it on my own blog.

The result is that WP Engine has added some incredibly powerful ammunition to their arsenal when it comes to the future offerings they bring to the table. Atomic Blocks could help in advancing all of their work moving forward, and as they note in the post, it will also likely play a role in all of their theme work involving Genesis in the future.

It’s worth noting that the purchase of Array also includes the addition of Mike McAlister to the WP Engine team as well, meaning they aren’t just bringing in the product, but the talent behind it. And he’s just the latest. They’ve been stocking up on a lot of high end WordPress talent recently, and I like their aggressiveness.

WP Engine is going to be a company to really watch as we move into and through 2019. They’ve made some big, strategic moves in the last couple of years that gives them a lot of revenue potential outside of just hosting, and it gives them a lot of power when it comes to steering the future direction of WordPress in general.

What do you think about the purchase? Will it improve the tools across the board, or do you fear features being gated behind paid support? Are you excited about WP Engine’s growth, or do their purchases scare you? Let us know by dropping us a line in the shownotes’ comments, or on Twitter or Facebook.

Oh, what the heck, since we basically ended up with a week of WordPress news, let’s just wrap up there by heading over to the Story Labs’ blog for a tutorial: Debug WordPress, the Right Way.

One of the most frustrating things as a developer in PHP is when you do something to cause a dreaded white screen of death. Frequently, people will get into development much more quickly than their debugging abilities can catch up to, leaving them Googling for help. But, knowing how to get useful information out of WordPress when something goes wrong can save you a lot of time and headaches.

They start by reviewing one of the most obvious steps, which is to simply turn on WP_DEBUG, which, along with a couple other options, allows WordPress to generate a log file that can be used to see what it was doing when things failed. This might point you to a broken or misstyped function, memory issues, or permissions problems. Once you know that, you have a starting point to research what you need to do to resolve it rather than guessing or going hunting for a missing semicolon.

The tutorial then looks at a couple common errors that can occur and how to resolve them as examples. Sometimes this might mean renaming or removing a plugin, setting some new variables, or changing some code that you’ve written.

This is, of course, a very superficial way of debugging WordPress, but it’s also just meant to be a starting place, especially if you are on a shared host where you can’t directly access PHP error logs. If so, a whole other world can be opened to you once you’re comfortable looking at an error log.

In that case, if you’re eager to learn more about debugging PHP, I’ll leave you with one more link in the shownotes to a tutorial over at Delicious Brains that shows you how to use XDebug in your development to really hunt down problematic code.

Thanks for checking in with us on Real-Time Overview this week and we hope you found one of these selections helpful for whatever it is that you are working on. 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. You can find us on Twitter, Facebook, or Podchaser just by looking up /drunkenux, or on Instagram with drunkenuxpodcast. As for next week, stay tuned for a new episode of the Drunken UX Podcast coming your way Monday morning where Aaron and I will be talking about lessons from Health.gov that can make you a better developer.

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