Deploying with Wordmove

In my new developer role, I was introduced to Wordmove: a tool that allows for multiple environment deployment via CLI. The ability to push and pull entire environments without worrying about modifying path variables is huge! This is just one of the many features that makes Wordpress deployment a breeze!

https://github.com/welaika/wordmove

The Burgh

After an intense hiring process, I landed a developer position at a large marketing/advertising agency in Pittsburgh. I went through quite the gauntlet to get here but I made it! The views in the office aren’t too shabby.

"Breadcrumbs" and the new Etsy Search Analytics Tool

New Etsy Feature!

If you’re an Etsy seller, you may have seen this new search analytics tool when you’re logged in. This tool provides valuable information about how users found your Etsy page.

View fullsize

The only problem: there is a lot of data!. If you’re trying to capture this data, this is a copy/paste nightmare!

View fullsize

Look at the pagination!

You can see that there are several pages that are out of view. Since I want to see all this data at once and work with it outside of this page, I needed a way to grab all this data without doing copy/paste for hours. Enter: “Breadcrumbs!”

The Companion Tool: Breadcrumbs!

Breadcrumbs is a tool that interacts with the Etsy Search Analytics section of your Etsy backend to extract all the data into a single CSV file.

It is built in Applescript and Javascript and is run while your Etsy Search Analytics section is open in your Safari Browser. For more information and to give it a try, visit my GitHub project!

Etsy SEO

About two years ago, I started an Etsy Shop for my video game art side gig. In that time, I've learned a lot about what I love and hate about being a handmade artist on Etsy.

One of the parts of this journey I have loved the most is Etsy SEO.

Yup! Spreadsheets, research, keywords, tags, titles, experiments, target ranking words and strategies are all pieces of the Etsy SEO puzzle. Before we get too far into the specifics, it's important to know the big picture: "What is it? Why should we care?"

What is it?

Etsy SEO has been covered by countless blogs and brilliant entrepreneurs (E.G. Jenni Waldrop at Fuzzy & Birch) but I will try my hand at a simplified version.

First of all, SEO = Search Engine Optimization.

"Search Engine? Optimization?"

A "search engine" is a system like Google. It lets you search for things. The "optimization" part describes the process of making your content friendly to search engines so that people can find you. I like to think of it as a game of "Where's Waldo?"

Think of SEO like a game of "Where's Waldo?"

Your product or thing is Waldo, and everything around him is the internet. Your customer is the one looking for Waldo. Poorly executed SEO is like keeping him in his normal striped red/white shirt and hat. Properly executed SEO is like giving him a fluorescent shirt that emits a light strong enough to create a beam that can be seen from almost anywhere on earth! Don't worry, it doesn't hurt him. 

Ok, so then what's a search engine?

Google, Yahoo, Etsy, and Bing make search engines. They are different! They have different ways to organize and display search results.

The goal of a search engine is to take what you enter into a search bar and scour the web for stuff that is relevant to your search. This is one of Etsy's primary objectives. They want you to be able to find exactly what you're looking for as quickly as possible!

In order to do this, search engines use algorithms (a complex set of rules, computations, and programs that determine which content gets shown.) Since each search engine is different, that means each algorithm is different. Learning Etsy's algorithm is really important in understanding how to use it to your advantage.

Why Should We Care?

1. People will actually find you!

Shop visibility is one of the biggest reasons to care about Etsy SEO.  As you know, when you use a search engine like Google, the results of your search get spread out across several pages. It's the same on Etsy. Your goal is to get your product within the first couple of pages of search, and as close to the top of the page as possible. It's no secret that shoppers will rarely navigate past the first pages of search results. This is why shop visibility is so important!

2. Good Etsy SEO works while you sleep!

