This series of articles loosely documents design choices and implementation issues I met during the making of the tln website. I learnt a few lessons along my improvised 9-week schedule, and I thought I could share them with fellow first-timers. I guess some technical points might also be of interest to more experimented developers.
Adopting RWD
Nowadays most web browsing happens from smartphones, so it was not long before I decided I would put in the work to make my website render well, whatever the browsing device. Contrary to what the lead of this article may suggest, I spent most of week 7 to tackle responsive web design (aka RWD), yet I had begun quite earlier to make way for it, and it really paid off.
As the name tells, responsive web design should be addressed from the start. Don't consider RWD as an external feature to be dealt with once your desktop version is ready. If you do, you'll be in for a lot of code rewriting, which will doubtless break previous rendering.
Implementing RWD
I found that the main RWD issue pertains to having web content fit in browsers of different sizes. This can be tested easily by resizing the browser window from your workstation. Recent browsers further integrate a mobile devices emulation browsing mode among their built-in developer tools. It's safe to set the lower bound to 320px-wide screens. Beside library-specific settings, CSS media queries provide the best way to display content according to browser size.
Because I still had much to learn about CSS at that time, early Critique implementation did not comply with RWD, and reworking it several weeks later was really laborious. Conversely, I'd built the Blog and Photos sections with resizing in mind, so once I set out to complete RWD, I realized I had little work left to do.
I wasn't aware of it yet, but default mobile browsers trigger the expected features when touching hover-sensitive elements. This means there's usually no need to rewrite CSS :hover parts, as Chrome for Android and Safari for iOS will convert them automatically. Obviously, forget about Windows Phone. I can't tell about alternative web browsers though.
One problem could come from hoverable links: by default, mobile users wouldn't be able to access hover-triggered content, as touching the link would send them to another page. In order to resolve this, I chose to detect touchscreens with either clean browser detection or a JS attribute-checking hack, and deactivate the link with the preventDefault() utility.
/* Top Navigation - Deactivate hoverable photos link on mobile devices */
function isTouchDevice() {
return "ontouchstart" in window || navigator.maxTouchPoints;
}
var topNavPhotoButton = document.getElementById("photos-dropdown-link");
if (isTouchDevice()) {
topNavPhotoButton.addEventListener("click", function (e) {
e.preventDefault();
});
}