March 10, 2016
The thirteenth overhaul of my website design is finally finished!
Scroll down for more

(If you're interested in seeing all the source files being discussed today, visit this project's repo at Github.)

Big news to announce today -- the thirteenth major overhaul of my personal website, since it began in 1998, is finally finished and ready for public consumption. There are still a few of you, in fact, who can remember all the way back to version 1 of my site eighteen years ago, back when it was hosted by Geocities (stop laughing), and whose layout was done through cells of an invisible table because that was literally the only way to position different things on different parts of a page back then, a trick I picked up from Wired magazine that did the first version of their website the exact same way.

There's been a lot of changes to the site in the decades since, reflecting the technical changes that have come with that industry over the years (a move to HTML4.1 in 2000, the adoption of CSS2 in 2005); but the design schemes of both the sites I personally design, this one and my arts center, fundamentally haven't changed in the last ten years or so, because they were "good enough" and let me devote all my time to publishing books instead. But now that it's 2016 and I'm trying to find a job as a front-end software developer, in the eyes of my potential employers those sites are hopelessly outdated and old-fashioned, don't demonstrate proof that I know how to do any modern bells and whistles, and are embarrassing detriments to the struggle to be taken seriously as a designer. So when I redesigned my career goals as a developer last Christmas, I realized that this was the very first thing that needed to be taken on, redesigning those sites plus the new one I created during DevBootcamp just to explain my skills as a coder to employers (i.e. a "resume website"), which was designed as quickly as possible last year as a class assignment we literally only had 24 hours to make from scratch, and currently such an overwhelming embarrassment that I'm not even going to link to it today. Then after that*, start cranking out templates as quickly as I can, showing to employers that I can do this or that kind of look and feel (a website that looks like a bank's, a website that looks like a hipster clothing company's, etc), much like a beginning screenwriter in Hollywood cranking out spec scripts of The Big Bang Theory and NCIS to prove he can. Which, incidentally, I'll then sell as Wordpress and Tumblr themes for 99 cents apiece, and hopefully make a little pocket change on top of everything else.

(*Or, well, to be clear, there's something else I'll be doing at the same time, the other big main thing I need to demonstrate my mastery of to employers, which is learning all the major JavaScript-based webapp frameworks; that's too big a subject for today, but they're basically "middlemen" that let code, database data, and web browsers all easily interact with each other, and is the basis behind most of the non-refresh "single page applications" out there like Twitter and Gmail. The first thing I'm doing, in fact, is building simple Twitter clones in the four most popular frameworks on the market -- Ember, Angular, React, and the up-and-coming Aurelia -- before I do anything cooler or more unique with the skills, just to prove to employers that I can accomplish the basics of whatever framework they happen to be using. So over the next few months, I'll actually be alternating between one project and other -- first the overhaul of my "resume website," then the Aurelia version of my Twitter clone, etc.)

The rest of today's entry is going to be only a more detailed look into the technical and sociological issues that went into making v13 of my website look and feel the way it does; so if this isn't your cup of tea, you can safely stop reading now without missing anything else, and I'll be back next week with more about, whatever, Star Wars and therapy, you little animals. Now, that said, there were basically five subjects that I kept in mind when putting this together, so let's maybe tackle them one at a time...

First I wanted to make sure that the site is elegantly degradable; that is, that the content and navigation continues to be aesthetically pleasing and functional no matter how old or limited the device you're on, with more and more benefits and cute little touches the newer a browser you're on, but still able to interact with every bit of the content even if you're on your 15-year-old dusty iMac you only use when your laptop is in the shop, or even if you're elderly and have to blow the view up to 600 percent more than the standard, or even if you're blind and are using a special browser that doesn't display anything at all, but rather reads every bit of it loud using a computer voice program.

This is something I've been doing for a long time, and in fact it used to be one of the key pieces of advice back in the '90s when I was self-learning coding from such front-end pioneers as Jeffrey Veen and Jakob Nielsen, advice that's still hugely relevant today -- that when you sit down to design a website, your first question should always be, "What would this look like in the browser of the oldest, most technologically hobbled device still realistically in daily use in our society?" Once you have a version of your site designed for that, then you can start adding all the fun bells and whistles for the majority of people who have much newer systems, without having to worry that a core part of your site's content will be inaccessible without these capabilities.

And like mentioned above, there's a powerful side effect to designing this way, which is that you are then voluntarily compliant with the Americans With Disabilities Act. As a disabled American myself (I'm 75 percent deaf, and heavily rely on government-mandated closed captioning in order to follow TV shows), I find compliance with the ADA to be a particularly important issue, an important reason unto itself to design degradable websites, apart from the practical benefits derived from it.

Second, I wanted to make sure that my website is as responsive as humanly possible, because this is one of the biggest optional skills employers are looking for in front-end designers, one of the things that can help tip the odds your way when you're vying for a position among a bunch of people who all know the same basic skills equally well (like, for example, someone like me who just got out of a coding bootcamp). This is such an important issue, in fact, that I've moved all the details into a standalone entry at my technology blog, Adventures in Codeland (coming soon); but basically, it's all about asking whether your website is responding in different ways based on what kind of device is outputting it (for example, a phone versus a laptop), and loading up modified versions of the design optimized for just that device, but without having to write a bunch of completely different templates and all the complicated code that hops from one to another based on the device, done instead through a single well-designed HTML page and the brand-new "media query" function in CSS3. Like I said, much more on this subject at my blog for those who are curious; but in a nutshell, this website loads in noticeably different ways depending on whether you're looking at it on a phone in portrait mode, a phone in landscape mode, a tablet or small laptop, a desktop or big laptop, a media device specifically running in fullscreen mode on a television (like an AppleTV or Chromecast), or on paper after printing it out. Go ahead, try it out under all these conditions and see for yourself, then send me screenshots or photos of what you see, because I'm trying to gather up a whole gallery of images of what this site looks like among every device under the sun!