Etsy SEO is an automated way for people to find your stuff. Once your Etsy SEO T's are crossed and I's are dotted, people will just find you. Anything we can do to free up time for product development, watching Netflix, and spending time with other humans (if that's your thing) is worth the effort!

3. You'll learn stuff about your product and market!

A huge part of Etsy SEO is knowing what words people use to find your product. When you figure out what words your audience uses to describe your products, you will feel more connected to your work and customers.

4. You'll Make More Money!

You can make a shop without investing time into Etsy SEO. You'll still get some sales, but you'll get way more if you work on your Etsy SEO! Think about it: if more people can find your product, you'll have more chances to sell them on your product. Basic maths! More visibility = More Money!

Need some help with tags and keywords? Let's chat!

While I love the science behind Etsy SEO, I know not everyone does. Many of us are trying to balance several parts of running an Etsy shop. Tags and keywords on Etsy can be a big time commitment and if you're in need of some help implementing them into your listings, shoot me a message and let's get the ball rolling!

Finding Good Twitter Tags

Finding Good Twitter Tags

RiteTag App Review

There a ton of ways to find Twitter tags that are relevant and popular. I’m not going into those but I will go into one tool that works well for me.

First, a few quick things about Twitter.

• No one strategy will always work
• It moves really fast
• You’ll probably need to create more updates/tweets than on any other social media platform. It’s… noisy!
• Hashtags are really important and can get you in front of a lot of people if you choose the right ones

Rite Tag

I use RiteTag to find hashtags that are relevant and popular. I use the URL “https://ritetag.com/best-hashtags-for/” then add a search term at the end. It’s a quick way to find a few good hashtags.

Do you use a tool to find relevant hashtags for your Twitter posts? I’d love to hear about what you use.

the "Learn to Code" Era

Academia and the private sector have been taking notice of the large demand for a workforce that knows how to write code; offering online courses, weekend workshops, and revamping their on-campus curriculums.

With applications and websites becoming larger, more complex, and mobile device friendly, knowing how to write code has never been more important. But is that enough, or even the right focus?

Don't get me wrong, I am all for people to learn this skill. In fact, I'm very passionate about furthering inclusivity and transparency around this industry. While many things are "open", there is still a mystery layer.

That layer is what I'm going to focus on here. That layer is comprised of soft and hard skills that are required to actually write code in the real world.

Problem Solving

In my years as a developer, I've touched many different languages. HAML, SASS, LESS, CSS, HTML, JS, Ruby, Java, XML, JSON, PHP, ASP, Python, C#, and the list goes on. Some of these languages, I've had to work with more than others, but the point is that I've had to work in all of these languages at some point. Why? I approach development as a problem-solver. Not as a syntax master.

When I'm solving a front end code problem, my stream of consciousness often sounds something like this:

How does this thingy get populated to the front end? And this text over here changes when this doo-hickey gets changed, why is that?

I'm not saying that learning the vocabulary is not important. It definitely is! However, it's not as important as being able to understand how things work and are able to apply problem-solving skills. The vocabulary and syntax familiarity will come with more practice. I promise!

The point is: I don't know the syntax of all those languages I mentioned. <sarcasm>Shocking, I know. </sarcasm> I do, however, love a challenge, and the internal reward of solving them. Also, you'll notice that I was asking questions. That's really important.

Asking Questions

It's not always easy to ask questions. To some degree, there is always a fear of coming across as a "noob", or worse: "an idiot."

I can't count the amount of times in the beginning of my developer career when I would ask a question, and the recipient would get annoyed with me. This made me apprehensive about asking any further questions, which led to a lot of wasted time and energy!

This fear would result in wasting a ton of time trying to figure out something that could have been answered quickly.

After spending years facing this fear, I finally developed enough practice to stop letting it get in my way. In fact, the more questions I asked, the more I learned (It's great how that works, isn't it?)

I'm not saying asking questions is easy. There is a set of skills that go into asking questions.

• Be aware of timing and be empathetic of their workflow so as not to disrupt them

• Know when to be self-sufficient and when to ask questions. "Timebox" solving the problem before asking someone else if you feel it is something you can figure out on your own.

• Pay attention to how you communicate with your team. Some people prefer direct, concise communication; while others prefer a more conversational approach.

• Know the right person to ask. Pay attention to the type of responsibilities held by each member of your team or office. This takes time, but if you have an org chart, learn it!

You might be thinking this is in the realm of "overthinking" especially for something as important as asking questions. There is no "right" way to ask questions. However, I do think that is value in being mindful of your team. If you allow empathy drive your approach, your team will appreciate it and your efforts will pay dividends.

"Learning to code" is only one small piece of the puzzle

I take issue with the notion that coding is the path to becoming a higher-value contributor to an agency, or as a solo-entrepreneur.

To be fair, "Learn-to-Code" curriculums have come a long way. However, I still don't think there is quite enough focus on the value of learning how everything works.

I think it's dishonest for private sector businesses to make it seem like coding is the main value proposition that will "lead you to an awesome job in no time!"

When "simple" isn't "simple"

Let's say you want to learn how to build websites. Most paths will start you with learning how to write HTML and CSS.

You learn all the building blocks that make up a "valid" HTML page. That's great and all, but once a student learns what goes into making it a "live" thing on the internet, eyes typically gloss over.

Why the blank stares? Outside of the coding part, these skills (mostly) are required to build the most basic website.

• DNS Management

• Deployment Methods

• Domains

• Version Control

• Local Server Configuration

• Task Runners

• Command Line

• Markup Preprocessors

I acknowledge that these type of skills are taught somewhere down the road in these curriculums (whether they are taught in the correct order is up for debate.)

Accept that you can't learn everything

The fact is, nobody can know them all front-to-back perfectly. Each technology has enough depth to be a life-long discipline. So I would argue that it's more important to be adaptable and generally know how things work than to be hyper-focused on memorizing the syntax. Naturally, there will be a set of disciplines that will interest you, which will lead to learning the syntax.

my gripes

While I have my concerns about the industry and how some businesses lure potential students, I think the movement to educate our workforce with the skills needed to contribute to our workforce is very important.

As of now, there's nothing to stop businesses from luring students (customers) with a rosey narrative about how code is the answer to your career woes and that it's "easy."

Traditional academia isn't designed to keep up with this space, so it's up to us to continue to educate, inform, and paint and accurate picture of what the industry is like and how to be successful within it.

I think people deserve to know what they are getting into before they invest a ton of money, time, and energy.

There's hope

I've found that there are many truly great places to learn about various coding languages. The UI and UX of these tools are awesome, and most of them are free! Most of these learning platforms use gamification to enhance the learning experience, which makes the whole experience more fun!

To name a few:

• Codecademy

• Codeavengers

• Treehouse

• Codeschool

TLDR;

When you're faced with clever marketing that promises that "code will land you an awesome job," it's OK to be excited about it. Know that learning to code is one of many skills required to succeed and that even the things that are "simple" have many layers.

Etsy Long Tail Keywords

You probably know by now that keywords and tags are basically the driving force behind getting your listings seen on Etsy. I’ve done a few experiments using Marmalead implementing Longtail Keywords, and I made some discoveries.

What, exactly, are we doing?

We're going to look at combining high-scoring tags within Marmalead to make niche and high-engagement long tail keywords. We're also going to review how Etsy processes your tags and titles.

Why tho?

If you're on Etsy, you want to sell stuff. Right? Understanding the different pieces of the puzzle will help you do just that! Etsy SEO is arguably the most important part of optimally positioning your shop to get sales.

What is a long tail keyword?

A long tail keyword is a series of words that describe a product. These words together create a phrase with high specificity. Many Etsy gurus talk about how shops that describe their product the most accurately within their tags and keywords get more sales. This makes sense!

Think about it, if you're searching for something very specific, and the product you're looking for comes up right away, that's a great user experience and will often lead to sale! Basically Etsy wants people to find what they are looking for and rewards shops that facilitate the experience.

a review of etsy tags and title

Before we get too far in, let’s review how the tags and titles work. If you want a more in-depth review, check Etsy’s Seller’s Guide.

Tags

• Can be combined when using them in your listing title to make long tail keywords
• Always match your tags to your title
• Spaces are OK
• Max of 20 Characters
• The order of tags within the tag section does not matter

Title

• Max of 140 characters
• Use up as much of those 140 characters as you can with your tags
• The tags in the front of the title are the most important
• The order of tags in your title does matter. We will cover this below.

A note about personalized titles

A thoughtful/personal title is great, but since the title of a listing is the driving force behind where you listing shows up in search, the value of a personalized title diminishes greatly. If you can work your keywords in your title in a way that is descriptive and thoughtful, that is the ideal.

In my research, most shoppers on Etsy will click on listings based on the photography and often don't factor in the title in their decision to purchase.

Find High Performing Tags First

You’re probably used to finding high performing 1-3 word combinations in Marmalead. Keep doing that! Now, you can take this a step a little further and experiment with combining those phrases with others to make long tail keywords.

Let’s say you have these three tags: “Chrono Trigger” “Shadow Box” “Art.” It doesn’t matter the order when you’re entering in the individual tags. However, what does matter, is the order of the words in the title.

This title could look something like this:

Chrono Trigger Shadow Box Art

Let’s check the strength of these tags by themselves first.

“Chrono Trigger” is looking pretty good. I generally don’t use keywords with lower than Moderate engagement. “Very low” competition is what I want.

UPDATE: Etsy has removed the category page (for now) making the Category Page risk not as important of a score to factor into your strategy.

“Shadow Box” I knew would be a broad word to use and sure enough, the competition is high. However engagement is high as well, so that indicates the health of the keyword as a whole. While that’s good to know, I want to see if I can combine “Shadow Box” with “Shadow Box Art” to see if I have a better chance of ranking.

What Does “Ranking” Mean?

The way I understand it, if you have a listing that is “ranking,” it’s on the first or second page of search results for that tag/keyword.

In other words, when someone types in “Shadow Box” into Etsy’s search bar, if your listing comes up on the first page, then you are “ranking” for that keyword. The reason this is important is that studies show that consumers on Etsy’s platform will seldom paginate to the next pages of results. They will more often refine their search.

“Shadow Box Art” cut the competition nearly in half, but the word has “very low” engagement. I definitely don’t want that so I’ll try to think of another keyword to put on the end.

I know from my research that the keyword, “SNES” does pretty well. The new keyword will be “Shadow Box Art SNES.” Let’s try it!

“Shadow Box SNES” seems to be an excellent long tail keyword! “Very low” competition and very high engagement. This is as close to a perfect long tail keyword phrase as it gets. Now, we’re going to see what all the words look like together as one gigantic long tail keyword.

“chrono trigger shadow box art SNES”

Now, we have an excellent long tail keyword that has individual tag strength as well! Now, to last part: how to implement it.

Apply the Long Tail Keyword

It’s quite simple. Copy and paste the long tail keyword, in our case, “Chrono Trigger Shadow Box Art” into your title. Let’s take dissect what’s going on with this title.

How Etsy Sees the Title

In the title, each word by itself has a computed value or “weight” in Etsy’s algorithm. It's important to keep this in mind when crafting your keywords and SEO strategy.

The breakdown of the title: “Chrono Trigger Shadow Box Art SNES” looks like this to Etsy’s search algorithm.

Single Words

Every single word has their own rank.

“Chrono”
“Trigger”
“Shadow”
“Box”
“Art”
“SNES”

Adjacent Word Pairs

Every word coupling has their own rank.

“Chrono Trigger”
“Trigger Shadow”
“Shadow Box”
“Box Art SNES”

Adjacent Word Groups

Every word grouping has their own rank.

“Chrono Trigger Shadow”
“Trigger Shadow Box”
“Art SNES”

Longtail Keyword Weight vs. Individual Keyword Weight

As a whole, this longtail keyword does pretty well! This isn’t the whole picture though. When you’re coming up with phrases, you’ll want to keep a few things in mind.

Recommendation: I saw a rank decrease when I used low performing individual tags to achieve one higher-performing long tail keyword. I would suggest not sacrificing the quality of your single tags for the one perfect long tail keyword phrase.

Some tags do poorly by themselves but do really well when you add a word

Pay attention to how each tag breaks down in the tags section. For example: If you broke up the tags like this, the individual tags would not rank well by themselves. For example:

The single tag “Box Art” has “very low” engagement.

However, when you add “SNES” to “Box Art," you have an excellent tag with high engagement and low competition!

In Conclusion

There’s always something new to learn about Etsy SEO. I’ve used these techniques to increase my views and rank! Here’s a quick recap:

• Make sure to always use the same words from your tags in your title!
• Combine tag keywords in your title to make high performing long tail keywords
• Pay attention to each keyword. Make sure they perform well by themselves before using them for title long tail keywords

Squarespace UX

The content authoring UX of @squarespace could be better. “Save” and “save and publish” both take the user away from the editing window, which is quite cumbersome. But not doing this is problematic if you’re working on a long post and lose internet connection in the middle of your edits (I lost two hours worth of changes). Possible solution: incremental draft auto-save? @slackhq’s implementation has really saved me from situations like this.

I admit, I should have had more presence of mind to stop what I was doing and save my work. I was on a roll and didn’t want to close the mind faucet! Yes, this may be an edge case. However, a user with less patience may abandon the entire platform over an experience like this. After all, time is our most valued commodity and I just lost my ass!

For the record, @squarespace , I’m still a huge fan. I just think this particular UX concern is worth some investigation. :)

