And the bartender says, “Success, but you’re not ready!” So a JavaScript function walks into a bar.

Well hello everybody, I hope your Wednesday is packed full of exciting things and daring adventures. I’m Michael Fienen and you’re listening to Real Time Overview for July 11th, 2018. I hope everyone had a chance to check out episode 14 of the Drunken UX Podcast where Greg Podunovich joined us from Expand the Room to have an awesome chat about design philosophy. If you haven’t listened to it yet, be sure to cue it up, it’s not something you want to miss.

This week, Real-Time Overview gets started with a trip over to growthrock.co.

Not counting the old Xerox Star design in the 80s, we’ve been putting up with the frustration that is the hamburger menu icon since the launch of the iPhone and iOS. It moves around interfaces, behaves inconsistently from site to site or app to app, and conveys no meaning to the user in its presentation. In general, it’s bad UX design, as outlined in the Nielsen Norman Group study that we’ll leave a link to along with this article in the shownotes.

Addressing this very issue is Devesh Khanal at Growth Rock, where they’ve published a piece that examines the effectiveness of using a link bar in addition or as an alternative to hamburger icons.

In the article, they outline the results from AB tests they did in two case studies that showed across the board improvements in product views and purchases. The simple idea they were testing was whether or not moving the highest value navigation out of a hidden element and putting it where the user can immediately see it would entice them to engage better. The idea they were able to establish is that by using this approach, you can get more customers farther down your funnel, and that, my friends, is a good thing.

One finding that I found interesting was that when they were testing a link bar that could be scrolled for more options, the results trended with what you would expect on a slideshow, which is to say, people didn’t bother looking at what was hidden. The only thing that mattered was the content you made visible right in front of them.

They’ve been kind enough to outline some visual mockups of the examples they are talking about, and they also show how some other big brands are handling similar navigation on their home pages.

If you’re looking to make an argument to drop your hamburger menu, run by Growth Rock and check out what they have to suggest.

Whether you use words like accessibility or inclusive design, nothing changes the fact that making sure your websites work regardless of input method is a top usability goal for any developer or designer.

Over at Smashing Magazine, Chris Ashton is continuing a series about using the web with different limitations, and his latest article covers using the web for a day with just a keyboard. That might seem like a silly requirement to some, but he starts off immediately by identify groups of people that this interaction method is the norm for, like the visually or motor control impaired.

He also mentions power users, which I was about to gloss over, until I thought about how I myself use my home theater PC, with a mini wireless keyboard and mouse combination device. I actually use the keyboard to control my stuff really frequently because of how hard it is to use the tiny touchpad across the room from the TV. Point being, inclusive design is also impacted by the context the user works in, not just their ability.

At any rate, his story talks about a number of things you can look at implementing to streamline the usability of your page, ranging from autofocus on forms and focus states on clickable elements to designing good skip navigation links.

He also points out problems with the growing ubiquity of cookie and GDPR disclosure popups that are actually at the end of the tabindex flow, making them incredibly frustrating to get to and dismiss with the keyboard.

Chris covers a ton of ground in the article from there, and there’s some great material that can really help you understand the interaction in interaction design. It’s a longer read, but well worth the time, and I guarantee you’ll come away learning something. Check out the article over at Smashing Magazine.

Impact is the name of the game when it comes to prioritizing your search engine optimization tasks in Casie Gillette’s article at Search Engine Land.

She looks at the challenges posed when the answer to “what should I do to improve our site” is “everything.” Everything is actually really hard to do, believe it or not, and few companies are equipped to deal with everything. Instead, they need ways to target and define what’s important. It’s the age old lesson, right, that if everything is important, then really, nothing is.

The article outlines suggestions such as focusing on things that will generate the best results first, but also considering what you or your client have the ability to do at the time, or what makes sense for their particular business. Search engine optimization doesn’t exist in a bubble. It has technical requirements, business requirements, marketing, content, and more. You have to know what capacity you have available in those areas, and understand how to approach optimization in a way that respects the time and people available if you want to get the best results.

If you’re looking at improving your SEO strategy, go read up on Casie’s article, and then stop by drunkenux.com and let us know what you favorite tactics are for making sure you’re doing the best you can in your search game.

If JavaScript is more up your alley, Pier Bover has written a piece called Vue.js: the good, the meh, and the ugly, which looks at the pluses and minuses of Vue.js after a move to it from React.

Sure, it’s a bit subjective, and every framework is going to have good use cases, but if you’re still looking at frameworks and deciding which to keep in your toolbox, this might provide some insight into what makes Vue great, and what can make it frustrating.

For instance, Vue.js includes tools that you have to add on in other frameworks, and it’s ridiculously fast. But, it’s also weirdly inconsistent architecturally, and provides conflicting documentation that you need to go to Discord to ask questions about.

Like many things, it’s not good or bad. It’s just a tool, and you need to be able to evaluate it on its merits for your particular case to know if it’s what you need. Towards the end of the article, Pier makes a great comment to that end – he didn’t move to Vue because it was better, he did it because it was better for his particular team. And that’s an important lesson to consider.

Check out his blog post on Medium and see what you think, and let us know your thoughts on what makes frameworks good and bad. You can message us at drunkenux on Facebook and Twitter.

Finally today we have an article at CSS Tricks by Robin Rendle that discusses how he uses CodePen to do prototyping in the browser.

Robin helps with interaction design at Gusto, and works to create animations that help make the tool feel faster and focus users’ attention. His goal was to come up with a simple way to quickly hack together ideas to show the rest of his team. The result was some interesting combinations of CodePen submits that can reference each other, making them forkable by others, and in turn allow them to immediately see the effects of changes to their platform in the browser.

The key to his story isn’t really CodePen though, it’s the idea that the best way to understand how a browser will behave with different interactions is to literally use the browser to test it, rather than other dedicated tools like Framer or Zeplin. Rapid prototyping is the new hotness in the design world, between frameworks like Foundation and Bootstrap, the introduction of CSS grids, and the growing capabilities of built in browser dev tools. So naturally, it makes growing sense to simply work in that environment to test out new ideas.

If you’re interested in Robin’s technique, swing by his article at CSS Tricks. It’s actually pretty neat the way he uses pens inside of pens. But more importantly, understand why he’s using that approach, and what makes it powerful, and consider how you can apply it to your toolchain and development process.