Base Foundation for WordPress
For development: Do your JS work in js/ and all your styling within scss/. The templates/ directory is meant to be your static build folder for HTML, and there is a ‘base-joints’ theme customized within the wordpress/wp-content/themes directory where you can create your WordPress theme based off your static templates. Grunt will handle the rest to ensure your templates have the necessary files."
This is the ‘Bones’ or “_Underscores_” for a Foundation based grid theme. You need to be comfortable with the Terminal to install the various bits and pieces that put this all together. If you have VVV installed you are set.
If I were to ask you what the least used default page type in WordPress is, chances are you’d say the archive template. Or, more likely, you’d probably not even think of the archive template at all — that’s how unpopular it is. The reason is simple. As great as WordPress is, the standard way in which it approaches the archive is far from user-friendly.
Let’s fix that today! Let’s build an archive page for WordPress that’s actually useful. The best part is that you will be able to use it with any modern WordPress theme installed on your website at the moment.
But first, what do we mean by “archive page” exactly?
The Story Of WordPress Archives
In WordPress, you get to work with a range of different page templates and structures in the standard configuration. Looking at the directory listing of the default theme at the time of writing, Twenty Fifteen, we find the following:
• 404 error page, • archive page (our hero today), • image attachments page, • index page (the main page), • default page template (for pages), • search results page, • single post and attachment pages.
Despite their different purposes, all of these pages are really similar in structure, and they usually only differ in a couple of places and several lines of code. In fact, the only visible difference between the index page and the archive page is the additional header at the top, which changes according to the particular page being viewed.
“In the past I’ve mentioned a couple of nice projects providing a collection of common data structures and algorithms in Swift and a collection of popular design patterns in Swift.
Here’s a project from Kamil Burczyk providing an extensive collection of Swift code snippets that you can quickly import into Xcode.
The snippets are all under the “Swift” scheme so in order to bring up the snippets you just type swift within the code editor and select the snippet of your choice.
This animation from the readme shows Xcode Swift Code Snippets in action:
A nice way to add many useful Swift code snippets into Xcode.”
Published April 17, 2015 by Geoff Graham
The difference between
<body> is easy to overlook. It seems to be one of those things that falls into the category of trivial. Admittedly, I have a bad habit of applying all global styles to
There are differences, however, and it’s a good idea to be aware of them regardless of whether we’re CSS veterans or rookies. We’ll go over those in this post and consider some practical applications where styling one over the other might make sense.
How HTML and body are related
The spec defines
<html> as the root element of a document, and we can clearly see that in the above example: the
<html> element is the very top level of all other elements. The buck stops there because there are no more levels beyond that from which styles can be inherited.
<body> make up the only two elements that fall directly inside
<html> . In fact, the spec defines
<body> directly in contrast to
<head> since those are the only two elements that need to be distinguished.
So, the bottom line here is that
<html> is the root element of a document where
<body> is a descendent contained within it. In fact, there is a :root selector in CSS. These target the exact same thing.
Issue #158 – April 14th, 2015
Ivan Shubin shows how to implement a stable and maintainable automated solution for cross-browser and cross-device testing of responsive layouts.
Patrick Brosset looks at some of the details of how CSS linear gradients work.
By Christian Holst – April 20th, 2015
When done right, filters enable users to narrow down a website’s selection of thousands of products to only those few items that match their particular needs and interests. Yet, despite it being a central aspect of the user’s e-commerce product browsing, most websites offer a lacklustre filtering experience. In fact, our 2015 benchmark reveals that only 16% of major e-commerce websites offer a reasonably good filtering experience.
Given the importance of filtering, we — the entire team at the Baymard Institute — spent the last nine months researching how users browse, filter and evaluate products in e-commerce product lists. We examined both search- and category-based product lists. At the core of this research was a large-scale usability study testing 19 leading e-commerce websites with real end users, following the think-aloud protocol.
Despite testing multi-million dollar websites, the test subjects ran into more than 700 usability problems related to product lists, filtering and sorting. All of these issues have been analyzed and distilled into 93 concise guidelines on product list usability, 35 of which are specific to filtering availability, design and logic.
We subsequently benchmarked 50 major US e-commerce websites across these 93 guidelines to rank the websites and learn how major e-commerce websites design and implement their filtering and sorting features. This has led to a benchmark database with more than 4,500 benchmark data points on e-commerce product list design and performance, of which 1,750 are specific to the filtering experience. (You can view the websites’ rankings and implementations in the publicly available part of the product lists and filtering 3 benchmark database).
In this article we’ll take a closer look at some of the research findings related to the users’ filtering experience.
Published April 15, 2015 by Chris Coyier
The following a guest post by Andi Dysart and Matthias Christen of Ghostlab . I was pretty impressed when I heard that the newly-released Ghostlab 2 could do this. I think a lot of us developers use Chrome because the DevTools are so good, and it sure would be able to use them in other browsers, even on mobile devices. And why not? Chrome DevTools are a part of Blink, which is open source, right? We just needed a tool to make it happen.
Now while that’s true for desktop browsers, it’s a little more difficult when you try to identify a problem in a browser on a mobile device.
Options for Mobile Web Debugging
Let’s have a look at what your options are for mobile debugging tools. We’re first going to outline how you can inspect and debug websites on Android and iOS using Google’s and Apple’s respective toolset (we’ve chosen to limit ourselves to these platforms for the sake of briefness). Then, we’ll introduce Ghostlab’s approach to remote inspection and debugging with the help of a simple example.
Debugging Using Vendor Toolsets
Goggle’s developer tools allow you to inspect any web page running in Chrome on Android by connecting the Android device (only 4.0 and newer) to your computer via USB. On your computer, you’ll also need Chrome. To set this up, enable USB debugging on the device, and in your computer’s Chrome, browse to
chrome://inspect to discover the device. After you’ve allowed the desktop access on the device, you can inspect and debug any web page that is viewed in Chrome on the device.
This is possible for iOS as well , Safari to Safari. You also need to connect your device to the computer with USB. In the advanced Safari settings on the device, enable the option “Web Inspector”. Then open Safari on your computer, and in the “Developer” menu, you’ll see a list of iOS devices currently connected to your computer by cable. For each device, you’ll be able to inspect and debug any web page that is being displayed in Safari.
So let’s say that for two popular platforms, there are ways to inspect your website on the device – albeit with limitations. On Android, it won’t work below version 4.0. Also, you can only inspect pages that run in Chrome – if you experience problems in another mobile browser, that won’t be enough. This is similar on iOS, where you are only able to inspect mobile Safari. And of course, you’ll need a Mac to do so.
In addition to these limitations, you basically need a separate toolset for each target platform – one for Safari on iOS, and one for Chrome on Android. Even if you can find a toolset for each of your platforms, you’ll need to set all of them up, figure out how to work with them – and that’s still not taking into consideration that you’ll have to connect each device to your computer with a cable.
Website Style Guide Resource
Things people have written about style guides
A Maintainable Style Guide
An explanation of the principle’s behind Rizzo: Lonely Planet’s Style Guide
By Ian Feather
Atomic design is a methodology for crafting effective interface design systems.
By Brad Frost
Creating Style Guides
By Susan Robertson
Front-End Style Guides
An introduction to Front-End Style Guides.
By Anna Debenham
A living style guide for GOV.UK
By Edd Sowden, GDS
This is an excellent resource for anything to do with style guides.
Published April 20, 2015 by Chris Coyier
Brad Frost was showing me some slides from one of his talks recently. He had some graphics that demonstrated different approaches to where a style guide can fit into a team’s process. As you might imagine, it’s a matter of just having one or not that will determine its effectiveness.
I thought I would attempt to explain my own thoughts on these approaches based on my own experiences.
Or maybe we could call it the “after the fact” model. The idea is that you have a Style Guide, but it’s this separate thing that exists outside of the actual process. You have to maintain and update it separately. Changes to the site aren’t reflected in the Style Guide unless you take the time to do that. Changes to the Style Guide aren’t reflected in the site unless you do that.
Useful as a reference, mayyyybe. I’ve worked on a Style Guide like this. It was slow to gain any use at all and was quick to be abandoned.
In this approach, the Style Guide is the law. Nothing goes into production that isn’t a part of the Style Guide. If something is needed on the site, it is integrated into the Style Guide then is available for use on the site.
Adoption of the Style Guide, of course, is high because it has to be. Everything is documented. Those are potentially good things. This is also potentially frustrating – the process can be slower, which is sad since speed is a big reason to use a Style Guide in the first place.
There is also a danger that you’re “designing a Style Guide”, not “designing a website”.
The Hippie Colony
Everything is connected, man. The Style Guide builds the website, but the website builds the Style Guide as well. It’s just one set of assets, packaged up in different ways. One way looks like a Style Guide, one way looks like a website.
This can be nice, as you could work on either one and have the changes reflected in both. The only potential danger here is that it might be too good to be true. Discussions might become disjointed. The Style Guide might not stay as updated as you might assume it would.
In this model, you generally work on the site itself. The Style Guide is built from production assets. It essentially becomes part of testing. “Does the Style Guide still look correct and cohesive after these changes?” The potential danger of this method is that people stop caring about the guide because of its placement at the end of the process.
The CodePen Style Guide is a bit like this, but I’m hoping to make it more hippie-like.
Never is one, I’m afraid.
It is important not to get too hung up on tools. People dynamics, or lack thereof result in the dynamic mess captured above even with a good tool.
Inspirational Website of the Week: Beagle
Beagle by Podio is an explosion of perfectly timed smoothness and creativity. Our pick this week.
A small, fast, modern, and dependency-free library for lazy loading images. Made by Michael Cavalea.