Forem: Ted Goas

Suddenly Working from Home?

Ted Goas — Tue, 17 Mar 2020 00:47:05 +0000

A Short Guide to Working Remotely for Co-located Teams

COVID-19 is unlike anything we've seen in our lifetime. Companies are taking precautions to protect their employees and (hopefully) curb the Coronavirus's spread. This means many are closing their offices and asking employees to work from home.

That's the right call for us privileged folk who can work from home.

But now you're scrambling to translate your team's office culture online. Let me tell you something:

You can do this!

Working remotely is less scary than it may feel like at first. It's about the people and the culture, not the tools. I'm not even gonna talk about tools in this article.

Maybe you start by doing a few Google searches and seeing what tips are being shared on social media. Companies like Buffer, Zapier, GitLab, Basecamp, and Automattic come up a lot.

If you only take one thing away here, make it this:

Do not compare yourself to these companies

These companies have years of experience working with a distributed workforce. It's in their DNA. Sure it's insightful to see how they overcome the challenges of working remotely, but it's a lot to take in for a team trying to salvage some resemblance of productivity amidst a pandemic.

Remember, this isn't about remote work, it's about forced isolation. As Andreas Klinger says:

Your goal right now is not to become a fully functional remote team overnight. Your first goal is to establish an emergency work-from-home setup that sustains your productivity.

Got it? Good. Phew!

With that out of the way, think about the most important parts of your team's culture. Remote work isn’t an all or none concept, so you can pick the parts that work best for you and your team.

I've worked remotely since 2016 when I joined Stack Overflow, but I worked in office jobs for 15+ years before that. I remember what it's like to be on both sides. Here are a few random thoughts based on that transition:

Productivity will probably decrease.

"Can you hear me?" "Can you see my screen?" There will be technical glitches. Folks won't grok all the new tools right away. That's ok. Remember we're just trying to salvage what we can here, especially in the first few weeks.

Establish working hours and norms.

