Template Map makes my Client Work Easier

Published 2 days ago on July 20, 2014 — 9 min read

TL;DR: Built another WordPress plugin: Template Map (GitHub)

Very often my inspiration for building plugins is to make my life easier. Selfish as that may be, I’m a big fan of the idea behind using your own publicly released code as much as possible. When you’re actually in the trenches using the code you’re that much more open to the flaws it’s got. Further, I think it helps you to write better code by looking for better ways to generalize it. One of the most frustrating things I catch myself doing to this day is repeating code in my projects, right down to repeatable styles.

Inspiration for Template map, however, came from the WordPress community. And it all started with a piddly little tweet:




Published 3 weeks ago on June 30, 2014 — 1 min read

I’m not sure if I’ve become too detached or something, but this is the first time I’ve heard of Susy which can’t be well described by calling it a Sass library because it’s just as much a philosophy. Susy seems to have been born out of the customization frustrations found with more traditional CSS frameworks and techniques. As per Susy’s docs:

In a world of agile development and super-tablet-multi-magic-laptop-phones, the best layouts can’t be contained in a single framework or technique. CSS Libraries are a bloated mess of opinions about how to do your job. Why let the table-saw tell you where to put the kitchen?

Okay, I’m intrigued. To date I haven’t latched on to any sort of framework and prefer to use a small mixin I wrote to help me generate columns using the power of Sass. I haven’t needed or wanted much more than that because every time I’ve tried a framework, the conventions put in place break down (for me) in a number of places. Too often do I resort to using the framework for the overall structure and then using my own on the internals. Susy seems to tackle that head on, check out this video:

Susy is one of those projects that immediately grabbed my attention and focus. I can’t say for sure whether it works for me but I can say that my interest is fully piqued.


Interfaces in need

Published 3 weeks ago on June 27, 2014 — 0 min read

Dentimax screenshot

I think one of my favorite aspects of client work is being exposed to solutions that otherwise wouldn’t be on my plate. Working with clients from many different industries presents us the opportunity to improve an area that (likely) desperately needs it.

There is so much talent being dedicated to the latest social-focused-ultra-modern UI in a pursuit of Silicon Valley valuation that could work absolute wonder on so many industries stuck in UI from decades past.


The Myth of the Design Studio Turned Product Company

Published 3 weeks ago on June 27, 2014 — 2 min read

37Signals successfully navigated the path of going from a design studio to being a software company. In the process of doing that they unknowingly started the mythology that every design or development studio should become a product company.

Kevin and I have on more than one occasion sat back and talked about what it would look like to pursue a product “on the side”. We dipped our toe in the water with a couple of (wicked) small offerings that exposed us to what that would look like on a more consistent basis. While that effort showed potential success, it didn’t take long to realize that it wouldn’t be sustainable.

I’m not sure how much that directly correlates to us being a two man shop with no intention of hiring/expanding, but that little experience was eye opening for us. It directly challenged what we had established as foundational for client work, it proved to distract from that very quickly. And we were barely in the game.

We realized that we started Iron to Iron as a client services company. We feel that we have a solid process down, happy clients, and we’re really proud of the work. We actually liked client work. Why are we rocking that boat? I think this article really nails down the subconscious that I think formed for both Kevin and I (and the rest of the industry) from stories like 37Signals’.

It seems like everyone is still striving to become some sort of overnight success by building a product that takes the world by storm and gets them out of client work. I’m not sure about all of the other shops pursuing products, but I think if you’re in that boat it makes more sense to think about whether you’re trying to build a product or simply get out of client work.

Edit/Update: I read this article as I was catching up on my to-read queue, it was published more than half a year ago. It turns out it caused a bit of a discussion, to which a lengthy reply was published. All that to say: there are definitely multiple angles to think about here, and as many others have mentioned I tend to agree with the overarching myth being how long things take as opposed to the very specific correlation with a single company in all of history.


I’ve Built a Live Search Plugin for WordPress

Published 2 months ago on May 5, 2014 — 4 min read

Search continues to be (in my opinion) a very much underutilized aspect of many websites. It’s not that websites are universally lacking on-site search, it’s that it usually stinks. I did what I could to improve that for WordPress sites by building SearchWP. It’s what I’ve always wanted but never found in a search solution for WordPress, and I hope it is for others as well. This isn’t an ad for SearchWP though (but if you’re interested to find out more definitely check out the site because it’s awesome </humblebrag?>).



Programming Sucks

Published 2 months ago on May 1, 2014 — 0 min read

Programming Sucks

This article has rightfully been making the rounds for the past few days, but I want to call out the reality of it. Yes it’s mostly hyperbolic but it’s awesome. Have you ever sat back for a minute to think about what you’re doing? Typing these words in specific ways that eventually translate into other things happening, but in between now and then countless other operations/tasks are taking place? It’s mind blowing.


Aerotwist – Better password form fields

Published 2 months ago on May 1, 2014 — 1 min read

