Over the last three months, I’ve written a series of four blog posts about creating and managing instances with Packer and Terraform. It’s been a tremendous learning experience, and I couldn’t have done it without the help of some HashiCorp experts (and ex-pats). Thanks to Sean Chittenden, Paul Stack, and Justin Reagor for your advice, critique, and editing.
Below I’ve included excerpts from all of the posts. The source code for all of the exercises is available on GitHub.
Every two years I redesign my website. It’s an opportunity to be up on modern web design trends, find gaps in content, and re-position the way I think about my skill set. It’s also a way to make sure I still know what my theme looks like inside and out, so that if I do encounter any problems, I know how to fix them.
For this redesign, I decided I wanted to accomplish the following:
Create a way to sort through projects by skill (web development, writing and strategy, product management, video, etc);
Create a case study style for projects to better highlight the purposes as well as additional deliverables;
Remove the resume as featured content, leaving that to LinkedIn;
Make it easier to contact me;
Simplify the design.
This site is one of the most important selling points for why you’d want to work with me. I want to make it easy to navigate, while being completely and utterly me.
I’ve learned a lot since I started working at IEG in August 2014, from building better WordPress themes via MVC to the ins-and-outs of git (how I got by before, I’ll never know). The greatest tool that I’ve embraced in my tenure is Sass. For those unfamiliar, Sass is a CSS preprocessor which takes giant complex stylesheets and neatly organizes them into tiers. There are so many features which will make your development process cleaner, faster, and happier.
Responsive web design is a buzz word that we are very familiar with at IEG. All of our modern sites fit that bill (we do have some that are quite old), and you can see it in action with the resize of your browser. The excess design falls away, the menu becomes a hamburger (which, has its own problems), sidebars slink below the content. But just because it fits a certain width parameter, doesn’t mean it works for mobile.
I just finished rebuilding the site for MetroFocus, a multi-platform news program focusing on the New York region. I got to a point where I was happy with the design, with the responsiveness, and we sent the site to our app developer to do some testing. He came back with incredibly insightful feedback when it came to thinking about actually using the site on a mobile device. The header and menu took up too much precious real estate and disappeared from view on scroll. The hamburger was small and surrounded by un-clickable (or, un-touchable) white space.
While the site looked good on a narrow browser, it wasn’t user-friendly for smartphones. I took his notes and spent a long time on my smartphone, clicking through and trying to think beyond “does this look good” and “is it broken” to thinking about the user’s experience on their phone. I can’t be spot on for every device and every situation, but we came to a place that is 100% better across the board.
Often when we create our WordPress themes, they come with a small theme options page built using the Settings API. This page could have inputs for everything from social media handles to uploading a new logo or picking a homepage layout. Having these options makes it easier for non-developers to make important changes to their websites, or give it minor refreshment.
Here’s a pretty straightforward example of how we use it on Chasing the Dream. Administrators can update the links for social media icons, enter the unique Google Custom Search Key, pick a homepage grid, and even update the footer text.
Having a theme options page is a good way to set global options, such as a font or accent color. Instead of having to find all of the places within the CSS every time a client wants to try a different shade of blue, instead they can have the power to update it themselves.
Back in October of 2014, I had a bit of a dry spell at WNET. There weren’t as many new projects coming in, and I was still green to the way our more complex web properties work. Instead of sitting around and reading the various internet news aggregates, I decided to attack a problem I knew about even before starting my job that August.
The Interactive Engagement Group (IEG) website was a flat, two-page piece of brochure ware. It was built to appease the powers-that-be, but was in no way indicative of the type of amazing work that the department was capable of doing. I wanted to take this project head on and lead the way to a beautiful, responsive, and informative website that would not only show off what we could do, but show off the expertise of our team. To do this, I needed buy-in from my boss, head of the technical team, and from the head of our department.
To Get Buy In, I Came Prepared
Though I talked about why I thought it was important with my boss and with the developer team, I knew I would need a lot more than a “good idea” to get department funding to build the site. I put my professional writing skills to work and wrote a content strategy.