This is Part III of a three part series about wd_s, our starter theme.
To summarize the previous two blog posts: we discussed the history of wd_s and then Damon went in-depth about how we kick off a new projects. In this post, I want to discuss what the future holds for our starter theme, wd_s.
At one point Bower was looking for contributors, and there was some doubt to whether or not it would continue as a project. Bower has since been rejuvenated and we feel like it will continue to be in wd_s for the foreseeable future, however we’ve decided to move the inclusion of Bourbon and Neat to Node instead of Bower.
At the request of Lisa, Grunt has been the build tool at WebDevStudios since late 2013. She saw the need for all developers to use the same Sass compilation tool. (Imagine four different developers all using four different ways to compile Sass! Good times.) Using Grunt to compile Sass was also the motivation behind our initial fork of Automattic’s _s. As wd_s continues to evolve, we can’t ignore the momentum behind Gulp.
As of this writing, Gulp has nearly doubled the amount of stars and forks on Github than Grunt. It’s safe to say that Gulp is no longer the “new kid on the block,” but the kid on the block everyone wants to play with. Choosing a build tool based on popularity may not be the wise choice. However, it is encouraging to know that there is a fury of activity both on Gulp and Grunt’s respective Github pages. The choice really should be based on, “Which build tool is right for me?”
With curiosity in mind, I started issue #140. The goal was: re-create our build process without changing our current Grunt workflow. I was blown away at how easy it was to work with the Gulp API. To me, the Gulp config file was just easier to understand and write. Out of the box, Source Maps just work (something we’ve struggled to get working 100% with Grunt) which is a huge win. I also loved how easy it was to get BrowserSync up and running, which replaced our old “LiveReload” system. Gulp support in wd_s is still in its infancy, and I’m sure there will be a kink or two to iron out as it matures, but so far the switch has been great.
Mobile Menu Magic
The “Hamburger Nav” has been the topic of debate in UX circles for years. While we strongly believe in keeping wd_s as un-opinionated as possible, we feel like abandoning the (awful) mobile menu in _s is the right choice. Corey is developing a different approach to the mobile menu system. Issue #137 is a discussion about different options. As a group, we’ve decided to take the Paradeiser “Tab Menu” concept one step further, and place it at the bottom (you know, where your thumb is?).
Pattern Library Integration
Creating a pattern library (like PatternLab) requires a bunch of time up front; but will save a ton of time over the duration of a project. It will help keep the team of developers on the “same page” about what a headline, button, and widget should look like. The team at WDS took a couple of weeks to write over fifty pens on CodePen.io for inclusion into our Pattern Library, and Damon is working hard at getting them into wd_s. You can track the progress on issue #136.
The wd_s Generator
Brianna has built a pretty sweet theme generator based on Grunt Init. She’s also working on Gulp port. The goal is to allow you to setup wd_s by answering a few questions in the command line. You can follow along with her progress at Issue #153
Better Gravity Forms Styles
This is something we work on often: styling Gravity Forms. Without question, Gravity Forms is the “go to” form plugin here at WDS. But overriding Gravity Form styles from scratch from each project-to-project was a bit redundant. After all, what’s an important programing mantra? “Don’t repeat yourself.” Eric took the initiative to create a vanilla set of styles for Gravity Forms out of the box in Issue #149.
What is linting?
Per Wikipedia, “Linting is the process of running a program that will analyse code for potential errors.”
Code standards are very important here at WDS. Without standards, working with a team of developers on a single theme would be a nightmare. To help maintain code standards, we implemented a Sass Linter via Gulp. From the command line, simply run gulp sass:lint and the linter will test against both WordPress and WDS coding standards. If anything fails to meet that standard, a warning will appear in the command line. Check out Issue #157 for more.
Continue To Iterate Accessibility
Early last year, I wrote a blog post about Accessibility Basics. WebDevStudios is committed to making sure we develop with accessibility in mind. Last November, we swept through and made wd_s 508c compliant. As we continue to add new tools and feature, we will ensure that they can be used by everyone!
Things have been moving pretty fast around here, but we’re committed to added documentation to Github soon. Issue #145 was created and the wiki was enabled! Your contributions are certainly welcome. Even further in the future, we may even create a “Github Pages” site to house in-depth usage documentation and tutorials.
On July 14, 2016, wd_s will be two years old. We’ve created a mature, reliable way for developers to spin-up a new project. As always, we invite you to fork our starter theme. Go ahead and kick the tires, poke it with a stick, and make a pull request of your own. Join the development democracy! We’d love to have you: https://github.com/WebDevStudios/wd_s