Third, unlike previous versions of my site, I wanted this one to reflect all the complicated little JavaScript bells and whistles I've learned how to do over the last year, specifically as proof of knowledge to potential employers, which breaks down in the following ways...

--On most newer devices, the main navigation menu starts out as scrollable, then becomes fixed into place when it reaches the top of the page, which I accomplished through the great little JS library scrollMonitor plus this tutorial by Creative Punch on how to implement it (plus with some fine-tuning help from my old friend John Paul Davis, once a fellow performance poet and now a fellow front-end developer). And note how degradable considerations were kept in mind even here -- if a person has disabled their JavaScript, as is often the case with web browsers at high-security work environments, the menu still appears in its normal scrolling form, just that you have to go back to the top of the page to use it once you reach the bottom.

--The bottom sidebar-type colored boxes concerning all the other things I do online come zooming in from the left and right edges whenever they enter the screen, again accomplished through scrollMonitor, plus a simple sliding animation in CSS I wrote myself. And note how responsive considerations were kept in mind even here -- the animations turned out to be too distracting in the phone version, so I turned them off there and have the boxes instead stretch all the way across the entire width of the phone's window.

--And perhaps most dramatically, the top of the site demonstrates "parallax scrolling," which is that cool thing where a section further down a web page will scroll faster than the section above it, and appears to "cover it up" as it slowly takes over its position. <sarcasm>You literally cannot get a job as a front-end developer in 2016 without knowing how to pull off parallax scrolling</sarcasm>, which is why I thought it so important to demonstrate it on mine too. There are a number of good parallax tutorials online in terms of "here's the code, now copy and paste it;" but for a thorough understanding of what in CSS and JavaScript makes parallax scrolling work in the first place, so that you can code it yourself with more fine-tuned control, I strongly recommend this tutorial by Sara Vieiera of Web Designer Depot.

And speaking of which, this was my fourth consideration -- instead of going with a much weirder or more indie or more unique look, like many might do with their personal sites, I wanted to prove to employers that I can visually design something that looks very slick and professional. As I get more and more things done for employers to look at, though, this will no doubt change, so keep an eye out for a much more arresting design when version 14 of this site is released some day in the future.

As then last, I wanted to make sure that the site's design reflects and enhances what the majority of its users are now coming here for; and this gets into what's called the "user experience and user interface" of a website, or "UXUI," which can sometimes be its own separate job category (especially among larger or more creative companies), but that is often enfolded into the usual daily responsibilities of that company's general front-end developer. And the fact is that what people are now coming here for has changed quite a bit since the last overhaul I did of the site's design a decade ago; back then, most people knew me as a creative writer and were looking for access to my old books of stories and poems, while many others were trained to come here daily because of me writing updates daily back then, and needed access to all the newest of the new stuff along what used to be an info-heavy sidebar (like all sidebars in the early-'aughts seemed to be).

Now with so many of these aspects of my life shut down, it's only the vaguely curious who will go back and look at that twenty-year-old creative material; and with me now updating at so many outside third-party sites (a reflection of the social media revolution that's also happened since the last overhaul of this site), I felt it was important to give visitors a much less busy, much more stripped-down experience here, a top menu that largely stays out of your way unless you specifically need it, a sidebar that doesn't appear until the very end when you're ready to go somewhere else, and otherwise a literal 100-percent concentration just on the super-long essays I write here once a week, already unusual back when everyone had personal blogs but now highly unusual in a world where most of those former bloggers now simply tweet or pin or snapchat instead. And again, this sort of ties back into my career goals as well; I'm trying to present myself these days as an expert at designing for content-heavy websites, a way of differentiating myself from all the faster and hipper 24-year-olds I'm competing against in the job market, so I have a lot to gain by making my text-heavy personal site as visually elegant and uncluttered as possible.

Anyway, so that's about all of it, which hopefully demonstrates both: 1) why front-end developers are so necessary; and 2) the legitimately big differences between mere web "designers" and full-fledged web "developers," why the former is so difficult to get a decently paying job doing anymore, while the latter is highly in demand these days and pays roughly the same amount as a back-end developer. I used to be just a designer, and eventually quit because I literally couldn't find paid work anymore, a situation that's become even more profoundly worse since the Great Recession of the 2010s virtually eliminated 90 percent of the creative-class jobs that used to exist; but now I've legitimately earned the right (through literal blood, sweat and tears) to call myself a coder, which makes all the difference in the job market and with results that I like to think are reflected in this new version 13 of my site. As always, I'm looking for as much feedback as you might possibly want to sit down and write; all of it, good and bad, can be sent to ilikejason [at] Next week, back to talk about TV shows and Minecraft, I promise!

Copyright 2016, Jason Pettus. Released under a Creative Commons license; some rights reserved. Contact: ilikejason [at] Powered by Movable Type 5.01. This site is graciously hosted for free by Jimi Sweet. Subscribe via RSS: summaries | full text