The Redesign: Part Two

August 18, 2014 at 2:30 pm

Welcome to the sec­ond post about my recent redesign of SpareType. Part one cov­ered the visu­als, while this post will dive into how I changed my think­ing and process. I’ll share a few key code snip­pets pow­er­ing the new design in part three com­ing soon. For now, let’s talk about process.

Holy shit. I’ve been doing this all wrong.

Have you ever had that thought? It’s a tough real­iza­tion. I had that moment a few months ago. I was feel­ing like an old dog in my web design game. I knew of these things called Github, Grunt, and Sass but wasn’t tak­ing advan­tage of them. I hadn’t updat­ed my skills or my process. My mind­set also need­ed a reboot.

My first break­through moment was for­get­ting about a fin­ished prod­uct. Coming from the print side of graph­ic design, I was still hold­ing on to that idea of get­ting every­thing right before hit­ting the print but­ton. I kept par­a­lyz­ing myself with the list of things to do before I could release the redesign. But that’s not true for a web­site. If I don’t like the way com­ments show up today, I can update a file and they can look bet­ter tomor­row. A web­site can — and should be — in a con­stant state of improvement.

Make it more better.

The idea of con­stant improve­ment notched per­fect­ly with the idea of ver­sion con­trol. If I want to always be try­ing new things, I need a safe­ty net to CMD‑Z the things that don’t work out. I threw all my cod­ing pride out the win­dow and start­ed with the Git basics. “I’m smart enough to fig­ure it out,” had to take a seat while I dust­ed off the instruc­tion man­u­al and read the baby steps. I’m still not com­plete­ly using Git cor­rect­ly for branch­ing and merg­ing, but I have the con­fi­dence to break things in my code and undo them.

Github Screenshot of SpareType 2014 Project, version control, redesign

At the same time I was start­ing to crawl with Git, I was lucky to stum­ble across Codio. Before, I bounced around edit­ing code in Dreamweaver or the built-in theme edi­tor in Word­Press. Some­times I just used the file brows­er pro­vided by what­ever host­ing com­pany the project was on. I did­n’t have an inte­grat­ed devel­op­ment envi­ron­ment (IDE) and set­tling on one place to code and work has been a huge orga­niz­ing force in my process.

Codio is web based and fully inte­grat­ed with Git and Github. It’s lib­er­at­ing to no longer be shack­led to a local pro­gram or files. I’m just mov­ing stuff from one spot on the Internet to anoth­er. This also has the ben­e­fit of forc­ing me to learn the dark arts of com­mit, push, pull, and branch. Codio’s other inte­gra­tions with the soft­ware I was inter­est­ed in learn­ing — Sass and Grunt — made it eas­i­er to start learn­ing about them. Of course I screwed up at first — four­teen com­mits before Grunt was pro­duc­ing the right out­put. And it could still get better.

Codio Screenshot - Homepage, World's Most Powerful IDE, integrated development environment

The Biggest Game Changer

As cliché as it sounds, if you feel like you need to do some­thing, just do it. If you need to use [insert tool, pro­gram­ming lan­guage, new-fangled boon­dog­gle here], start using it. Screw it up, read more doc­u­men­ta­tion, copy some code, screw up again, get one tiny thing to work, screw up again, rinse, repeat. Along the way those tiny things that work start to stick and that’s called learning.

I’ve learned a lot the last few months both tech­ni­cal­ly in my code and in my approach to think­ing about what I do. It’s also made me appre­ci­ate oth­ers shar­ing their learn­ing on the Internet. Hopefully, I can con­tribute a small piece and inspire oth­ers to make things more bet­ter. I leave you with a few of the key arti­cles that helped teach me the last few months and bring about my process changes.