Heartbleed (hopefully) had us all changing our passwords. A lot of passwords. It was a grim reminder of just how terrible so many password policies are, but that’s beside the point. This is great:

A better password requirements UI

It was so frustrating to have 1Password generate a password for me only to find out that the established password policy required it to be worse, and it only told me after the page reloaded. I then had to open up 1Password and forcefully edit the login I just had automatically generated to something that met the policy at hand. I wish something like this prevented that headache from the get-go.

Be sure to check out the demo after you read the article. Neat stuff.


A Strategy for Organizing WordPress Theme Functions

Published 2 months ago on May 1, 2014 — 0 min read

I’ve adopted a similar strategy to Tom. I use functions.php as a bootloader of sorts for all of my theme-specific dependencies. Breaking out things like Custom Post Type/Taxonomy registration from other logic like Walkers has proven to be extremely helpful both when initially building & revisiting projects down the line.


Cargo Cult CSS

Published 2 months ago on May 1, 2014 — 4 min read

I’ve been sitting on this article for a while but finally was able to give it a good, focused read. If I’m honest, there are many great points to consider. I say that because at first glance it feels very anti-”modern” CSS, but what good is something if it hasn’t been questioned repeatedly (even when the masses have stopped)?

I think a lot about CSS. Internally I continue to struggle with the balance of OOCSS/SMACSS/etc. insofar as not being quite settled (again: personally) with my choices on whether to use more classes (inherently adding to the complexity of the HTML and more) or use more CSS (which results in larger documents). I told myself I was overthinking it and stuck close with SMACSS to the best of my ability, although not fully.

I have kind of my own adaptation of SMACSS when I write CSS and it’s done the job (more than) well for the past couple years. My workflow felt good, breaking things up felt organized, I was able to progress through larger projects with relative ease, but something still (to this day) doesn’t sit right. I can’t emphasize enough how this is personal to my experience and is likely a result of not reading SMACSS for a third time to find a likely solution to my underlying pain points, but I digress.

The one part of this article in particular that really hit home for me was this particular code comparison:

<span style="display: block; font-family: Arial, sans-serif; font-size: 11px; color: blue; border-style: solid; border-color: blue; border-width: 2px; padding: 20px;">Here's a box.</span>
<span style="display: block; font-family: Arial, sans-serif; font-size: 11px; color: blue; border-style: solid; border-color: blue; border-width: 2px; padding: 20px;">Here's another box.</span>
<span style="display: block; font-family: Arial, sans-serif; font-size: 11px; color: blue; border-style: solid; border-color: blue; border-width: 2px; padding: 20px;">Here's yet another box.</span>

<span class="display-block blue-box font-arial color-blue solid-blue-border padding-20">Here's a box.</span>
<span class="display-block blue-box font-arial color-blue solid-blue-border padding-20">Here's another box.</span>
<span class="display-block blue-box font-arial color-blue solid-blue-border padding-20">Here's yet another box.</span>

The author admitted to it being an extreme example, and it is, but there is a fine grain of truth there that I think exposes some of my personal issues with using a ton of classes so as to be adaptive and increase maintainability. Naturally it all comes down to the actual class names you’re using, but I hope we can understand the point the author is trying to make.

To this day I don’t have a working answer that’s any better than the genius approaches to CSS I’ve had the privilege of reading about, but I think the fact that we’re still talking about ways to implement a foundational approach to writing and maintaining CSS is awesome. Preprocessors shook up that world like never before and I think it’s the best thing that’s ever happened to CSS. It’s opened up the doors for using things like partials, mixins, functions, and more to level up our approach to CSS, and until we’ve got more time under our belts actually using these approaches we can’t say we’ve found the solution.

I’ve started to focus more on the efficiency aspect of writing CSS. When I’m working on a project I haven’t touched in six months I want to be able to rattle off new HTML without having to sift through classes to make sure I’m using the right ones at the right time. I’ve found that to be a big bottleneck for me in recent months. I realize it likely comes down to my adaptation of strategy resulting in this bottleneck, but it’s something on my mind without a doubt.

I don’t know if I’ll ever find the balance of OOCSS I’m really looking for, but I think it’s getting better with each project I take on, so that’s a good thing. Articles like this keep me on my toes.


WordPress Code Reference

Published 2 months ago on April 28, 2014 — 1 min read

DocBlocks got a lot of love recently in WordPress which is awesome for developers. In fact it’s beyond awesome. It opens the doors for so many awesome implementations of that data set, things like the newly offered WordPress.org Code Reference.

Website screenshot

This information is insanely useful to anyone writing any bit of code for WordPress. We should be using these docs as guidelines. A lot.

What’s awesome about all of this focus on the docblocks themselves is that if you use an IDE that works with the data, you basically have the entire WordPress.org Code Reference built into your editor, with autocomplete! It’s fantastic!

Documentation is no small task to implement and maintain, but when you see it put to use like this it’s a great thing.


Powered by Fusion