Blog Category: web

My New Responsive Design Workflow - Custom Boilerplates and Grid Systems

Lately, I have been struggling with starting projects and keeping them organized and clean. I have tried using other people’s grid systems, boilerplates, and starter files - only to find myself modifying them to no end. For example - I’ll start off with Bootstrap using their grid system and a few buttons and alerts. But I soon realize that I don’t like their typography. So I edit that. Then I realize I don’t like the padding, margins, and fixed width and height on a few of their input elements. So I edit those. And the list goes on… By the time I end up with a finished product, I would have been better off just writing all the CSS from scratch.

Front End Web Developent Frameworks

What’s even more frustrating is that sometimes I’ll use something like Bootstrap only to end up having about 1000 lines of additional code that just sits in the stylesheet and adds unnecessary weight to the page. I’ll either be too lazy to remove it or it’s so intertwined with the other code that I don’t feel like rooting out what I don’t need. Sure I can create a custom build of bootstrap - but it’s just not the same.

I have also gotten stuck in the same situation when building custom WordPress themes. I’d usually start off with a starter theme like _s (which is probably the best one I have found), then end up modifying it to no end. I DO realize that this is the point of a starter theme - it’s just a place to start - it’s not meant to be your final theme. But again, I find myself wasting a lot of time building in the same functions over and over again that could easily be reused for future themes. This time wasted on repetitive actions could definitely be better spent on building out new functionality, problem solving, or getting creative with designs. The point is - time is money, and I hate wasting money.

So I finally come to the point where I created a boilerplate of my own - a set of files for quickly prototyping single page HTML websites. It includes a mobile-first responsive grid system (which by the way is a fun exercise to create yourself), a reset from Normalize.css, and some other common CSS patterns that I typically use. It also sets the typography to how I usually like it for responsive website. It’s easy for me to modify and best of all, it saves me a bunch of time! I can quickly get a prototype together in a flat HTML file and easily create a mock-up in the browser. This has proven to really get my projects started faster and even speeds up my WordPress theme development. It lets me build something that the client can see and feel right away. Instead of trying to explain a flat PSD to the client, they can actually see some movement.

I frequently make changes to this boilerplate when building new projects too. If there is something I am working on a in a project that I know I will use in another project - I just add it to the master files, then push it to Github. Easy as that - it takes a few minutes to stop what I am working on and add it to the master files - but in the long run it saves a lot of time.

I’ve also done the same thing with a WordPress stater theme. It’s more work than creating a simple set of HTML, CSS, and JS files, but it definitely saves time in the long run. And I keep adding to the master files as I go along. This makes each new project I work on that much faster.

Of course, there will always be a time when certain modifications won’t justify using my starter theme, but for the most part it serves it’s purpose - it starts my project on a faster path than just creating it from scratch.

So my advice? Start your own boilerplate and scratch using everyone else’s. Use your favorite elements from other systems out there and roll it into your own unique system. Here are just a few fun front-end projects that you can pull elements from when deciding how to build your own:

My First Truly Multi-lingual Website

The first time I saw how online translators like Babelfish and Google Translate work, I knew they would never be a good solution. There is simply no way to have a machine properly translate a sentence from one language into another with all the proper grammar, tone, etc. I thought for a second it might work, then quickly realized: nope.

So when my friend was in need of a website in both English and Spanish, I had to find a decent solution. The parameters of the website were as such: develop a multi-lingual website with a responsive design built on a content management system so the client could update content and images. Both languages needed to be easily updated.

So I thought to myself: ‘should I build two different websites?’ Maybe just make things easy and build the spanish version on a sub-domain? Effectively giving the client two different websites to login to and update? This wasn’t exactly the easiest option because future maintenance would require updates to two websites. Plus the client didn’t really want to provide upkeep on two different sites.

Another option was to branch the site at the main level and add sub-folders for each language. I guess this would require the homepage to act as a landing page where the user could choose which language. The only thing I wasn’t crazy about was the fact that this isn’t exactly optimized for SEO.

So what did I do? I found Perch CMS -which lets you build an HTML template first, then insert dynamic content areas later. The content that is served up to each area could then effectively be switched out based on what was in the query string. So all we had to do was create a “language” button to change what was in the URL string. I found a super simple tutorial on how to do this here.