Phablet Struggles

It feels wrong that I have to strategically arrange my apps in such a way that the ones I use the most are to the left of my home screen (I typically use my phone with one hand, my left). Any apps past the first two columns are basically dead to me since I can never reach them one-handed. (I’m on the go a lot) On that note, strategically arranging these apps in this way is strangely difficult given the way iOS shuffles them for you. It feels like I’m solving a Legend of Zelda puzzle. Which wouldn’t be too bad if I was rewarded for it in somehow. I’ll take the “you solved a puzzle” melody or a chest with a key in it or something! The puzzle: Move this other app that you never use over here so that it will create a complete row so that you can position the app you actually use right below it.

Vodori Final Day

Today is my last official day at Vodori. I'm feeling the rush of support from my co-workers as I embark on the next part of my journey. This makes it all the more bittersweet for me.

Being a Vodorian has been an honor, and a pleasure. To say that Vodori has some of the most talented people I've ever worked with is a gross understatement.

Thank you to my co-workers and friends! I will miss you all, but I'll be back to visit soon! Until next time.

Vodori Retrospective

My departure

I've had a great run here at Vodori. I've been here for a year and change. My role evolved from "markup producer" to nearly full-fledged "front-end developer". I even tried my hand at project management (thank you, Scott giving me a chance)!

