This website is powered by WordPress, and until a few days ago, it utilized a free theme entitled “Portfolio Press.” Portfolio Press is a great theme worthy of its high ranking and great user reviews. However, as this website is intended to showcase my design skills, using someone else’s theme was counterproductive. And so I set upon building my own WordPress theme. This is not my first WordPress theme, I created the theme for the Leo Robbins Community Sailing Center website as well as several throw-away practice themes to cement the design process. It is however, the “best” and most complete I have worked on yet.
I wanted this new theme to utilize many of the modern website design trends without succumbing to the pitfalls and annoyances that are so common in modern designs. This means a responsive layout, good typography, a dash of minimalism, and cross-browser and cross-device compatibility. In addition to a modern design, I wanted to limit how much of the “blog look” seeped through and make this a bit more like a traditional website that happens to have a blog section.
First, if designed correctly, a huge portion of code of most every theme should be identical from site to site. Every site uses a header, a navigation menu, a footer, and so on. With that in mind, rather than rewriting the same nuts and bolts every time, it’s wise to start with some pre-written base code that does most of the repetitive work for you. There are several options, you can write your own foundation code, you can use one of the default WordPress themes as a starting point, or you can use one of the numerous starter frameworks/templates that others have written.
With the aforementioned Leo Robbins Community Sailing Center website, I opted for starting with one of WordPress’ default themes and customizing it from there. In the practice themes I mentioned, I chose to use a skeleton foundation that I created. However, this time I opted for someone else’s framework. I settled on using the Bones HTML5 Starter Theme. Doing so was the right choice. It was significantly simpler to modify than the default WordPress themes and is setup for responsive design right out of the box. There was still a lot of modification to do, but so very much was already done.
The Bones Starter Theme allows easily writing CSS using LESS or SASS. If you haven’t used LESS or SASS, and refuse to try it, you can modify the straight CSS. But I highly recommend learning one or the other and using it. I opted for LESS, and it simplified the CSS writing process. Mixins and variables are wonderful!
Other than those tools, I simply had my trusty Sublime Text 3 editor and Google Chrome.
The Learning Curve
I didn’t have much of a learning curve here. I was already familiar with using media queries for responsive design, HTML 5 and CSS 3, and the WordPress theme design process. Therefore during production, the biggest issue was finding my way around the Bones Starter Theme. I was able to figure it out with a some code analysis and trial and error. However, others may want to start with a tutorial.
The Planning Process
I don’t like planning, but it is a necessary evil. One of the truer sayings I have ever heard is “proper planning prevents piss poor performance.” In the past, I have had a tendency to dive in head first and deal with the consequences later. But unless a project is small, diving in head first leads to being stuck in a corner and needing to waste time and effort getting out of it. So I bit the bullet and planned.
First on the list was the basic color scheme. Since much of this website depends on reading, a light colored background is needed. For reading, you want dark text on a light background. But, I like darker color schemes. So, I planned on using one of my common design methods and have a dark background with a centered, smaller section with a light background. And a menu with a dark background. Pure black and pure white are hard on the eyes with websites, so it needed to be a shade or two lighter or darker.
Then, the color of most everything else flowed naturally from there. One of the design influences is minimalism, so limited and non-flashy colors. On the white background, standard text is very dark grey, almost black. In the main focus areas of the site, links are somewhat traditional, underlined and some shade of blue. In non-focus areas like the sidebar, links are less obvious so they don’t draw attention. I opted for the same color as normal text, but underlined. On the dark background, any text designed to draw focus is slightly darker than straight white, and any non-focus text is a light to medium grey.
Responsiveness is the name of the layout game. Content should be front and center on every device.
First, most every blog has a sidebar. The common “responsiveness” tweak is to move the sidebar beneath the main content once the browser width decreases beneath some threshold. I opted to just get rid of the sidebar on smaller screens. As I will talk about below, I made some changes to the standard blog sidebar, and the net result is that the sidebar can be hidden without negative repercussions to site content or navigation. So when the browser windows is below a certain size, the sidebar altogether disappears, and the main content is resized to fill the window.
The footer was also changed (more on this below) to act more like the traditional sidebar does. As such, it re-flows to suit the browser width.
Lastly, there is the header. Minimalism dictates that the header should be fairly small and subdued in appearance. Tradition indicates that it should at least have some form of navigation and a logo. Combining those, yielded a small logo and a navigation menu on a single line without much fanfare. For visual variation, I made the content in the header restricted to the width of the rest of the sites’ content, but the actual “bar” containing the header covers the full width of the page. This helps to distinguish the header from the content visually.
The rest of the layout is pretty standard and didn’t undergo much, if any layout changes.
Content and Flow
The big content changes for the site are limited to the sidebar and footer. The sidebar no longer contains the common recent posts, recent comments, and meta links widgets. Those are very common and uncreative. It now contains a search bar, contact information, and a listing of the most popular blog posts. The recent posts and recent comments were not completely dismissed however. Those widgets are useful for SEO. Instead, they were moved to the footer.
The footer is criminally underutilized on many websites. And typical WordPress site footers are particularly lackluster and boring. To spruce it up, I opted to make a section which oriented itself as 3 columns on large screens, and 3 rows on smaller screens. Each of those 3 sections can contain one or more WordPress widgets. This makes customizing the content very easy (no theme editing required, just use sidebar editing page in admin), and putting in those recent post and recent comment widgets that I moved out of the normal sidebar exceedingly simple.
Other than those two highlights, not much changed. The site already had content and an established flow. And, a good WordPress theme allows both content and flow to be changed through the CMS, without touching the theme, so no changes were made at this time. I do plan on making changes in the future, but those can and will be theme independent.
95% of the code for this layout was CSS thanks to the Bones theme. I did make a few alterations to the PHP and HTML to facilitate footer changes and a few other minor items. But most of the work is CSS. Again, I used LESS for writing the CSS, and Bones sets everything up very nicely in terms of responsive design and media queries. A common workflow, and the one Bones caters to, is to start with a base design for the smallest screens and least capable devices/browsers, then to slowly ramp up using media queries. This went as expected. It took time as any design does, but no significant challenges were encountered.
After the theme was written, next came the browser and layout testing. With few exceptions, modern web browsers work very much the same as each other (thank you standards). Provided the designer doesn’t treat the most recent version(s) of Internet Explorer differently, they’ll likely be fine, and testing will go quickly and smoothly. The responsiveness was tested simply by resizing the browser window.
Problems only usually begin to arise with the quirks and lack of support of new standards in older browsers and mobile browsers. As some very noteworthy websites have dropped support for Internet Explorer 6, I didn’t bother thoroughly testing for it. I did a few preliminary checks, and it seems to work well, but I am not catering to it. Internet Explorer 7 and 8 are much easier to support than 6 despite their quirks, and didn’t require much more than what the Bones theme had by default. In practice, Internet Explorer 7 is virtually dead as well, and would likely be safe to drop support for. Internet Explorer 9 and up are very standards compliant and worked without issue.
Chrome (and Chromium for Linux) is fairly militant about updating itself, so checking the current release and one or two previous covers most everyone. Chrome is also extremely standards compliant and thus behaves as expected across all versions.
Firefox (and IceWeasel for Linux) is similar to Chrome in terms of standards compliance; however, there are some ancient Firefox installations out there.
Some people who use an alternative to Internet Explorer, still treat that browser as badly as they did Internet Explorer. One of the biggest problems with Internet Explorer is that a lot of people never updated it (thus version 6 remained prevalent for roughly 9 years. As Internet Explorer started losing marketshare, some of those never updating people moved to Firefox… and still don’t update. My school had Firefox 2 installed on their lab computers until last year (6 years after release), because the lab technicians don’t allow automatic updates, and never updated their images.
In addition, highly stable Linux distributions are notorious for rarely updating their software repositories (which is why they are stable) and using Firefox or IceWeasel as their default browser. This means that someone running Debain stable will likely be running a Firefox version that is a few years old.
So it’s important to test older versions of Firefox. I usually test versions 3.5 (latest in Debian Squeeze), 10 (present in some older OS X installs), 17 (latest in Debian Wheezy), and then the latest stable version. If it behaves as expected in all of those, it will likely work on everything in between.
Opera and Safari users are usually up-to-date, so checking the latest version is good. And most other browsers with any marketshare, outside of the mobile world are derivatives of Firefox or Chrome and use their rendering engines and don’t require special treatment.
Then comes the mobile world. I have a few Android phones at my disposal as well as an Android tablet. In addition, I have the Android SDK on my computer and can fire up the emulator if I am concerned about certain situations. I also have a Microsoft Surface Pro. On my Android phone, I have all the popular browsers (Dolphin, Opera, Chrome, Firefox et cetera) and test them on there for functionality. I then test the layout on the various screen sizes of the other Android phones and the Android tablet. I do test on the Surface Pro, but it just uses a touch friendly skin over the newest Internet Explorer, so as long as the website is touch friendly and works in Internet Explorer, it works.
The hard part is the Apple i* devices (iPods, iPhones, and iPads). I do not own any Apple i* devices, and have to resort to more difficult testing methods. The best is getting friends or family with i* devices to check, but that is a highly impractical testing method except at the very, very end. In the interim, making sure it works on the Android phones usually irons out any bugs, and thoroughly checking on sites like http://ipadpeek.com/, and http://iphonetester.com/ while using the Safari web browser is enough until the friend/family check occurs.
I do not have a Windows Phone either, but have the SDK and emulator for quick checks, and the Windows Phone browser reacts extremely similarly to Internet Explorer in Windows 8. So while I can’t extensively test on a Windows Phone, I am very confident that it works.
Overall, testing went very smoothly as I have done my time in the trenches of browser discrepancies and know what to avoid or what to do to prevent problems. The worst part of testing is checking on phones and tablets that I do not own, but I have ways around that.
The Finished Product
Leave some feedback on the design in the comments!