So my silver bullet ended up being a super simple solution. Using Perch allowed me to manipulate the CMS into exactly what was needed for the client. He can login and edit content for each page in both English and Spanish - all in one spot. On the front-end when a user clicks on the different language flag, the content areas are swapped out correctly.

Here is the website:

My Experience with Navigation in Responsive Design

Updated on: 3-9-2013

I’ve looked at a lot of websites on my iPhone. I’ve tried to study how other designers and developers out there are tackling navigation when their website is viewed on a tiny screen. A typical website built for a desktop computer? No problem. You can build whatever the heck you want. Get crazy with Mega Menus and shit. Make your drop downs slide all sexy like - or ease in ever so gently. That’s not the tough part. The tough part is what to do with that huge mega menu once your viewport gets down below let’s say 800px or so. That’s when the fun begins.

So I started to check out what the web had to offer on responsive navigation. I found a few decent resources out there. I found a few interesting techniques (and even made a fancy one myself.) Then I decided I needed to learn more about each technique. So I went ahead and built a little website with a bunch of demos - because we all know that experience is the best teacher.

Here are a few fun things I have learned about how to handle navigation on your responsive projects:

  1. Make ALL of your content accesible from all platforms and devices.

    It may be tempting to simply hide something on your website when you get down to a small screen size - but don’t penalize your users just because they are viewing your website from their phone. I know there’s been a debate going on about what context your users are using your website for - but personally I think it’s crap. If someone wants to view your website they want to find out everything you have to offer - they don’t just visit your website on their phone to grab your address. If I’m at looking for info on a restaurant while on my 24” iMac, I want to be able to find their address, menu, and phone number just as I would if I were walking around downtown and considering eating there in half an hour. So don’t hide your content when you get down to small screens - be creative and find a way to display all of the same information. Decide if you really need that information anyway - responsive design is a great reason to re-visit your content strategy.

  2. Make it easy for the user to find your mobile menu!

    Sounds simple - but sometimes the use of the hamburger icon isn’t too obvious for your Mom to decipher as the button that activates your menu. Case in point - Microsoft’s menu icon. Some people call the button that twitter bootstrap and the facebook app popularized the “hamburger” icon. If that’s the case then Microsoft’s icon is a club sandwich.

    Responsive Web Design Menu Icons

  3. Make your buttons easy to tap.

    The average human finger pad is 10-14mm. Apple suggest making your buttons at least 44x44 points (they say points because they can’t technically say pixels due to their high res retina screens). But this is something really simple - just add more padding to your links if they’re hard to click when on a phone or a tablet.

  4. Take advantage of accordions, lists, other creative elements to hide/show content.

    There are many elements you can use in your menu to hide and show menus and sub-menus. jQuery UI has a simple accordion - heck you don’t even need jQuery UI - you can just use a simple function to add a class to the parent item and use CSS to hide or show something. Simple example code here. There’s also the off-canvas method, which is nice for smaller menus. But don’t forget about the option of keeping your menu really small and utilize landing pages that hold your sub-navigation. This method requires you to really think through your content strategy, but it’s definitely worth it in the end.

  5. There is no hover property on touch devices!

    We can pretty much trace the need for responsive web design back to the creation of smart-phones - and smart-phones are touch enabled devices. They don’t have a mouse - therefore there is no hover state. There is only touch.

    Try to stay away from the hover property when building responsive websites. For years we have built menus with unordered lists that when hovered over, a drop-down will appear. While this is great for a device with a mouse, what about a device without one? I would rather see a drop-down menu activated with a click or a touch event. This creates consistency across your responsive design. Add a caret or some kind of notification to the user so that she knows something will happen when that menu item is clicked.

    I found an interesting bug when I purchased a touch screen Windows 8 Lenovo desktop computer - Internet Explorer did not register touch events. It merely simulated click events. Therefore, hover properties were not handled as they are on iOS devices. I tried to activate a hover-enabled drop-down menu, but it was completely inaccesible. The drop-down wouldn’t stay down long enough for me to click on any of the sub-menus! (Side note: even the Lenovo website wasn’t accesible from their own device! #fail)

    So this leads me to tell you this - optimize your website for TOUCH first, hover second. Don’t hide valuable content behind items where “hovering” is needed.

Should I Hide Menu Items to Make My Navigation Responsive?

The quick answer: probably not. The long answer depends on your situation. How big and complex is your navigation? Do you have tertiary navigation? Is your site jam packed with content on the homepage? Do you already have calls to action on the homepage that can get the user to your “hidden” sub-nav?

The reason I don’t like hiding your sub-nav: why hide content from your users just because they are browsing your website from a mobile device? Odds are, they are searching for the same exact content they would be searching when on a desktop. Don’t penalize your users just because they have a smaller screen.

In Conclusion

So after all of this research, here is a link to the site that I built which contains some examples of navigation patterns. →

Goodbye Cowboy Coding. Hello Statamic.

So this site you are looking at is very new. I’ve owned this domain for a while, but only used it for testing scripts or setting up WordPress test sites for clients. I’ve never really built it out into anything meaningful. Then I heard about a new CMS called Statamic.

I started looking at Statamic as a referral from someone on Twitter who I had known primarily as a WordPress developer - and I too, primarily develop client sites on WordPress. He said that using this new CMS was a refreshing break from building on WP all the time. So of course my interest was piqued.

WordPress Vs. Statamic

So I bought myself a Statamic license and let the coding begin. I watched the few screencasts they have on their site, then began building my site locally on my machine via MAMP.

The one thing I often find myself doing with WordPress is cowboy coding (and by cowboy coding I mean never really using development or staging servers before taking my code to the production site). Now, for bigger projects I always use development servers - but the process becomes a bit of a chore. I have to launch MAMP, create a new database, download WP, install it, then launch it. Then after I get a few WP sites running on my machine, I get a clusterF of databases running.

Oh, and version controlling a site on WP (or any CMS with a database) is kind of a bitch. I say this because I usually collaborate on the content of the site with my business partner. While I’m working on functionality - he may be working on presentation and content. This is a little tough to do when working from a database that is located on my computer! So what I found myself doing was launching test sites on dummy domains. This at least allowed us to work together on the same website without too much conflict. Of course to me - it’s not ideal.

Enter Statamic

The ability to version control everything - even the content of a Content Management System - was pretty mind-blowing for me. Yes, I’m a noob when it comes to flat file CMSs, so if I sound over-excited - that is why.

Statamic requires no database whatsoever - but it does run on PHP 5.3 (which I had to call hostgator to get running on our server). It also uses YAML - I have no idea what it does, but it’s pretty frigin awesome. ALSO, Statamic lets you choose how you want to write your content. You can write it in HTML, Markdown, TXT, or Textile. I chose to use markdown. I’ve never really had to use markdown before, but now that I’m starting to write my content in markdown I’m starting to realize why it’s such a terrific way to write copy - especially when writing about code.

Back to: getting off cowboy coding.

Statamic allowed me to quickly set up a dev site on my local machine with MAMP (since you have to run PHP). I was up and running in a matter of minutes. Just edit the .htaccess file and you’re good to go. I was able to start building the site exactly how I wanted through good ole’ HTML, CSS and JS. It was also nice to have live refresh enabled through the use of CodeKit. After that I was adding my own content and started with version control on GitHub. This was the turning point for me - realizing that versioning, testing, setting up a staging site, and setting up the production site where all going to be a seamless transition. There’s no back and forth, copying and pasting, creating new databases, exporting and importing SQL files, and worrying about where the latest version exists. Everything just got a little more simple. Oh - and I don’t have to edit the site on the production server anymore (AKA cowboy coding). Not that I had to in the first place, but now it’s just waaaay easier to make all my edits on the dev site. Whewh.

Added Bonus: Site Security

With WordPress there are definitely some security risks. For starters - you’re running a database. Anytime you run a database there is risk of some type of injection. Of course there are many ways to protect your WP install - like moving the wp-config file above the site root, or changing the database prefix, the list goes on. But with Statamic there is no database (yes, I probably sound like a broken record now) so the risk of a database injection is completely eliminated! Woot! Also, moving the content and config files above the public site root is super crazy easy to do. This just gives a terrific layer of security.

Building From the Content Out

Statamic has definitely made me rethink how a content management system should work. I’ve had a complete mental change in how I go about architecting websites now. I guess it also helps that I just finished reading Content Strategy For Mobile by Karen McGrane - a book I highly recommend. The content truly comes first and I can easily manipulate the content management system for what ever it is that I am trying to accomplish with this website rather then building layers on top of existing layers that exist in a more defined content management system.

So could we start to see more flat-file Content Management Systems in the future? I sure hope so. Databases will always have a time and place - but when they’re just a little overkill, a static site generator will work wonders. And you’ll probably see me creating more client sites with this lovely little CMS.