If your company has an ass-in-chair mentality (hey we've all been there), set up a #current-status or #hi-bye channel in chat where folks can signal when they're available and when they're away. It's also important to be more aware of the time, especially late in the day. Since you're already at home and might not notice that it's dark out and you've been working for 12 hours because you're at home!

Remember to walk around.

Commuting and navigating an office involves walking. Working at home really doesn't. Your bed, kitchen, and bathroom are likely only a few steps away from your work area, so it's important to get intentional exercise. Going for a walk around your neighborhood seems to be one of a few safe things to do. I'm also digging into at-home workouts.

Remember the idle chat.

Spontaneous conversations at work are important. Conversations around the coffee machine and having lunch together are great ways to bond with coworkers in an office. You can recreate some of this online by creating non-work channels in chat (eg. #random, #listening-room, #coffee-n-tea, #work-from-home-tips), having a happy hour over video chat (hey I'm doing that with my non-work friends), and holding team building exercises on a Google Meet call. I've found there's almost nothing you can't recreate in video chat, you just have to be creative for a while.

Be transparent with your communication.

When communication is moved from an office to 100% online, folks might be afraid they're missing out on key conversations and decisions they might otherwise see in the office. Transparent communication solves this issue.

Use public chat rooms whenever possible. As Jon Ericson says:

Instead of asking 'Who needs to know this?', ask 'Is there any reason this should be private?' The answer is almost always No.

"Public by default, private if you have to."

I promised this'd be short, so I'll stop there. I'm happy to keep the discussion going in the comments 💬

Remember this isn't about transforming your culture to be remote-first or rethinking your companies core values and processes. We're just trying to get by in this strange, new world.

I won't hit you will a million WFH links published within the last week, but here are two worth reading:

Close your office - Andreas Klinger
OMG WFH - Benedikt Lehnert

Stay safe our there friends ✌️

How do you find and apply to speak at conferences?

Ted Goas — Tue, 04 Feb 2020 14:08:14 +0000

Howdy y’all, I’m wondering how y’all find out about conferences you’d like to attend. And more specifically, how would you find ones that are accepting speaker proposals.

I have a handful of topics I’ve given talks about, but am struggling to find conferences that are looking for speakers or soliciting CFPs (call for proposals).

For conference goers and speakers alike, how do you find them?

Getting Started with Maizzle, a Framework for Rapid Email Prototyping

Ted Goas — Mon, 03 Feb 2020 14:47:12 +0000

For the past several years, coding HTML emails has been part of every job I've had. However, despite all the modern front-end tooling that's been created in recent years, my email development process has remained relatively basic and manual. Write static HTML, inline CSS by hand, copy/paste, etc.

A few times I tried twisting a framework into outputting high-quality HTML emails, but was never successful.

Fast forward to last week, I saw a tweet about Maizzle, another framework for building HTML emails. I was initially skeptical, but that changed after a few minutes clicking around the documentation.

Maizzle is an email framework that helps you quickly build emails with utility-first CSS and advanced, email-specific post-processing.

This piqued my interest: utility classes are kinda like writing inline CSS, which is how I currently develop emails.

So last week I set aside a few hours to dive in. I also opened up a blank text document to record my reactions as I went through the process. This is that document. 😀

Getting started

Alright (cracks knuckles), let's start by setting up a new project.

I followed the instructions in Maizzle's installation docs. I’m not the most comfortable using the command line, but I was able to follow these instructions and get a new project up and running locally within in a few minutes.

Nice, that wasn’t too bad.

Editing

Let’s open up the transactional email and see if I can change the title of templates/transactional.njk…

Nice, so this is where the template files live, I can edit them and see my changes in a browser, and better than best browsersync automatically reloads the browser even time I save a change in my editor.

I love this idea of building emails using JavaScript partials. Not the newest idea, but there aren’t many off-the-shelf options to do this specifically for email (I’ve tried unsuccessfully to hack a few static site generators to build emails.

Configuring

Ok so the Javascript part of this is cool, but let's check the actual HTML that was rendered since that’s the final email that someone would actually experience.

Whoa…! This email is 433kb??? For this tiny little thing? Let’s open up the rendered HTML and see what’s going on.

Oh… the email includes ALL of TailwindCSS 🤦‍♂️

TailWindCSS is a utility-first CSS framework comprised of tons of tiny, single-purpose CSS classes. And it looks like our email has the entire framework included in the <head>. All 25,000+ lines of CSS would certainly account for that file size!

I remember seeing something about this in Maizzle's docs…

Here it is. We can configure build environments by editing their respective config.js files. Looks like config.js is for local development, so let’s pop that open.

Looks like inlineCSS and removeUnusedCSS are both set to false. Let’s change those to true so that our CSS is inlined (still a thing in email development, yea) and all unused CSS classes are removed.

Let’s save and re-run Maizzle.

Much better!

There are some nice options in the config file. I’ll review in-depth later, but we’re back on track for now.

Templates and Partials

Checking out the folder for partials and thinking of use cases…

A header + logo for each product line
A footer for each ESP (and their unsubscription info).
Spacers and other non-editable components
🤔 I wonder if you can specify a component and send in variables (Eg. Define the code / design of a button but send in a unique URL and text for each instance). Will research.

I also like the option to have multiple base templates… handy for those one-off fancy designs.

Tailored for Email Development

I love the choice of utility classes for email development. Writing a bunch of small, single-purpose CSS classes to style a component is really a more efficient way to writing inline CSS. (✋ I still write most of my email code by hand and inline the CSS.)

Maizzle also includes a lot of niceties specific to email developers, such as sensible and customizable CSS inlining, accessible <table> tags, setting base image url ONCE, automatically adding url parameters automatically prevent widows, and more.

Also while TailwindCSS defaults to modern units like rem and vh, Maizzle’s default output uses units like px and attributes like bgcolor (also still a thing in email development). Maizzle does this by customizing tailwind.config.js with email-friendly CSS. This is a huge piece that I was missing from previous attempts to use a modern web framework to build emails 🔥.

Worth noting is that we’re still writing HTML in Maizzle. Other options like MJML and Foundation abstract away some of the verbose HTML in custom tags like <column> and <row> and <button>. While some find that freeing, I find it limiting. Maizzle allows us to write the HTML we really want.

Maizzle abstracts away some annoyances of email development by solving them with modern web technologies, allowing:

web devs to code proper emails using tools & techniques they're already familiar with.
email devs to build emails quick without losing control of their code.

I’m excited to start porting over parts of our email design system into a Maizzle project to see how it holds up.

My first interactive email

Ted Goas — Thu, 02 Jan 2020 13:33:52 +0000

TL;DR: I coded my first interactive email using radio buttons to toggle on/off states without using JavaScript.

I was first introduced to interactive email in 2015 when I attended Mark Robbins’ presentation at Litmus Live in Boston.

JavaScript isn’t supported in any email client, so up to that point the only interactive things I’d done in email were relatively basic (like creating a :hover effect on a button using CSS).

But in his presentation, Mark introduced me to the concept of punched card coding: using checkbox and radio button tags in email to mimic on/off functionally that JavaScript typically enables on the web.

I was blown away by Mark’s talk. I told myself to look out for an opportunity to use what I learned at work, but promptly forgot about it for four years as “regular” work took the front seat 😬.

The Pilot

Fast forward to 2019, I now work on Stack Overflow’s private Q&A products. Teams can ask questions, post answers, and vote on the best ones in a private setting.

However some teams have mentioned they’d like to improve their culture of voting. Eg. The team posts useful answers, but folks don’t upvote or accept the best ones to signal a high quality answer to rest of the team.

Folks don't spend all day with Stack Overflow open in a browser tab, so how can we meet folks where they already are?

“What if you could vote on questions right from your email, without even visiting the site? I bet that’s something an interactive email would be able to do!”

Four years after learning about punched card coding, I finally found a good pilot project, tied it to a business need, and set aside a day to code my first interactive email.

What We Built

The “Happy Path UX" allows someone to view an answer to their question and optionally vote on or accept it as the best answer, all without leaving their inbox. This is what I built:

Try clicking the icons on the left!

The Code

The HTML uses the radio input along with the :checked attribute to show and hide content using CSS.

HTML

<input type="radio" name="vote" id="ArrowUpLg" style="display: none !important; max-height: 0; visibility: hidden;">
<label for="ArrowUpLg" class="ArrowUpLg" style="cursor: pointer;">
  <img src="ArrowUpLg.png" height="36" width="36">
</label>

<input type="radio" name="vote" id="ArrowUpLgactive" style="display: none!important; max-height: 0; visibility: hidden;">
<label for="ArrowUpLgactive" class="ArrowUpLgactive" style="cursor: pointer; display: none;">
  <img src="ArrowUpLgactive.png" height="36" width="36">
</label>

The actual radio button is visually hidden and linked to from their <label> tag using the for and id attributes. The image file is wrapped inside the <label> to make the click/tap area nice and big.

For each icon, I created two almost identical versions of the code: one for the “initial” state and another for the “active” state. The “active” state is hidden by default with inline CSS (Inline CSS is still the most universal way to style HTML in email).

So the base HTML and CSS inserts and positions each icon state in the email, and hides the “active” image for each icon. With this foundation, the CSS in the <head> adds the functionality.

CSS

#ArrowUpLg:checked + .ArrowUpLg {
  display: none !important;
}
#ArrowUpLg:checked ~ .ArrowUpLgactive {
  display: block !important;
}
#ArrowDownLg:checked + .ArrowDownLg {
  display: none !important;
}