However, the universe was giving me chances that I would regret passing up.

I've learned a lot

To say I've learned a lot while working here would be a gross understatement. Through my project work, consulting others, and being consulted, I've greatly grown my skills in:

• Javascript
• CSS and Preprocessors
• HTML
• Git
• Atlassian Product Suite
• Agile Methodology
• Cross Browser Optimization
• Graceful degradation
• Mobile Device Optimization

Bittersweet

While I'm excited about what's next, it will be bittersweet to move out of Chicago. I've really enjoyed living here, and I've made some wonderful friends. It was great to be around such intelligent, talented, and driven people at Vodori. It was an invaluable experience that shaped my career, and life for the better. To anyone from Vodori that might be reading this, Thank you!

Pre-processer Love

There's no shortage of posts about preprocessors, and more specifically about LESS. Now that I've been working with preprocessors for a few years now, I feel good about sharing the features that I used the most and find the most useful.

Variables and Mixins

Arguably the two biggest reasons to use a preprocessor are variables and mixins. The power of these features are at this point well documented, and people have become very creative with their usage.

It's pretty common to use variables in the context of colors, values that are used frequently, and even for class names. It's just as common to use mixins as a way to pass variables into them like functions. However, the large scale project I worked on regularly in my last agency job pushed me to think creatively about how to use variables and mixins, and how to make them usable (something I had not considered before).

I've talked about how to use variables for established media queries. While this was very useful, it was only the start of how I would experiment with variables and mixins. Rather than thinking about reusing individual variables, I started thinking about how to reuse entire design patterns leveraging variables and mixins.

The Project Backstory

This large-scale project I keep talking about throughout my posts was truly gigantic. It is internationalized for over 20 countries, has a back-end system that pulls data from all over the place, displays data to the front-end dynamically based on very complicated information architecture, user interactions, and requirements. What Vodori has created in terms of a product for this client is truly amazing!

Now that we have glimpse of context around the depth, and size of this application, we can understand the need for identifying design patterns, and being able to reuse them.

Design Patterns?

As with everything in this space, "Design Pattern" means many different things to different people. In my case, I see a "design pattern" as a set of attributes, be it design, or data, that are reused in many contexts. Since I'm a front-end developer, I'll use an example of a visual pattern.

header {
  padding: 1em 2em;
}
section {
  margin-top: 3em;
  margin-bottom: 3em;
  padding: 1em 2em;
}
footer {
  margin-top: 3em;
  padding: 1em 2em;
}

In this case, we want the padding of the header, section, and footer to be the same, so our content is displayed consistently. The padding: 1em 2em line is an example of a design pattern because we are using it in multiple places.

Since we can recognize this as a design pattern, we can turn it into a mixin.

.content-padding() {
  padding: 1em 2em;
}

Now, we can reuse this design pattern without having to declare and remember the padding values. It's much easier to remember "content-padding". As a bonus, this type of modularity adheres to DRY!

/* Note: Even though we're not passing anything into the mixin, 
I still like to add the parens so it's easy to identify it as a 
mixin, pattern, or object */
header, section, footer {
  .content-padding();
}

The beauty of this approach is that if we discover a new design pattern that pertains to the "content-padding mixin, all we have to do is add it to one place!

The problem: for semantics, we may need to rename the mixin if the design pattern strays from whitespace. Or perhaps there's a better way. This would be a good time to talk about "Design Objects".

The problem: Patterns with different functions

When I was going through this exercise of using design patterns, I found that quite often, I would make a set of design patterns that were not related in function. Rules around whitespace, typography, and positioning quite often would get mashed together into a mixin that would get used in many places, forcing us to override them in edge cases. (Cringe)

The way we handle this is to go back to basics with Object Oriented CSS principles.

Object Oriented CSS Principles

The idea with OOCSS is to decouple rules into modular objects, which for CSS usage, are injected into the HTML. Since we're using LESS, we can use this same principle without injecting HTML classes.

Again, there are many ways to do this, but I have a general method for abstracting patterns. I try to not cross-pollinate these patterns so they can stay abstracted by function.

Typography: color, text-decoration, font-family, font-size, line-height
Positioning: floats, TRBL (top, right, bottom, left) positions, absolute, relative, z-index
Whitespace: padding, margin

Naming Convention: Slightly Modified BEM

Using a naming convention is critical in ensuring your code is scannable, intuitive, and maintainable. This is especially important when creating patterns and objects. The developer looking at this code needs to be able to see relationships between patterns and objects at glance, without too much explanation. (Although, writing comments is extremely important too!)

I loosely adhere to the "Block, Element, Modifier" naming convention (BEM) for naming classes. This methodology was designed for large applications (althought it works very well for smaller projects too), and I can attest that this method works very well in that context. Here's an example of a slightly modified version of BEM:

