Reflections on Site Development and Responsive Design

Initial Site Design

When I went back in time to my very first “completed” version of my website, finished on June 21 (technically at 4 am on June 22 after emerging victorous in a life-and-death battle with the intricacies and eccentricities of CSS, but who’s counting?), I was somewhat surprised to see just how similar my current version of site (as of August 16) to my initial commit. Sure, the navigation buttons were light gray and pill-shaped, most of the links resulted in 404s, and the content that was there was mostly laughable, but nevertheless the initial vision I had of my website, which I had wireframed earlier in that same week, has proven to be surprisingly robust.

Content Generation

I like writing. A lot. Especially when it’s on a specific topic. That’s why I didn’t have any trouble churning out two blog posts a week. It was all the other text that I felt were necessary for this website and its “hidden” (in plain view) purpose—the intro spiel, my short bio, the resume page, and the bits of text on the projects page—that felt like a chore to write. I did it slowly over a period of 4-5 weeks, setting a goal to get one part done per week.

Refining the Design

Almost immediately after pushing the first “completed” version of the site to GitHub, I started seeing places that needed improvement, sometimes with the help of friends. For example, someone told me that the links on my site looked like they had time-traveled back from 1999 (colored as they were in that early-Internet, Netscape Navigator blue and purple), at which point I sat down and analyzed how modern sites signify hyperlinks and what modern users expect. This change was swiftly made.

July 4 marked a big day for my site design, as I made a huge overhaul that covered everything from layout (margins and page balance), typography (kerning and leading, that is, letter-spacing and line-height in CSS terms), and color theory (the splash of olive green you see in the nav bar and headings came from this session).

Having to build my site from a blank CSS file did wonders for my CSS skills, and I felt very comfortable in executing my design idea for the social media icons present in the footer, which I did on July 10. This is still my favorite design element on the entire site—to me, there’s something very distinctive and pleasing about the olive green that pops out of that light gray background on :hover, but De gustibus non est disputandum of course.

As my blog posts became more varied, I started to require more and more elements like <table>, <blockquote>, and, well, <code>, a tag which has made the bits of code in this sentence monospaced on a faint blue background. As my technical posts became more technical, I acutely felt the need for a <code> tag as well as a <code class="block"><pre>, which I wrote into my CSS file on July 11 and July 16 (added a horizontal scroll bar). The CSS file itself was reorganized on July 26 under the influence of Jonathan Snook’s webbook on Scalable and Modular Architecture for CSS. It could still use another round of refactoring, but it’s a lot better than it was.

Rewriting the Content

The Russian proverb «первый блин комом» (“the first pancake is always a mess”) could just as well be applied to the writing of drafts, so I sat down on August 5 and hacked and slashed the core content into something that more closely represents my Platonic ideal of a pancake. Site design is important, but content is still king.

Responsive Design and Other Improvements That Add Polish

While the overwhelming majority of this site was written by taking the principles I learned from reading two different HTML/CSS textbooks in the spring of this year and relentlessly experimenting with them, there are some pieces of professional polish that must be learned from (and attributed to) the experts. For example, I chose to do a “nuclear” CSS Reset (a more refined one found on this aggregator might have been a better option) and borrowed the “clearfix” hack when I wanted to float images in my post on object-oriented design without resorting to using <br style="clear:both" /> in my HTML.

On August 11, I fixed the problem I had with my page footers mysteriously floating in the middle of the screen on large monitors for pages with a minimal amount of content by drawing on the ideas referenced in this Stack Overflow post. I combined a couple of the suggestions to institute this fix:

html {
  height: 100%;
}

body {
  min-height: 100%;
  position: relative;
  margin-bottom: -3.1em;
  padding-bottom: 3.1em;
  box-sizing: border-box; /* This is crucial, otherwise the footer    */
}                         /* will float just below the visible screen */

footer {
  height: 1.5em;
  position: absolute;
  bottom: 0;
  width: 98.5%;
  padding: 0.8em 0 0.8em 1.5%;
}

Also, on this day, I completed my first experiment with using “vanilla” JavaScript (i.e. not jQuery) for DOM manipulation by making what I call SAT hangman, a semi-educational game where the possible words consist of the 100 most common SAT words.

Finally, August 13 was destined to be the day I sat down and gave my site something it probably should have had from the beginning—a responsive design. (Earlier this same day, I added a custom script to render my email address more safely.) Despite being familiar with CSS media queries, I had always somehow thought that JavaScript had an essential role to play in resizing for mobile web. And while there certainly are many popular techniques in JavaScript that add in the functionality present in most mobile design these days, the core bit is actually done in CSS.

To other aspiring web designers and developers who might be reading this post, I would recommend starting with Ethan Marcotte’s seminal article on responsive design, before reading a short introduction on responsive design that details some of the shifts in responsive design practice that have occurred in the five years since the publication of Marcotte’s article. However, after reading these two articles and coming up with a responsive design scheme that kicks in at 700 or fewer pixels of width, my smartphone still defaulted to the desktop page, probably due to pixel density calculations. The technical solution to this—including <meta name="viewport" content="width=device-width"> within the <head>tag—and many more advanced tips and tricks can be found in Shay Howe’s excellent webbook on HTML and CSS.

Final Thoughts

One thing that distinguishes writing a website from, say, writing an article for publication is that there is never any “final” product. There is always more content to add or another improvement that can enhance a site’s functionality or make it feel more “modern.” I have a few ideas for my site in both these areas, but in the coming weeks I will be prioritizing my classes and projects at Dev Bootcamp Chicago. The rapid speed of change is what defines web publishing in the 21st century and, in fact, the tech industry as a whole, and this is what makes it so exciting for me to be a part of it.