Typically when you log into your website, you go to a Post, Page, or other “thing” to add or edit text, images, and more. Central to your website experience is a the big blank Text Editor. Most of the stuff you want to show your users goes into this Text Editor. If your site has a bit more customization, you’ll have extra meta boxes to add extra bits of information and content. Whether it’s for SEO or linking to related resources, these meta boxes aren’t always displayed in the editor where they show up in your content. Heck, sometimes they don’t even show up in your content at all.

When you think about, it’s not the most intuitive way to deal with your content. How did we end up here? Years ago, the WordPress admin interface was revolutionary, if you wanted to publish and still own your content. Instead of having to learn HTML, you could simply enter a username/password, write, and show the world—totally friction-less. Just type, publish, and it went live.

As website complexity has grown and site owners have figured out how visitors use websites, our understanding of content has expanded well beyond just a wall of text and a picture. Content, these days, can be relationships to other posts and products, supporting images, sales pipelines, tutorials, forms, and a billion other things. Essentially, web publishing has outgrown the humble Text Editor view. WordPress agencies and plugin developers have been dealing with this by bolting on meta boxes as needed.

WordPress core developers see this Frankenstein approach as problematic. The solution is Gutenberg. Named after Johannes Gutenberg, who invented a printing press with movable type more than 500 years ago, the Gutenberg Editor is very much beta software. Each point (0.0.x) release of Gutenberg has significant changes and improvements over the previous, so it’s difficult at this point to see where it will end up. Because the developers are seeking active feedback, each update polishes the user experience a bit more. However, we’re still months from Gutenberg being part of WordPress core. So, expect many more changes before all the dust settles.

Gutenberg is an attempt to make the editing experience feel a bit more logical. This is accomplished by treating everything as a block. Ideally, this will make the task of creating content much more intuitive (and heck maybe even fun?). One of the biggest changes that hasn’t been accounted for in Gutenberg is what to do with all of the “legacy meta boxes.” In some cases, they’ll make sense as a block that is added to the content. But some meta isn’t necessarily something you’ll need to display. That kind of content doesn’t fit in the Gutenberg block model.

We expect Gutenberg will ship in WordPress 5.0. That’ll probably be in the second quarter of 2018. In the meantime, it will be important to stay on top of both WordPress core and plugin updates as some of the groundwork for dealing with Gutenberg will be laid before it’s available in the backend. Start thinking about the metadata you use in your posts. Unlike when Facebook changes the interface, WordPress is giving us a huge amount of notice. If you need help in either of these areas, reach out to experts at Maintainn. They’re actively preparing for Gutenberg and are fluent in all things WordPress.

Photo by Bruno Martins on Unsplash

The post Preparing for Gutenberg appeared first on WebDevStudios.

If you aren’t familiar with rubber ducking, the term comes from the book The Pragmatic Programmer in which a dev would explain, line by line, their code to a rubber duck.

Writing code is hard, and interesting, and tricky, and challenging. And frustrating. And disappointing. And humbling. This is especially so when faced with a bug we can’t identify, or a side effect that makes no sense.

I often take to our company Slack when I’m in a sticky situation, asking for someone that isn’t busy to rubber duck. It seldom matters who is available. The role of ‘duck’ isn’t to solve the problem. It’s to listen, occasionally ask questions, and relate to the feeling of being ‘stuck.’ They don’t need to know the project, my IDE, or even understand the code.

I’ve announced, “I need a to help me with some weird js modal issues,” and ended up discovering my issue was with post content. I’ve had a session that took ten minutes. Then I realized I was testing on staging while making code changes on my local.

I ed my first WordPress patch.

via GIPHY

Even more fun than ing is being the duck. Asking for a in a team can feel like you’re being a burden. It’s an admission of, “I can’t figure this thing out.” We as devs take pride in how we can think through any sticky situation.