/*"content-section" is the block with dash separating words, and "typography" is the modifier */
.content-section--typography();

/*"content-section" is the block with dash separating words, and "positioning" is the modifier */
.content-section--positioning();

/*"content-section" is the block with dash separating words, and "whitespace" is the modifier */
.content-section--whitespace();

Patterns and Objects in Practice

Let's take the original example. Now we can see how the design patterns are making up the design object.

/* The design object */
.content-padding() {
  /* The design patterns */
  padding: 1em 2em;
}

header, section, footer {
  .content-padding(); /* The design object */
}

Now, let's say we want to add more patterns to the design object. Let's add some typography patterns that we can reuse. Now that we're creating patterns with different functions, let's rename the patterns so they are more semantic.

/* Variables */
@brand-font--primary:       'Open Sans', Helvetica, Arial, sans-serif;
@brand-color--body-copy:    #4a4a4a;

/* Design Patterns */
/* Let's keep the .content-padding() but use it as a design pattern, not a design object. Also, let's rename it to something more semantic and appropriate.
*/
.content-section--whitespace() {
  padding: 1em 2em;
}

.content-section--typography() {
  font-family: @brand-font--primary;
  color: @brand-color--body-copy;
  font-size: 1em;
  line-height: 1.75em;
}

/* Design Object */
.content-section--patterns() {
  .content-section--padding();
  .content-section--typography();
}

header, section, footer {
  .content-section--patterns();
}

Patterns as objects

You might thinking: this is too granular! You might be right. On some cases, it might be too risky to add all the patterns into one object. In this case, we should use our patterns as objects.Essentially, all the patterns are objects and can be used as such.

Here's an example of using patterns as objects.

/* 
Instead of creating a design object, you could just apply the design patterns as individual objects.

You may need to do this in some cases, especially in the case of pattern variation.
*/
header, section, footer {
  .content-patterns();
}

/* The Sidebar has slightly different typography rules, but the same padding rules

We can apply the padding design pattern, but apply different rules for the typography
*/

/* Let's hash out those typography rules as a new pattern. */
@brand-color--sidebar-body-copy: #cccccc;

.sidebar-typography() {
  font-size: 0.85em;
  line-height: 1.25em;
  color: @brand-color--sidebar-body-copy;
}

aside {
  .content-padding();
  .sidebar-typography();
}

We could have wrote rules for sidebar typography, but it's smarter to convert the set of typography rules into a pattern so we can reuse it later if we need to.

Be careful! I strongly recommend not reusing patterns if your intent is to only use some of the rules. This breaks the idea of a pattern, and causes messy situations where you have to override.

.content-padding() {
  padding: 1em 2em;
}

.content-typography() {
  font-family: @brand-font--primary;
  color: @brand-color--body-copy;
  font-size: 1em;
  line-height: 1.75em;
}
/* ---------------------------
Don't do this!
--------------------------- */
aside {
  .content-padding();
  .content-typography();
  /* The content-typography has most of the rules I want, except for the color. */
  color: red;
}

While it may be trivial in this example to override one of the design pattern rules, this way of thinking can lead to messy overriding problems that can be difficult to keep track of, and or troubleshoot. This is especially true when working in a large application.

A Learning Experience

Aside from using mixins and variables to make patterns and objects, the exercise of pattern recognition has a lot of value. Working with designers in the beginning stages of projects to uncover these patterns greatly improved my development workflow, and understanding of OOCSS.

Developer Productivity

I've been writing code for nearly ten years. I'm still pretty slow, and I still have trouble writing code for more than three hours at a time (unless I get really motivated). The one thing I have learned in my years of writing code is how to get the best out of my productivity.

Timing