When an icon is clicked, the <label> tag, it checks the hidden radio button.

In the CSS, the :checked selector is used to toggle the display property of the adjacent <img> between block and none. The first time an icon is clicked or tapped, I hide the initial state (display: none !important) and show the “active” state (display: block !important). The !important is necessary to override inline CSS styles.

The Happy Path UX

The end result is an email with working upvote and downvote arrows, and a checkmark to accept the answer.

We should only be able to upvote or downvote an answer, but not both. So we used radio buttons and included the upvote and downvote arrows in a single group using the name attribute. This means that if the upvote arrow is active, and then the downvote arrow is selected, the upvote arrow is unselected in the process.

The “accepted” checkmark is independent of the voting arrows, so I gave that its own name.

Email Client Fallbacks

I’ve been using the term “Happy Path UX” to describe the ideal state. Unfortunately not all email clients support this level of interactivity, so I have to think about fallbacks.

For instance, desktop Outlook on Windows does not support HTML form tags in email. Left alone, Outlook would display each icon… but nothing would happen when they’re clicked. Both confusing and frustrating for a user.

In this cases like this, we can target email clients that don’t support our desired UX and code in a fallback (Like say, static image files that click to the website).

In this example, I targeted Outlook using <!--[if mso]><![endif]—> tags to hide the interactive form content from Outlook but display it in other email clients.

How to Target Email contains a long list of ways to target different email clients. I'll use this to display the interactivity to clients that support it and hide it from the rest.

Punched Card Coding

This was my first foray into punched card coding. It’s a pretty steep learning curve, but I had a giant “A-Ha!” moment the first time I got a proof of concept working.

Punched card coding can involve radio buttons, checkboxes, or button tags to achieve a number of things. Javascript still isn’t supported in any email client, but we can still toggle state, build tabs, reveal a hidden menu, build a carousel, and more.

Known Issues and Questions

My example above poses several questions outside of the HTML and CSS.

Can we maintain state? Eg. What happens if I vote in an email, close the email, and re-open it? Is the arrow still active? If it’s not and I vote again, what happens?
What about security? Eg. If I forward my email, can someone else vote on my behalf?
What about testing? Eg. Emulators like Litmus only produce static screenshots. I’ll need a working version of every email client we want to test.

If you’re a Stack Overflow user, I’m not sure when we’ll figure this out, but I’m working on it! This is simply and exploration of what’s possible using interactive email.

If you’ve written markup using punched card coding or "the checkbox hack,” I’ve love input on how I could improve and optimize this.

If you’re a Stack Overflow user, would this be useful?

💌 ✌️