I have ed for some amazing developers at WebDevStudios. It’s easy to forget as that your job is not to solve the issue. It’s to listen, empathize, ask questions, and relate.

I’ve seen issues in code in the first minute, and I’ve spent thirty minutes listening without understanding more than the cursory description of the problem, and everything in between. In all cases the ing was successful because the goal isn’t to jump in and solve the person’s programming issue. It’s to reset the approach and provide new perspective. There is no place for blame, pity, or frustration. It’s simply an opportunity to hack our human brains into being okay with… well… being human.

Normally, ing isn’t super time-consuming. A screen share starts, the dev with the problem frames it. The may ask for some general background to get a mental model of the problem and then…

¯_(ツ)_/¯

Sidebar: I know we as devs aren’t supposed to be social. Writing code is usually a solitary endeavor. We all know that the final draft of our code has been wrestled with, refactored, and rewritten. When you duck or rubber duck, you are inserting two people into an incomplete thought. Be cognizant of the person behind the code. Sometimes it’s hard to remember that we are not our code.

ing is an amazing tool. It gives perspective; it resets our approach to a problem. It doesn’t indict or blame. Hopefully you have a great team of developers you can with. If not, take to Twitter, your local meetup, or whatever social circle of technical people you have and agree to for one another. Most importantly, set the example and be the you’d want.

Photo by Andrew Wulf on Unsplash

The post Rubber Ducking appeared first on WebDevStudios.

About a year ago, I declared to several WCJAX organizers that I would be interested in helping organize food, but only if we could have a Popsicle party on Saturday. It’s fair to say that I’m food-motivated. After all, I taught myself good git habits using a king-size bag of M&Ms as inspiration.

At any rate, my declaration worked. I successfully involved myself in the event as food and party organizer, which meant that I didn’t have to make any real decisions that mattered. Coward or genius? It’s hard to say… but more likely a smattering of both.

A borderline WordCamp tradition, we offered BBQ for lunch on Saturday. One of the goals of WordCamp is to bring WordPress to local user groups supported by local users. Using the same logic, nearly all of our dining options were local caterers and restaurants.

True to my word, we celebrated the early afternoon with super-swanky gourmet Popsicles. At this point, with my previous promise fulfilled, I simply joined the masses and enjoyed the rest of camp.

The local nature of camps means it’s nearly impossible to not be vested in providing an amazing experience. As a result, our after-party presented an opportunity to show how “the bold new city of the South” networks. Using the same facility as our speaker event, we had light hors d’oeuvres and BOARD GAMES! Deemed by attendees to be “introvert-friendly,” I’d say it’s safe to say we’ve found a partner in entertaining WordCamp Jacksonville attendees for years to come.

If Saturday was a success, Sunday was the pinnacle of my two-day career as the food and party organizer. I’m known for having an obsession with tacos. Using a local caterer, we were able to offer a taco bar for lunch on Sunday.

Aside from the food, yes, the second WCJAX was an overall great accomplishment. My coworker, Jodie, even joined in the event presenting a session called “Connecting in a Digital World.” Because our team is 100% distributed and we work remote from home, it’s always a bonus when we get to see fellow WDS-ers in person.

It takes a strong team to organize a successful WordCamp. I count myself lucky to know six amazing organizers in Jacksonville. WordCamp attendees are often active WordPress community members, and WordCamp sponsors know the value of WordPress. Bringing all of these like-minded individuals together to learn and celebrate the power of WordPress is bound to create an atmosphere of camaraderie and fellowship. If you have never attended a WordCamp before, hopefully I have convinced you to do so now. But, I can’t promise that yours will have a Popsicle party or a taco bar. That is, unless, I’m involved.

To find a WordCamp near you, visit WordCamp Central. To keep up with which WordCamps WDS will be attending, visit our WDS Gives Back page.

The post Post Event Report: WordCamp Jacksonville appeared first on WebDevStudios.