Many studies have shown that your mind is at its best in the morning. While I fought this tooth and nail at first (I'm naturally a night owl), I realized that this was true when it comes to writing code. I always tackle the toughest coding puzzles first thing, and save the easier ones for later in the day.

Taking Breaks

Again, there are many studies to back up the validity of taking breaks. I'm here to tell you that it is essential! I like to set milestones for myself when working through a coding problem. An example mental milestone.

Get through the styling for desktop viewport and ipad landscape, test it, then take a break!

Sometimes breaks came in the form of getting up to go to the bathroom, get a cup of coffee, or go for a walk. As long as it involved not being in front of a computer screen and sitting down, I considered it a welcomed break.

Making a todo list

I like to feel accomplished at the end of a day. If I don't have a set of to-dos completed, I may as well have played Battlefield all day (which would be awesome, but not exactly productive). I use teuxdeux to write a ton of mini tasks.

In addition to feeling accomplished at the end of a work day, this process of writing granular to-dos is practice for writing good project estimates.

Rewarding yourself

After I solve a really tough coding problem, I usually let out a big "F### YEAH!". Which as you could imagine, did not go over well in an open floor plan environment. Reeling in my enthusiam became a regular exercise for me at Vodori due to the environment. So I had to come up with ways to reward myself that didn't involve loud expletives.

When I conquered a tough problem, I would tell myself that I'm going to get something delicious for lunch. Or that I'm getting a beer after work. Or I would allow myself an hour or two of xbox one (again, Battlefield FTW!). The ritual of giving myself something to look forward to has really worked for me, and I think it will work for you too!

Understanding your client and their goals

At my time at Vodori, I went through phases of developer maturity. I started out relying on my coding chops to get me through my tasks. This was, as you could imagine, very short-sided. I drowned very quickly.

In the example of our largest international client, I was tasked with building a template. Which would include many individual modules like buttons, containers with columns, forms, etc. When I built out the buttons, I did not accommodate for long strings of text. So naturally when this template went to QA, the defect was discovered.

The mistake I made here was that I didn't know how far the internationalization reached within the app. If I would have taken the time to read the admittedly long-winded, but very informative wiki on the client goals, and how we're helping them reach them, I would have known that we need to accommodate for long strings of text everywhere! Whoops.

After making these mistakes early on, I began spending more time on our company wiki reading up on the client history, our dynamic with the client, what they want to achieve, who their customers are, and many more topics. Having this knowledge proved to be very helpful in coming up with solutions to code problems, and building features. It also helped in prioritizing features and bug fixes as I now had an understanding of the weight of different parts of features based on the client's goals.

While it may be annoying or time consuming, make sure to take the time to understand your client and their business. It will give you ground to stand on when proposing solutions, and it will make all processes smoother.

Writing Technical Requirements

Who should write requirements? Everyone!

Some of us developers feel a business analyst, project manager, or tech lead should write technical documentation. I'm here to tell you that it's not explicitly their job! We need to be part of writing them. In fact, the more stakeholders involved with writing requirements, the less chance of things slipping through the cracks in the development cycle.

I found that at Vodori, while the people I worked with were brilliant beyond measure, not all of them were comfortable writing markup requirements related to CSS styling. This resulted in vague requirements that would force a developer to stop their workflow to ask questions. This also led to missing implicit requirements. Again, this is not their fault. We should have all participated in the exercise!

What do good requirements look like?

Take link styling as an example. It's much more than just the color of the link. Here's an example of a complete set of styling requirements for links. These requirements outline context, colors, states, decoration, and nuance.

These requirements are for links inside of body copy. Links within other areas have a different set of requirements.

• The active state should have no text-decoration.
• The active state should be the color: #4196b4.
• The hover state should have an underline.
• The hover state should be the color: #365d9d.
• The visited state should have an underline.
• The visited state should be the color: #5e4d62.
• The text size of links in all states should always be the same size as the paragraph it is contained within.
• All links within paragraphs should open within a new tab unless otherwise noted.
• Links should have the same font-weight as the paragraph: normal.
• On Safari iOS7 and iOS8, the tap state should be removed.
• On Safari iOS7 and iOS8, the visited, and active state should be visible.

We have to write requirements sooner or later

We have to address the requirements for all of these components at some point. I argue that the development cycle goes faster and smoother when we provide requirements in as much detail as possible before development begins, than to piece-meal it on the fly later on. If we spend the time up front writing detailed requirements, it results in:

1. Less bugs
2. Less back and forth between developers and QA analysts
3. Faster development (developers work faster with things spelled out)
4. Less ambiguity around decisions (the requirements are requirements for a reason!)
5. Higher quality output (with the edge cases covered in the requirements, the quality of the code will be higher)

Of course, we can't always capture everything in the requirements. There will always be some degree of improvisation in resolving bugs. However, the more detailed we can be up front, the better off we will be as we progress in the development cycle.

My First Large Scale App Experience

Since my development career began, I had the itch to contribute to a large-scale app. You know? The kind that involved a big team, lots of meetings, deep coordination. Reading about it intrigued me, but it wasn't nearly enough to prepare me for what was in store.

I got my chance to work on my first large-scale, international, fully responsive web app while working at Vodori. Not only did I learn a lot about my own craft, experimenting with different media query objects, using custom breakpoints, and even ways to structure our file imports, I also learned a lot about how a large app is managed. Below are some of the key components.

• Budget
• Staffing
• Timeline
• Process
• Client Dynamic
• Business Goals
• Budget

Being a medium-sized company, and having a good long-standing relationship with the client, the leadership team was able to procure a contract that had a large enough of a budget to comfortably include a team of developers, designers, project managers, and business analysts.

Budget plays an important role in the consideration of how to approach responsive design in that it determines how to phase the development. With a small budget, you may have to optimize in phases. One approach could be to optimize for the two most important viewports (based on analytics and business goals) first, then in another round of funding, perform the remainder of the optimization.

Staffing

The exercise of knowing how many people you need, for how many hours of the work week, while maximizing capacity is no easy task. Vodori was (thankfully) able to hand-pick people for various roles. Although, throughout the project, we were seeing people being very cross-functional and stepping outside of their traditional roles in order to keep the project moving (a truly awesome thing to see).

A lesson learned about staffing in my experience at Vodori was to involve the right people at the right time. As an example: involving front-end developers at the beginning stages when the Experience Design (XD) team was crafting mood boards, mockups, interactive prototypes, information architecture, and making user experience decisions would have saved a lot of time, and budget.

This was a classic case of "staff chunking", where you have different discipline teams working in a silo, then hand off their work to another discipline team, without any further interaction. It makes complete sense to do this when planning such a large project, however after executing it, we learned that if we had allocated time a bit differently (disciplined teams spending their time across the project instead of in one large chunk), the project would have gone more smoothly.

Timeline

The work was slated to be completed within a matter of only a few months. This timeline was quite aggressive for a website of this scale and complexity.

Similar to budget, the timeline plays an important role in how to phase the development. The timeline also can drive the decision to use a framework, or to build one from scratch. It's also worth discussing with the client whether the timeline is arbitrary, or must be set in stone. Hard-fast deadlines that are close in calendar time may warrant using a responsive framework, and other pre-build components.

Process

Webflow

The XD Team, while being well-versed in the vocabulary and considerations of responsive design, did not have a lot of practical experience with it in the context of a large-scale application. (None of us really did!) We all had a lot to learn, and quickly! We thought that one way to get over that learning curve a little easier was to use Webflow to create responsive and interactive prototypes.

Our first thought, to save on budget and stay on target for our deadline was to bring in Webflow's frontend code into the production environment. Being the middle-man between the XD team and the developers, I made the mistake of bringing in Webflow's HTML and CSS into the project and going through the exercise of parsing what we needed and purging what we didn't.

While we were able to get templates off the ground quickly, we ran into trouble when we had to make tweaks to the HTML and CSS. The project specific CSS imported from Webflow was quite verbose and bloated, which made it difficult to find the classes/selectors we needed to modify, without affecting something else. Regression city!

The verbose and non-semantic markup was part Webflow's default CSS being bloated, and part a result of our XD team not having enough knowledge (or time!) with coding best practices. This was was not their fault. In retrospect, we should have used Webflow's CSS/HTML as a guide for development: cherry picking CSS rules we needed while writing our own HTML and class names.

Working in Silos

Working with an aggressive timeline, and with seemingly endless JIRA tickets, our developers were working in silos. In retrospect, the team would have benefitted from more interaction to solve some of these very complex front-end, and back-end puzzles. (While the back-end was very complex, it was planned in a way that made it easier to get off the ground. The front-end work ended up being the larger time-sink.)

There were many instances where I needed a sanity check to see if that code that I had been working on for nine-straight hours was viable. Unfortunately, this did not happen, and as a result, I had to go back and refactor many lines of code when I came back to it the next day with a fresher mind.

As an example: About four hours into the development of a feature, I wanted to discuss an approach with another developer before I submitted it for a pull request. Unfortunately, our team had no availability (even to block out fifteen minutes!), so I spent another four hours finishing the feature and submitting the pull request. I was hoping our tech lead could guide me through any revisions within the pull request dialogue, but she was also unavailable (this was not her fault as she's overseeing this gigantic app, while being in meeting for most of the day). She ended up coming over to my desk and informed me about another feature that was being implemented, which would make my code problematic. (I'm amazed that she had enough time to even do this! I consider myself lucky because most tech leads do not have the same level of awareness with such a large app. She's awesome! :))

Turns out, if I would have known this when I had originally asked a developer for a consult, I would have saved four hours of development time.

Now, I'm not blaming anyone for this inefficiency. In fact, the team I worked with was truly fantastic and awesome to work with. It's nobody's fault that the work was done so siloed, and from a project planning perspective, it was the best option we had. However, I do feel as though we, as a team, could have implemented a workflow that allowed for more internal consulting time. What I took away from this was that it's important to plan for developer to developer consulting time. In this case, it would have saved me four hours!

Client Dynamic

Our relationship with the client was generally very positive. We had been working with this client for a long time (about 8 years). However, this client was at times not very easy to work with, for many reasons (multiple stakeholders, lack of consolidated opinions/direction).

We ended up conceding on a number of design and development approaches, mostly because we weren't able to educate them on certain aspects of the project (time constraints as a result of staying on budget and timeline). The other reason we ended up in this boat was because we were working with a third party that was developing the ecommerce component of their product in parallel with the main app that we were building. This agency had strong opinions about certain technical implementations and were able to push their weight around to influence certain aspects of the project.

While we were working on two completely different apps, both parties had to ensure that our technology and design decisions were aligned since these two apps were under the same brand (rebrand). This proved to be very challenging when it came down to the approach for responsive implementation. It was difficult to coordinate on how we were changing elements on different viewports, but our Project Managers did a great job of communicating these strategies, and helping to come up with compromises on both ends.

Unfortunately, these types of politics will come with the territory, especially on larger projects. What I took away from this was that it is important to understand the client dynamic early on, and to plan for interactions that involve taking a firm stance, and to remind the client that the decisions made are for their benefit.

Business Goals

I've talked about the importance of knowing your client's business goals as a developer. This was especially important for this project and client. The approach to responsive design, and development was created based on the business goals: "we want an immersive experience that tells the story of our brand, while providing a simple path to purchasing our products." This is of course a summation, but it was a good high-level concept to keep in mind during development.

One example of how we approached development based on the client's goals:

Back story: The topic of conversation and contention was around a particular element on the site: A container that exists at the top of most pages that contains a hero image, a heading, and in same cases: a subheading with calls to action. The third party vendor was in favor of dropping text below images on smaller viewports to allow for more text. We felt differently. This was my stance, and defense of implementing an approach to keeping text on top of images, and to maintain this design pattern even as we experience the site on smaller viewports.

We believe that part of creating a system is having parameters around more than just data, but also having parameters around maintaining design integrity. Allowing a variable amount of text in the hero container compromises the integrity of the design. To better understand why we feel this way, let us explain the design process.

As we went through the process, we were finding that the vision we were striving for depended heavily on the combination of compelling imagery matched with rich copy. In order to create that immersive experience, we needed to ensure that the all the content was working together in way that would tell the brand story. In many cases, letting the image scale down across viewports, and dropping the text below the image did not lend itself well to that vision, so we decided to take the more difficult development path in order to deliver this vision. While this was a more difficult path from a development perspective, it actually opened up more doors for design.

The other topic of conversation was around a method of cropping we utilized for maintaining a central focal point for images that are implemented with the img tag. We were using css to center the focal points of key images in certain templates across our required viewports. Again, the third party vendor took issue with this approach, stating that it was too difficult to maintain and it would be easier to change the layout of the templates so that the image is displayed fullwidth, and shrinks down naturally with the browser/device. Again, this was an issue because some of the images had an aspect ratio that would render the image very short on smaller viewports. This was one of the reasons we decided to go with cropping instead of scaling. We explain:

Using our image cropping method allows for more flexibility in how we display our content. As an example, one of our design patterns is that we use min-heights on containers of content in order to provide enough whitespace for the copy to breathe, and to have control over the visual weight of the background imagery. The background images (among many other components) play a very key role on how the user digests the content. If we have control over how large the images are across our viewports, we can more effectively tell the story.

In the end, the client went with both maintaining the text over image design pattern, and our cropping approach. (hoozah!) While it took a little bit more development work, it ended up aligning with their business goals, which the client greatly appreciated. This example shows how if you map your decisions with your client's goals, you have much more ground to stand on.

Being a Team Player

When the deadline approaches, and the days get longer, it's important to be a team player. As an example: one of our project managers offered to take on some of my own project management work (for a different client) in order to free me up for development work (you rock, Dan!). This allowed me to be heads down on some of the development work that would have been difficult to finish quickly had I tried to balance both the PM and Development work.

The Large Takeaway

Working within a team for an application of this size is totally different than smaller projects. What I learned:

• There are more stakeholders
• More team members
• Organization and workflow planning is very important (it's borderline disastrous to ad hoc!)
• Communication between developers is critical
• Plan for for internal consultations between all disciplines
• Involve developers in the processes of establishing design, ux, ia, and wireframing early on in the project. If you, as a developer, feel you should be part of meeting, find a way to inject yourself!
• Be mentally ready to deal with politics. Things will not always go the way you want!
• Read up on all the documentation related to the client goals and relationship with your agency
• Don't be afraid to ask a lot of questions!
• Be Patient! Project managers, tech leads, and business analysts have a lot on their shoulders. Be cognizant of this.

Bullet Proof Development

What is "Bullet-Proof Development?

First of all, nothing is truly "bullet-proof." I know my code will never be perfect and I'm always trying to improve. However, I believe there are methodologies that can reduce the number of vulnerabilities in your code.

My definition of Bullet-Proof Development: a method of building components for the web in a way that can accommodate most contexts outside of project-specific requirements. A key part of this methodology is to think outside of the immediate requirements, anticipating how the user could interact with the component and build fail-safes for those edge-cases.

What prompted this idea?

At Vodori, I was leveraged primarily for my HTML/CSS/Responsive expertise. I floated across many project teams, in and out of sprints patching up styling bugs. So many of these bugs could have been prevented with Bullet-proof development methodology.

What makes it "Bullet-Proof"?

This is not a new concept. Everything I know and practice is a culmination of knowledge of industry leaders. "Bullet-proof development methodology" is not about over-engineering, or accounting for every edge-case. It's more about minimalism.

Minimalism?

I started my career as a graphic designer. Terms like "gestalt", "visual weight", "minimalism", are examples of some of the vocabulary of that world that are very applicable to web development.

The term "minimalism" was one that always stuck out to me. Most likely because it is so widely applicable in contexts beyond the work I do every day. The concept of stripping things down into their most core with the goal of telling the story more effectively really resonated with me.

Minimalism plays a big role in Bullet-Proof Development (we'll refer to it as "BPD".) When I'm looking at a component, let's say; a button, the first thing I do is go through my BPD checklist:

• Does this work in IE8?
• Is there anything here preventing this from working in all the major modern browsers?
• Are there any unnecessary rules? If so, delete them (with caution, of course)
• Can I do this same thing with fewer rules?

Needless to say, even a "small" styling issue goes through a number of mental filters. I cringe when I hear "it's a quick styling issue, it shouldn't take any time to fix."

There's no such thing as a "quick" styling issue

On the surface, cleaning up little bugs like overflowing text in a container seem innocent enough and not very time-intense. However, little bugs like this end up reaching more people outside of the developer. Let's look at my workflow at Vodori:

1. QA analyst is looking at a feature.
2. QA analyst realizes that the text of a button is overflowing a button due to too many characters.
3. QA analyst creates a bug ticket and writes acceptance criteria for the ticket. This includes how to create the defect, an example page where the defect occurs, and what the correct result should be.
4. QA analyst assigns a bug ticket to a developer.
5. Developer receives the ticket.
6. Developer branches off of the project-appropriate git branch.
7. Developer fixes and tests the bug.
8. Developer submits the branch to be reviewed by a tech lead in a pull-request.
9. Tech lead reviews the code in the pull request and initiates any communication with the developer if needed.
10. Tech lead merges the branch into the stable branch (develop, usually)
11. Tech lead executes a build to a QA environment
12. Tech lead assigns the ticket back to the QA analyst.
13. QA Analyst reviews the ticket and marks as resolved, or documents if the defect still exists.

That's three people involved, two of them at much higher billable rates than developers (usually). All this could have been prevented with some thought investment. "What happens if this button has a lot of text?" Those 12 steps (give or take a few based on your organization's workflow) and hours of cumulative time would have been saved.

TLDR;

When we are under pressure to work quickly, we as developers can get hyper-focused on the immediate requirements of the feature and lose sight of the bigger picture. If we can take a step back and think more broadly about the implications of our decisions, we could potentially save a significant amount of time, money, and sanity for our clients and ourselves!

Communication > Coding

Being a developer is more about communication than about writing code

When I worked at Vodori, I found that as I progressed as a developer, I was spending more time consulting, writing requirements, communicating with my team, writing documentation, and writing test acceptance criteria than writing actual code. The communication part of development consumed more of my time than writing the actual code. Why? Because communication is more important than the syntax because it is what aligns the work with the client's goals.

It took a few years of writing a ton of code to get comfortable with the front-end stack. I still really struggle to remember the seemingly endless nuance of Javascript! I think there's this period of learning that needs to happen before many of the soft skills come as much into focus. That being said, I strongly feel I would have benefitted from integrating these soft skills and higher level ways of thinking earlier in my career.

Learn to be flexible

When we talk about flexibility, we are usually referring to learning new languages and technologies. While this is very important, a good developer is also flexible in the sense of how they collaborate.

There will be instances where you're working with other developers with differences in opinion on how to implement a feature. That's natural! However, your ability to see their point of view, while defending yours, and moving toward the common goal of meeting the project or client's goals is very important.

Empathy is important

Having empathy is critically important to success as a developer. You're going to be frustrated with Project Managers imposing unrealistic deadlines without your consult. It's the nature of the business and is unavoidable. When this happens, try to educate them on why the task is unrealistic, and work on a solution together. Don't just blindly accept it and stew about it. This leads to burn-out and resentment (I lived this and learned from it!)

It's important to step back and put yourself in the shoes of your team, and your client from time to time. Understand that Project Managers, Business Analysts, and business owners have a lot on their plates too. There are aspects of their disciplines that you don't understand, just as they don't understand yours! Educate each other, and learn to be empathic.