There are numerous articles about how to work remotely, offering advice like: establish a routine, over-communicate, limit distractions, and have an area for “office” use only. Those are all fantastic, and there are probably a few more tips that should be included.

For me though… the siren song of being a remote employee is, well, the “remote” part. By that, I mean not simply remote from the rest of the company but remote from the normal comforts of home.

I often work from my hammock or back porch, but I’ve been known to `git push` from my children’s schools, local parks, docks (with requisite toes dangling in the water), the backseat of a van on a road trip to WordCamp Miami, my garage, a hotel room, friends’ patios, on a hike, the beach, my local sushi shop, coffee houses, and various other places.

Many of my colleagues take similar approaches, sometimes hailing from coffee shops, boats, the gym, their patios, and beyond. Here are some things I do to make “remoting” easier:

Simplify
Web development doesn’t have a lot of prerequisites. A computer to bang on, an internet connection to send your code up, and that’s about all a remote web developer needs!

I work from an older MacBook Air that gives me gobs of battery life. There are no external monitor, keyboard, mouse. In most cases, this means I can work half the day without thinking about charging (more on that below).

Software
My local development environment is pretty lightweight. I like laravel valet, because is allows me to avoid anything that requires me to run a virtual machine (VVV, Local by Flywheel, etc.). My general IDE is PhpStorm, but I’ve disabled many of the power-hungry plugins. I don’t use the terminal storm provided, and I don’t use the git tools. So, those are two easy wins. The terminal that ships with MacOS is more than sufficient for most things.

Outside of that, I keep an eye on what my computer says is using “Significant Energy” and either kill those tasks or figure out how to make them behave a bit better.

I hear you. What about Slack? Currently, I use the Slack app for my primary team and keep everything else on my mobile device with alerts on. If need be, I log into that team in-browser. That’s because I aggressively use a Chrome extension that suspends inactive tabs. However, Chrome is rolling out a similar native option. I’ll be curious to see how that works.

Be Prepared
I drive carpool most mornings. My checklist, as I walk out the door, is just two things: my coffee and backpack. That way, if the mood strikes or traffic is bad, I can just get to work.

In my bag is a set of all the cables I use at home, which, to be fair, is a laptop charger and phone charger. It’s nice at the office to route your cables and make things looks presentable. It also takes time. I have my “permanent” laptop charger setup at home and another in my bag.

In addition to that, I have a set of ear buds, and… not much else. If this bag is heavy, I’m not likely to want to deal with the hassle. But with it weighing so little, I rarely give it a thought.

Security and Privacy
Auto-lock your devices. That is kind of a no-brainer anyway. I generally am not working in a public place with any kind of crowd, but when I do, back to wall is a good practice. On the occasions I am working somewhere a bit more public, the earbuds come in handy. Often times they aren’t even plugged into my laptop. White cabled earbuds are the universal sign for “do not disturb.”

Also, since you’ll be working on someone else’s connection, a VPN is a requirement.

Practical Matters
One of the major issues I run into while working outside is screen washout. If I’m in my IDE, restoring visibility is often as simple as picking an inverted color scheme. However, when that’s not enough, I find that hitting up the accessibility settings and increasing contrast tends to restore screen visibility.

What about wifi? When I’m outside, I often use my phone as a hotspot. Some carriers limit or throttle hot-spotting. I’ve not had issues, but I also have a mental list of locations close by that have given me permission to hop on.

Relax
Yep! Breathe. Things are going to work out.

Most remote workers are driven and need to “fix that one last thing” before the next screen break, client call, lunch, or the end of the day. Working away from the office in an uncontrolled environment means that sometimes you have to break a bit earlier. Several times I’ve parked myself somewhere long enough to end up driving home in rush-hour traffic, a thing that working remotely is supposed to avoid.

I dig the frenetic energy of working from an unfamiliar location. I find it exciting and as a result, I have more fun working!

The post Working Remotely appeared first on WebDevStudios.