wd_s Theme Generator New Look

Take a look at the makeover our design team gave our wd_s theme generator.

“The previous look was very dated,” explains Cameron Campbell, Creative Lead, “And I wanted to add some content to point users to the Github repo if they have questions or want to contribute to wd_s.”

Got an upcoming WordPress project? Consider using wd_s.
 
 
 
 

CPT UI Security Release

We just released Custom Post Type UI (CPT UI) 1.7.4. This version addresses a reported security vulnerability around its tooling and migration functionality. We’d like to express gratitude to WDS Support Engineer, Michael Beckwith, who handled this update.

Is your WordPress website among the 800,000+ with an active installation of CPT UI? It’s time to update now! Interested in a WordPress plugin that provides an easy-to-use interface for registering and managing custom post types and taxonomies. Check out CPT UI.

PluginMadness

Speaking of CPT UI, did you know we made it to Round 3 of Torque Magazine’s yearly bracket-style competition known as PluginMadness? Help us make it to Round 4 by voting for CPT UI in Matchup 5.

March Support Program Madness

The madness continues with with a special offer on WordPress support hours that ends on April 3rd. Right now, you will receive one free hour of WordPress support for every five hours you purchase.

“We’ve run similar Support Program promotions in the past, and they have been very popular with our small-to-medium-sized business clients,” says Jim Byrom, Director of Client Services. “While the theme for our latest promotion is now null and void due to the cancellation of the basketball tournament, the mission remains the same. With a small investment in our service, we’re here to help ensure our clients’ success while also giving them a little bonus on top to help with their bottom line.”
 
 
 
Use discount code madness2020 to take advantage of free WordPress support hours. Get more details on Maintainn’s blog.

The post WebDevStudios Company News – March appeared first on WebDevStudios.

Maybe it’s just me, but @webdevstudios is one of the few companies that often shares their Five for the Future work https://t.co/AVvnDeLkYY

— Jeff (@jeffr0) June 5, 2017

While giving back to the WordPress community isn’t something that WebDevStudios (WDS) does for the glory and accolades (or the glamour, for that matter), actively and consistently participating in Five for the Future is something we do with a great amount of pride. Last year, WDS contributed 1,500 hours to the WordPress community, and we are on track to complete the same this year.

Our team’s contributions are varied and diverse. They include volunteering or speaking at WordCamp events, building plugins and adding them to the WordPress repo, transcribing talks for video caption, replying to tickets submitted at the WordPress support forum, and much, much more. Below are some examples of those contributions. And after the first of the new year, we’ll tally up all the hours contributed and report back to you. Keep up with our team’s Five for the Future contributions by following the hashtag #5ftf on Twitter.

Eric Fuller, Senior Frontend Developer

“Over the past couple of Five for the Futures, I’ve been working on creating a Todo plugin for WordPress. You might be thinking, another todo plugin? And yes, I would agree in most cases but this one is actually going to have a pretty nice feature set!” says Eric.

“My approach to this plugin is to create a fully functional frontend prototype before actually wiring it up to the WordPress backend. This is an effort to practice separation of concerns when it comes to FED/BED,” he explains. Check out the prototype branch here.

Jay Wood, Lead Backend Developer

In addition to actively working on an open ticket in GitHub, Jay has also been developing a robust random post generator for WP CLI, which supports multisite, post types, post counts, taxonomies, terms, term counts, and featured images. Plus, it comes complete with a cleanup command to undo it all! Neat, huh? Get all the details here.

And, because it’s October, after all, Jay is also participating in Hacktoberfest! And if all of that is not enough to qualify as a considerable amount of Five for the Future contribution (it is!), Jay is using his free time to learn Jenkins more deeply, which is a Continuous Integration and Deployment system that’s pretty configurable.

Ben Lobaugh, Backend Developer
Ben has been building out a standard WDS Docker development instance and combining that with automated testing capabilities that can be plugged into Jay’s Jenkins server.

 

 

 

Greg Rickaby, Lead Frontend Developer

“TeamJBW spent our Five for the Future testing wd_s as we revert from Neat 2.0 to Neat 1.9,” reports Greg. “The three of us tried to build a website using the /revert-neat branch of wd_s. We identified only one issue and fixed it. We also updated some documentation. We believe this branch is ready to be merged into master.” Learn more about the history of the WDS internal starter theme wd_s here.

 

 

Jeremy Ward, Backend Developer

“I’ve been working on my Dudley Patterns Framework plugin, which allows developers to quickly pull in reusable components powered by the meta fields plugin of their choosing (it defaults to Advanced Custom Fields),” Jeremy says. He has also been working on setting up a unit testing suite for the plugin and getting started on some initial tests so he can ensure that the code is rock solid.

Learn more about the Dudley Patterns Framework plugin here. Installable packages can be found on Packagist. Search for “Dudley.”

Aubrey Portwood, Senior Backend Developer

Aubrey has been working on getting out an internal Single Sign On plugin for WebDevStudios. He’s also contributing to WDS’s own coding standards. You can view that here.

 

 

Justin Foell, Senior Backend Developer

Justin is killing it at Five for the Future. He presented a metadata talk called “Too Meta” at WordCamp Portland, assisted Aubrey by updating the WDS Coding Standards, and has also been contributing to the internal Single Sign On plugin project for WDS.

Additionally, Justin has worked with other developers on the WP Strava plugin, which is designed to use the Strava V3 API to embed maps and activity for athletes and clubs on a WordPress site. Check out the plugin here.

John Hawkins, Business Development Manager

John recently donated his time and expertise by giving the talk “The Part You Play in Your Company’s Website Security” at WordCamp Salt Lake City.

 

 

 

Corey Collins, Lead Frontend Developer

Corey is our expert transcriber, having provided the captions for two WordPress.tv videos: Don’t Fear the Command Line and Diversity and the Design Team. He also did some work in wd_s, updating the header to an out-of-the-box, three-column header with Customizer support for an additional button/search form trigger.

 

Kellen Mace, Frontend Developer

Just recently, Kellen shared his knowledge at WordCamp Ann Arbor by speaking on “Build a Simple Frontend App Using the WP REST API + React.” He demonstrated an interactive React app he built for WDS to manage internal training, and he showed how he turned that project into a general starter plugin that anyone can use to get started building WP REST API-powered React apps. His WordPress React App Starter plugin is available here.

 

Cameron Campbell, Creative Lead

Cameron has been working on the design screens for an upcoming plugin called WDS Checklist Plugin, which is designed to provide developers with a thorough checklist for website launches. As full columns are completed, the user will even receive words of encouragement, such as, “Keep up the good work, champ!”

 

Will Schmierer, Lead Frontend Developer & Jo Murgel, Frontend Developer & Designer  

Seeing as how teamwork makes the dream work, Will and Jo have worked together to develop and design a WordPress theme for student athletes looking to be recruited for college sports. Custom post types include events (so the athletes can feature their upcoming games) and videos. This project remains in development. We’ll keep you updated.

The post Five for the Future: the Gift That Keeps on Giving appeared first on WebDevStudios.

]]> https://webdevstudios.com/2017/10/31/five-for-the-future-gift/feed/ 0 17626 https://webdevstudios.com/2017/07/05/how-thinking-about-accessibility-can-lead-to-success/ https://webdevstudios.com/2017/07/05/how-thinking-about-accessibility-can-lead-to-success/#respond Wed, 05 Jul 2017 16:00:26 +0000 https://webdevstudios.com/?p=17164 Just over two years ago, I wrote a blog post about accessibility basics, where I introduced readers to accessibility APIs from a 30,000 foot view. Near the end, I proclaimed that WebDevStudios is “committed to building accessible websites.” Internally, an effort to make our starter theme, wd_s, pass both Section 508 and WCAG 2.0AA standards began. Since then, Read More How Thinking About Accessibility Can Lead to Success

The post How Thinking About Accessibility Can Lead to Success appeared first on WebDevStudios.

]]> Just over two years ago, I wrote a blog post about accessibility basics, where I introduced readers to accessibility APIs from a 30,000 foot view. Near the end, I proclaimed that WebDevStudios is “committed to building accessible websites.” Internally, an effort to make our starter theme, wd_s, pass both Section 508 and WCAG 2.0AA standards began.

Since then, WebDevStudios has kept that promise. When we ship a website to a client, it passes all sorts of accessibility tests, as well as HTML and CSS validation. When a potential client asks us to provide examples of accessible websites that we have built, it’s easy to oblige. More often than not, that leads to a sale.

While impressing clients and acquiring a new project are good reasons to build an accessible website, the reality is that over 285 million people worldwide have visual impairments… which is almost the population of the United States! Thinking about accessibility is just the right thing to do.

Four Basic Principles

Make no mistake, accessibility is hard. So where should you start? To keep from getting overwhelmed, take a cue from Foundation by Zurb and follow four basic principles:

1) Structure your document properly

Modern web browsers can do a lot of the heavy lifting… if you write semantic HTML.

1. Use <button> instead of making <a>, <div> and <spans> look like buttons.
2. Use headings <h1> – <h6> to help provide both structure and context to screen readers.
3. Steer clear of “enhanced” form field plugins. Ask yourself, “Is it really worth having a pretty dropdown, when it is completely unusable by 285 million people?”
4. Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
5. Read more about “How Writing Semantic HTML Can Help Accessibility” by Jeffrey de Wit.

2) <label> everything

For 285 million people, a screen reader is the only way to “view” a website. When it’s read back to them… does your website makes sense?

1. Make sure form fields have a <label>. It is OK to hide labels with CSS: <label class="sr-only">
2. Using <fieldset> and <legend> to group related form elements.
3. Provide descriptive alt attributes on images: <img alt="A hen Mallard landing on a pond"> vs <img alt="mallard_duck-1.jpg">
4. Read more about “Labeling Controls” from w3.org.

3) Don’t rely on purely visual cues

If a page is being read to a user by a screen reader, it may not be obvious what the user is supposed to do next.

1. Make sure call to actions have labels that can be read by a screen reader.
2. Do call to actions meet a minimum contrast ratio? Meaning, can this person actually see/read it? Make sure the contrast ratio (on everything from text to buttons) is at least 1:4.5 for normal text and 3:1 for headings.

4) Make everything usable on a keyboard, mouse, and touch screen

1. Make sure you can use the tab, spacebar, and arrow keys to navigate a web page.
2. Give users the option to skip around a page.
3. Complex components such as sliders or modals should be tested with arrow and esc keys.

Tools Can Help

These accessibility testing tools can help, by pointing out areas of your web page that need work.

• Tenon.io – Will check your website against Section 508 and WCAG 2.0, and provide recommended fixes.
• WAVE – Similarly, WAVE can test your website against accessibility standards and even display contrast issues.
• Total Validator – Available for Windows and MacOS, this tool can test entire websites against a wide range of validation tests.

Conclusion

By thinking about and ultimately acting on these principles during the entire life cycle of a project, from scoping to design, development, and QA, not only will you be making your website usable by those with disabilities, you will be doing the right thing. This will come with many other benefits including: long-term maintainable code, SEO juice, and that feeling deep down when you do something nice for someone else. In my book, it doesn’t get more successful than that.

Further Reading

• MDN – Learning accessibility
• WebAIM – Training, assistance, certification, and testing
• WordPress Accessibility Code Standards – The WordPress A11y Team
• Accessibility APIs – A key to web accessibility

The post How Thinking About Accessibility Can Lead to Success appeared first on WebDevStudios.

]]> https://webdevstudios.com/2017/07/05/how-thinking-about-accessibility-can-lead-to-success/feed/ 0 17164 https://webdevstudios.com/2016/06/09/five-for-the-future-may-2016/ https://webdevstudios.com/2016/06/09/five-for-the-future-may-2016/#respond Thu, 09 Jun 2016 19:17:46 +0000 https://webdevstudios.com/?p=13221 Although contributing to the open source–and specifically, the WordPress–community has always been a central component of WebDevStudios’ philosophy, it wasn’t until October of 2014 that we figured out how to formally contribute as a full company. We started participating in Five for the Future, where we designated 5% of WDS working hours to giving back Read More What WDS Did During Five for the Future: May 2016

The post What WDS Did During Five for the Future: May 2016 appeared first on WebDevStudios.

]]> Although contributing to the open source–and specifically, the WordPress–community has always been a central component of WebDevStudios’ philosophy, it wasn’t until October of 2014 that we figured out how to formally contribute as a full company. We started participating in Five for the Future, where we designated 5% of WDS working hours to giving back to WordPress. Since many of our developers are passionate about WordPress, it wasn’t difficult to get everyone on board, and a bunch of cool things have come out of the time we’ve spent on it!

Last month, we started detailing the 5FTF goodies we finished up, and decided to keep it going! Here’s round two!

This past month, we worked on a few projects during May 5FTF time that we thought you might like to hear about:

WP CLI Random Posts Generator

Jay worked on this super rad WP CLI random post generator.

From the plugin page:

This WP CLI posts generator, unlike the core generator in WP CLI, supports the following:

 

• Terms
• Term Counts
• Taxonomies
• Post Types
• Post Counts
• Post Author
• Featured Images (thanks to lorempixel.com)
• Featured Image Types (thanks to lorempixel.com)
• Image Download sizes
• Multi-site (specify site id if necessary)

And what’s even more awesome: WP CLI Random Posts Generator was added to the official site courtesy of Daniel Bachhuber, the maintainer of WP-CLI.org.

Variable VVV – The Best VVV Site Wizard Version 1.10

Remember Variable VVV? Parbs recently released vv 1.10, which is mostly a collection of bug fixes, along with some nifty new features.

One of the most frustrating bugs that vv has is not always correctly setting the path to your VVV installation. This means some people were never able to use vv to manage their sites. Thankfully, there is now very robust checking and fallbacks so that everyone can have vv working correctly on their system.

Thanks to some great contributions, vv’s Blueprint functionality now allows for configuring menus, network options, and a lot more. You can practically build your entire site using Blueprints now.

Minor bug fixes are the process for halting Vagrant, removing old files, and better system-level integration are now in place as well.

(Special thanks to Parbs for giving us this blurb.)

wdunderscores

Not too long ago, Corey caused a stir by saying SEEYA to hamburger navigation. Well, he finalized it and moved it into wd_s! Huzzah!

BuddyPress Codex

Ryan cleaned up the Changing Internal Configuration Settings in the BuddyPress codex…it makes sense that he was there, since he’s been working with Pluginize on BuddyExtender, a free plugin that allows you to configure internal BuddyPress settings from the WordPress dashboard.

This is proof that you coding isn’t the only contribution; a little codex copyediting counts as contributing, too.

The Forums

Aubrey, Jay, and Will were all over the forums during their 5FTF time this past month as well.

---

These are some of the cool things that we worked on during May’s 2016’s 5FTF time! We know a bunch of you out there are contributing back as well–what have you worked on recently?

Tell us! We want to hear about your nifty new projects too.

The post What WDS Did During Five for the Future: May 2016 appeared first on WebDevStudios.

]]> https://webdevstudios.com/2016/06/09/five-for-the-future-may-2016/feed/ 0 13221 https://webdevstudios.com/2016/05/03/a-strategy-for-styling-gravity-forms/ https://webdevstudios.com/2016/05/03/a-strategy-for-styling-gravity-forms/#comments Tue, 03 May 2016 16:43:05 +0000 https://webdevstudios.com/?p=12700 Over the past few weeks, there has been a lot of work done to the starter theme we use at WDS, known as wd_s. Everything from incorporating a pattern library, migrating our build system from Grunt to Gulp, and adding some really great menu enhancements are just a few that we’ve covered! Another enhancement we wanted Read More A Strategy for Styling Gravity Forms

The post A Strategy for Styling Gravity Forms appeared first on WebDevStudios.

]]> Over the past few weeks, there has been a lot of work done to the starter theme we use at WDS, known as wd_s. Everything from incorporating a pattern library, migrating our build system from Grunt to Gulp, and adding some really great menu enhancements are just a few that we’ve covered!

Another enhancement we wanted to make was to add a set of base styles directly into the theme for Gravity Forms. I decided to take this task on! Here’s the process I went through to make it happen:

Why a Base Set of Styles?

Applying custom styles to a Gravity Form can turn messy real quick. It can also be very time-consuming if you aren’t familiar with it, because you will be spending the majority of your time trying to figure out what selector to use.

NOTE: I will be referring to Gravity Forms as GF through this post.

Since we use GF on many of our projects, it only seemed logical to set up a simple, not-too-opinionated set of styles that provide a nice starting point for all new projects–something that would cover the most commonly used form fields and provide the ability for extending if necessary.

The Goal

I want this post to be helpful for anyone using Gravity Forms. I may refer to the wd_s theme specifically, but the ideas shared should apply under the context of any theme. I hope to save you time in your Gravity Form styling adventures by detailing a few of the problems I worked to overcome and provide some helpful tips and strategies along the way!

There are quite a few points I want to touch on in this post, so I won’t be focusing so much on the code, but the thinking behind why I went about things a certain way.

I will provide a direct link to the base style file at the end of the post. Please take the time to review it and use it!

Initial Requirements

As I was getting input from my co-workers and getting a game plan together, I put together a few requirements or goals for these base styles:

• Styles should not require any configuration by user–an example of this would be a user having to add class names to fields when creating a form (other than CSS Ready classes).
• Local GF variables should integrate into existing form variables but have the ability to be customized.
• Avoid the use of !important –this tends to happen a lot when styling GF.
• Account for common fields only–the advanced/complex fields can be addressed on a case-by-case basis.
• Sass–keep nesting to a minimal.

Resources

The Gravity Forms documentation is pretty great, but there are two key pieces I thought were most helpful:

• CSS Targeting Examples
  Referencing these examples will show you exactly what selectors you need to use to target a specific field type.
• CSS Ready Classes
  These are classes provided by GF and are used mostly for creating more advanced form layouts such as a form that has two columns. Knowing these classes is important when you want to override the default styles. For example, we will be tweaking the .gf_left_column and .gf_right_column classes a bit later.

Sensible Local Variables

One of the awesome features of Sass is the ability to use variables. Using variables in form styles helps to provide consistency as well as the ability to quickly apply a set of changes!

I would advise against going crazy and creating all kinds of variables. Be deliberate and start out with a select few. You can always add to them later as the need arises.

Here are the variables I chose to target:

//--------------------------------------------------------------
// LOCAL VARIABLES
//-------------------------------------------------------------------

// Form
$gf-padding: 0; // set outer padding on form
$gf-bg: $color-white; // background color of form
$gf-border-width: 0; // border-width on form
$gf-border-color: $color-white; // border color

// Fields / Rows
$gf-field-margin-bottom: rem(25); // margin between field and label below (vertical spacing between rows)

// Labels
$gf-label-font-size: rem(16);
$gf-label-font-color: $color-mineshaft;
$gf-label-font-weight: 700;

// Inputs
$gf-input-color-background: $color-white;
$gf-input-color-border: $color-input-border;
$gf-input-color-text: $color-input-text;
$gf-input-color-focus-text: $color-input-focus-text;
$gf-input-padding: $padding-input;

As you can see, the input variable values are initially tied into the global form variables but can be overwritten if necessary.

Filling Parent Element

One of my biggest pet peeves about the default GF styles is that the main form wrapper does not fill its parent element. This is especially a problem on forms that are two-columns–and as we know, alignment with the rest of the content is paramount.

Here’s an example of what I mean:

In short, the widths for the form wrapper, columns, and inputs needed to be adjusted in order to achieve the desired result which looks like this:

BOOM! Notice how the form extends the full-width of the containing element and the form fields extend the full width of the form itself.

Strategies for Overcoming !important

If you have ever applied custom styles to a Gravity Form, you have undoubtedly had to use !important to override the GF default styles. Don’t worry, I’m right there with you!

In my first pass at coding these base styles, I resorted to using !important fourteen times. Yikes! This was not acceptable and I needed to find a better way to apply these styles that wouldn’t require so many uses of !important.

This is when being able to get input from awesome co-workers is invaluable!

Enter Damon

Damon presented the idea of creating one content specific selector that could be used to house all of the styles that needed to override the GF defaults. The thinking behind this was to just target anything GF form related in this selector that needed higher specificity.

Here is an example of what I mean:

#content .gform_wrapper {
margin-right: 0; // allow for full width of containing element
	max-width: 100%; // allow for full width of containing element

	// Standard fields
	input[type="text"],
	input[type="url"],
	input[type="email"],
	input[type="tel"],
	input[type="number"],
	input[type="password"],
	input[type="file"],
	textarea{
		padding: $gf-input-padding;
		width: 100%;

		@include media($phone-landscape) {
			width: 49%;
		}
	}
}

Using the #content selector makes all selectors in this block more specific than the default GF styles which results in them taking higher priority. As long as the GF style isn’t using an !important, our styles will override!

This was a brilliant idea and allowed for getting rid of all but two uses of !important!

Mobile Styles

As I was working through this task, I quickly realized that just having some default mobile styles in place would be a huge time-saver. At WDS, we typically like our forms to have inputs that have a width of 100% on mobiles and then adjust accordingly as the screen-size grows.

Having these mobile styles built into the default wd_s theme styles is going to save us time and maybe one less headache!

Wrapping Up

In the end, taking on the task of writing these base GF styles was a great learning experience. It really drives home the point of we should always be trying to identify ways to improve our workflow and make ourselves more efficient.

I encourage you to go checkout the full code on Github. Please leave your questions, comments, or suggestions below! I want to hear from you.

The post A Strategy for Styling Gravity Forms appeared first on WebDevStudios.

]]> https://webdevstudios.com/2016/05/03/a-strategy-for-styling-gravity-forms/feed/ 9 12700 https://webdevstudios.com/2016/04/26/skype-in-media-on-wordpress/ https://webdevstudios.com/2016/04/26/skype-in-media-on-wordpress/#comments Tue, 26 Apr 2016 15:00:59 +0000 https://webdevstudios.com/?p=13019 Last quarter, we were hired by Skype and tasked with building a smaller site, featuring Skype TX. Skype TX is “studio-grade hardware for the broadcast industry, which features peerless integration with Skype.” In other words, Skype Tx is powerful hardware and software for professionals in live broadcast situations. Because of a hard launch date, this project had a super Read More How We Built Skype in Media on WordPress

The post How We Built Skype in Media on WordPress appeared first on WebDevStudios.

]]> Last quarter, we were hired by Skype and tasked with building a smaller site, featuring Skype TX. Skype TX is “studio-grade hardware for the broadcast industry, which features peerless integration with Skype.” In other words, Skype Tx is powerful hardware and software for professionals in live broadcast situations.

Because of a hard launch date, this project had a super short timeline and we decided a smaller team would keep us agile. Jaimie would be our Project Manager, Simon would handle the designs/PSD, Damon would deal with the front-end development, and I oversaw the back-end development, as well as serving as a lead for the project as a whole.

I’d like to share our teams experience through building a new website for a pretty well known client.

Designs

Part of the scope, was a custom design, which featured five different templates. Skype wanted something similar to their current production site, but freshened up a bit for the new product launch. Simon also had brand guidelines and some direction from our point of contact at Skype. I spoke with Simon who told me, “All design research starts with listening. One of the issues Skype had was [that] Skype TX was buried.”

Simon took some time to research the product and find the business value within brand guidelines. This process is called “business proposition.” During the design phase, Simon also had to make the case for a few features.

“Behind good design, there’s a reason for everything. Form follows function since we’re designing not only for the client, but the client’s client…” (AKA the user!)

Thanks to software like Invision, communication between the Simon and the client went smoothly and after a few revisions, both Damon and I had PSDs to work with.

Choosing the theme and plugins

Almost all of our projects include our starter theme, wd_s. This build was no exception! Wd_s enables developers to spin-up a starter themes quickly and develop with modern build tools like Sass and Gulp. We didn’t install too many plugins; we used a select few to manage content via point-and-click, ensure everything had a featured image, rearranging page order, and more. We also used a few custom plugins as well.

The Hero

By far the most complicated part of this build was the Hero.

Take a look at the requirements:

• Every post and page must have a hero
• Use post title, excerpt, and featured image as the content, but can add additional content can be added in a control panel
• By adding additional images/content, the hero turns into carousel
• Each carousel slide can have a modal
• Modal must support oEmbeds
• Customizable headline
• Customizable paragraph
• Support for two different buttons, one of which opens a modal

If your head is spinning, don’t worry. So was mine! After speaking with Chris for a bit, we put together a development roadmap and I got to work. Because this hero had to be on every post and page, we decided to use CMB2 to create repeatable group metaboxes. These would serve as the optional “control panel.”

I also used Slick to power the carousel and custom Javascript and CSS to power the modal.

In the end, I really like how the Hero turned out. Some of the functionality developed here, will make its way into our Hero Widget plugin on Github.

The Footer

While it may not appear to be complicated, the footer was indeed difficult. Microsoft requires footers on all their web properties to be visually similar. We were instructed to “copy” the footer assets, markup, and functionality from production.

This proved to be a bit of a struggle as Damon describes, “They had some toggling in footer that worked on desktop, but didn’t have a great mobile experience. So we updated the code by rewriting the Javascript around the toggling altogether…”

In the end, Damon did a fantastic job creating a footer that works beautifully at any viewport.

Accessibility

Microsoft takes accessibility very seriously, and this was part of scope from the beginning (as well as a general practice here at WebDevStudios). We had to design and develop to meet WCAG 2.0AA standards. As you can imagine, since Microsoft is such a large company, failure to meet these standards could cost them tens of thousands of dollars in fines. Fines aside, making websites accessible for everyone is just the right thing to do.

We put this site through some rigorous testing to ensure things like, the color contrast and HTML markup passed 2.0AA specs using both Total Validator and ContrastChecker.

Data Migration

Ah yes, the final part of this project was moving the content from their proprietary CMS into WordPress. Normally, this would be handled by our migration team using our custom migration plugin. However given that the site only had about fifty posts, and the time necessary to interface our plugin into that CMS, we instead opted to migrate the data by hand. This process went fairly quickly, and in no time we had all of their content in place.

Hosting

We’ve been working with Microsoft and their WordPress properties for a couple years, so we’re familiar with the unique challenges and benefits of running WordPress on Azure.

We introduced Microsoft to WPEngine and provided the technical guidance to get Skype in Media on WPE! It’s pretty cool that this project will be the first web property owned by Microsoft on WPEngine!

Conclusion

Even though this was a custom built site for an enterprise level client, we had a short timeline and a few development hurdles. In the end, it was a fun project. I believe we were able to successfully help rebrand Skype TX, and hopefully this will help them sell a few more pieces of hardware–which at the end of the day, is why we’re here.

The post How We Built Skype in Media on WordPress appeared first on WebDevStudios.

]]> https://webdevstudios.com/2016/04/26/skype-in-media-on-wordpress/feed/ 6 13019 https://webdevstudios.com/2016/04/19/wd_s-pattern-library/ https://webdevstudios.com/2016/04/19/wd_s-pattern-library/#comments Tue, 19 Apr 2016 14:35:40 +0000 https://webdevstudios.com/?p=12715 We recently discussed the differences between a Style Guide and Pattern Library, and the opportunity for leveraging both inside of a WordPress theme. Today, I’m excited to introduce you to wd_s Pattern Library 1.0 ? Here is a list of features (which I’ll also cover in further detail later in this post): 36 user interface Read More Introducing the wd_s Pattern Library!

The post Introducing the wd_s Pattern Library! appeared first on WebDevStudios.

]]> We recently discussed the differences between a Style Guide and Pattern Library, and the opportunity for leveraging both inside of a WordPress theme. Today, I’m excited to introduce you to wd_s Pattern Library 1.0 ?

Here is a list of features (which I’ll also cover in further detail later in this post):

• 36 user interface patterns available out-of-the-box
• An auto-generated colors swatches page, which watches the _color.scss for changes, and recompiles as needed.
• A Typography page, which allows you to quickly test out typographical choices.

36 Patterns, and then some

Out of the box the Pattern Library contains thirty-six common UI patterns, and they’re organized in to the following categories:

• Accordions
• Carousels / Sliders
• Data Visualization
• Effects
• Forms / Fields / Inputs
• Hero / Banner
• Layout
• Media
• Navigation

Each pattern was written to meet our internal standards, as well as the WordPress coding standards. Also, each pattern leverages as much of wd_s default CSS as possible. Let’s look at an example pattern with only the default wd_s styling applied.

As you can see each pattern contains a bit of meta information, like original author, date added, and a brief description, as well as the HTML should you chose to use it in your WordPress theme. Pretty neat, right?

Should you also choose to extend the pattern, we’ve organized all the associated Sass partials in a corresponding /patterns/ directory. So we can modify the example pattern above by turning it on (all patterns are off by default) in /assets/sass/patterns/index.scss with $use-vertical-bar-chart: true !default;, and can modify the partial (/assets/sass/patterns/_vertical-bar-chart.scss) to your heart’s desire, and see the results instantly in the Pattern Library.

You can even extend the original HTML, if you like, as the whole Pattern Library runs on Jekyll, the static site generator. Just open up the corresponding pattern in the Pattern Library’s /src (or to continue our example: /pattern-library/src/_patterns/vertical-bar-chart.html).

Color swatches

We thought this would be a nice bonus, as it ties in to the concept of creating a Style Tile. Whether you’re a developer or a client, often times it is useful to see a color palette, so we put in an auto-generated color swatches page that watches the _colors.scss Sass variables partial, and regenerates when any changes are detected. This gives us a single point of reference during discovery, scaffolding, and development to see what colors are available, as well as avoid overly extending existing colors.

wd_s Pattern Library 2.0 – What is in store?

We’ve already got a bunch of improvements for the next version, but first we want to get some mileage and squash some bugs. Please help us test it out by checking out the feature/pattern-library branch (git clone -b feature/pattern-library git@github.com:WebDevStudios/wd_s.git) of wd_s, and let us know what you think.

The post Introducing the wd_s Pattern Library! appeared first on WebDevStudios.

]]> https://webdevstudios.com/2016/04/19/wd_s-pattern-library/feed/ 2 12715 https://webdevstudios.com/2016/04/12/gulp-configuration-a-beginners-guide/ https://webdevstudios.com/2016/04/12/gulp-configuration-a-beginners-guide/#comments Tue, 12 Apr 2016 14:25:13 +0000 https://webdevstudios.com/?p=12691 Recently, WebDevStudios integrated Gulp into our theme boilerplate, wd_s. Below, I go through the Gulpfile.js, section by section, in hopes that you can benefit from our mistakes experience. Terminology Alright, newbie, before we dive in, let’s go over a few definitions: Gulp – A streaming build system. Sometimes called a “task runner,” which is built on Node. With the Read More Gulp Configuration: A Beginners Guide

The post Gulp Configuration: A Beginners Guide appeared first on WebDevStudios.

]]> Recently, WebDevStudios integrated Gulp into our theme boilerplate, wd_s. Below, I go through the Gulpfile.js, section by section, in hopes that you can benefit from our mistakes experience.

Terminology

Alright, newbie, before we dive in, let’s go over a few definitions:

Gulp – A streaming build system. Sometimes called a “task runner,” which is built on Node. With the right combination of plugins (aka “dependencies”), Gulp will handle otherwise tedious tasks only fit for an intern, like: compiling Sass or Less, minifying JavaScript, optimizing images, etc.

Node – Node.js (aka “Node”), is a JavaScript runtime environment. This is the engine that runs Gulp and its plugins.

NPM – The Node Package Manager (NPM), reads a JSON formatted configuration file (package.json) and downloads any required dependencies into a folder named “node_modules.”

.stream() – Typically, Gulp will pass (but never cross) a “stream” of files through plugins, which transforms the files in some way. Streams are handled by Node.

.pipe() – If you’re familiar with the command line, you may already know about the vertical bar | (aka “pipe”). This dohicky is used to pass the output of one command to the input of another. The same thing is accomplished via the .pipe() method. This occurs in the stream.

.task() – Defines a task which executes either an anonymous or callback function.

.src() – Creates a stream of files.

.dest() – Writes the stream to a file on a hard disk.

One Config File vs Multiple Config Files

While putting our Gulpfile.js together, there was talk about splitting the tasks into multiple files. After careful consideration, we decided to place everything into one file, and then document the heck out of it.

We felt like a single file would help fellow beginners understand the inner workings of Gulp. Gulpfile.js is written pure JavaScript, and we often joke about there being “twenty-six ways to do the same thing.” While humorous, that statement is absolutely true! If you spend any time on Google or Github looking at other’s Gulp configuration, you might scratch your head and wonder, “Why did this person write it that way?” or “Wow! I didn’t know I could write it that way…”

I promise you, there isn’t really a right or wrong way to set up Gulpfile.js. Do what makes you comfortable. If your configuration works and is executing those tedious tasks? Then you’ve done it right. As you feel more comfortable with the config, you can always go back and iterate.

In wd_s, all Gulp related configuration is contained in a single Gulpfile.js.

Adding Dependencies

Dependencies? Plugins? Which one is it?

Items that are going to be downloaded via NPM are “dependencies” and are defined in package.json. A snippet from our package.json file:

{
  "name": "wd_s",
  "version": "1.0.0",
  "description": "A theme boilerplate for WebDevStudios.",
  "main": "Gulpfile.js",
  "dependencies": {
    "gulp": "^3.9.1",
    "gulp-cssnano": "^2.1.0",    
    "gulp-sass": "^2.2.0",
  },
}

You would then type the following command into your terminal:

npm install

This instructs NPM to go fetch Gulp, CSSNano and Sass… NPM will place the files into a folder named, node_modules.

In the context of Gulp, those dependencies are called “plugins”. In the header of Gulpfile.js, we will define the plugins we just installed using NPM:

// Define some plugins!
var gulp = require('gulp');
var sass = require('gulp-sass');
var cssnano = require('gulp-cssnano');

What’s going on here? We’ve set a variable for each dependency, which tells Gulp we want to use each of those as plugins. Gulp already knows to go look inside node_modules, so there isn’t a configuration setting necessary for that.

If you’ve made it this far? Awesome, sparky. We’re almost done!

Our First Task

Now that we’ve defined our plugins, lets run a task (which are sometimes called “recipes”) to compile that Sass. In Gulpfile.js, we’ll write:

/**
 * Compile Sass.
 */
gulp.task('sass', function() {
    return gulp.src('./sass/*.scss') // Create a stream in the directory where our Sass files are located.
    .pipe(sass())                    // Compile Sass into style.css.
    .pipe(gulp.dest('./'));          // Write style.css to the project's root directory.
});

Boom! A very simple task which can be used to compile Sass and create style.css! The code above is simply an anonymous JavaScript function wrapped in gulp.task(). (Check out the gulp.task() API for more)

To execute [‘sass’], simply type the following command into your terminal and press enter:

gulp sass

Man, we’re doing great, huh? But what a pain-in-the-butt to have to type that command every time we make a change. Did you know Gulp can automatically compile Sass each time we save a Sass file? Check this recipe out:

/**
 * Watch the Sass directory for changes.
 */
gulp.task('watch', function() {
  gulp.watch('./sass/*.scss', ['sass']);  // If a file changes, re-run 'sass'
});

In your terminal, simply type the following (instead of gulp sass) and press enter:

gulp watch

Now, anytime you make changes and save any file with a .scss extension, it will trigger this [‘watch’] task which executes [‘sass’]. We sure are rock stars, huh?

Daisy Chaining Tasks

I gotta admit, it’s pretty sweet that we can compile Sass, but what if we want to minify it too?

Because JavaScript is single-threaded, we can run tasks concurrently (aka daisy chain) and they will execute one after another. Let’s chain a couple tasks together…we need to create a secondary task to minify our compiled stylesheet, style.css:

/**
 * Minify stylesheet.
 */
gulp.task('minify', ['sass'], function() {
    return gulp.src('style.css');  // Grab style.css and add it to the stream.
    .pipe(cssnano())               // Minify and optimize style.css
    .pipe(gulp.dest('./'));        // Write style.css to the project's root directory.
});

Do you notice anything different about this task? Before the anonymous function starts, we’re inserting an array with the word [‘sass’] wrapped in single quotations. This tells gulp.task() to execute [‘sass’] before running [‘minify’].

This is fantastic! However, we’re still having to type something each time we make a change…and because I’m lazy, that goes against everything I stand for.

How about we refactor our [‘watch’] task. Then, we can be super lazy; we only have to type one command to kick-off a cascading event of mind blowing compilation proportions:

/**
 * Watch the Sass directory for changes.
 */
gulp.task('watch', function() {
  gulp.watch('./sass/*.scss', ['minify']);  // If a file changes, re-run 'sass' and then 'minify'
});

Gulp is now watching our files, and whenever we make a change…it will start a chain reaction which will create compiled a stylesheet along with a minified version too! #MindBlown

Alright champ. I’ve shown you how to do some cool things with Gulp. Hopefully, I’ve helped you feel confident enough to make your own Gulpfile.js. Now, go forth and use Gulp to help you be just as lazy as we are! Thanks and good luck!

…

..

.

Ok. I can see you’re not an average developer. You seem to be a glutton for punishment and have the stomach for some advanced stuff. Proceed with caution…

Advanced Example

Below is an example Gulpfile.js, which will put our Sass through a gauntlet of plugins:

• If there are no errors
  • Lint to ensure code standards are followed
  • Autoprefix
  • Combine similar media queries
  • Compile style.css
  • Optimize
  • Minify
  • Create style.min.css
  • Delete pre-existing compiled files
  • Refresh the web browser when finished

What you’re about to see is nothing more than a few concurrent tasks:

// Define some plugins!
var autoprefixer = require('autoprefixer');
var bourbon = require('bourbon').includePaths;
var browsersync = require('browser-sync');
var cssnano = require('gulp-cssnano');
var del = require('del');
var gulp = require('gulp');
var gutil = require('gulp-util');
var mqpacker = require('css-mqpacker');
var neat = require('bourbon-neat').includePaths;
var notify = require('gulp-notify');
var plumber = require('gulp-plumber');
var postcss = require('gulp-postcss');
var rename = require('gulp-rename');
var sass = require('gulp-sass');
var sasslint = require('gulp-sass-lint');
var sourcemaps = require('gulp-sourcemaps');

// Set asset paths.
var paths = {
 css: ['./*.css', '!*.min.css'],
 sass: 'assets/sass/**/*.scss',
};

/**
 * Run Sass through a linter.
 */
gulp.task('sass:lint', ['cssnano'], function() {
 gulp.src([
  'assets/sass/**/*.scss',
  '!assets/sass/base/_normalize.scss',
  '!assets/sass/utilities/animate/**/*.*',
  '!assets/sass/base/_sprites.scss'
 ])
 .pipe(sasslint())
 .pipe(sasslint.format())
 .pipe(sasslint.failOnError());
});

/**
 * Minify and optimize style.css.
 */
gulp.task('cssnano', ['postcss'], function() {
 return gulp.src('style.css')
 .pipe(plumber({ errorHandler: handleErrors }))
 .pipe(cssnano({ safe: true }))
 .pipe(rename('style.min.css'))
 .pipe(gulp.dest('./')));
});

/**
 * Compile Sass and run stylesheet through PostCSS.
 */
gulp.task('postcss', ['clean:styles'], function() {
 return gulp.src('assets/sass/*.scss', paths.css)
 .pipe(plumber({ errorHandler: handleErrors }))
 .pipe(sourcemaps.init())
 .pipe(sass({
   includePaths: [].concat(bourbon, neat),
   errLogToConsole: true,
   outputStyle: 'expanded'
 }))
 .pipe(postcss([
   autoprefixer({ browsers: ['last 2 version'] }),
   mqpacker({ sort: true }),
 ]))
 .pipe(sourcemaps.write())
 .pipe(gulp.dest('./'))
 .pipe(browserSync.stream());
});

/**
 * Clean compiled files.
 */
gulp.task('clean:styles', function() {
 return del(['style.css', 'style.min.css'])
});

/**
 * Process tasks and reload browsers.
 */
gulp.task('watch', function() {
 var files = [
   paths.sass
 ];
 browserSync.init( files, {
   open: false,
   proxy: "foo-client.dev",
   watchOptions: { debounceDelay: 1000 }
 });
 gulp.watch(paths.sass, ['styles']);
});

/**
 * Handle errors.
 */
function handleErrors() {
 var args = Array.prototype.slice.call(arguments);
 notify.onError({
   title: 'Task Failed [<%= error.message %>',
   message: 'See console.',
   sound: 'Sosumi'
 }).apply(this, args);
 gutil.beep();
 this.emit('end');
}

In the terminal, we type:

gulp watch

And we’re off creating a theme for our client. If you feel like there’s a lot to take in, don’t worry. There are really only four tasks daisy-chained together, a watch task, and a helper function which deals with errors.

Let me break it down:

In the first task, we’re running all of our Sass against both WordPress and WDS coding standards with a Sass Linter. This ensures that everyone on the project is writing excellent Sass.

/**
 * Run Sass through a linter.
 */
gulp.task('sass:lint', ['cssnano'], function() {
 gulp.src([
  'assets/sass/**/*.scss',                  // Include all files that end with .scss
  '!assets/sass/base/_normalize.scss',      // Ignore _normalize.scss
  '!assets/sass/utilities/animate/**/*.*',  // Ignore any animations
  '!assets/sass/base/_sprites.scss'         // Ignore _sprites.scss
 ])
 .pipe(sasslint())
 .pipe(sasslint.format()) 
 .pipe(sasslint.failOnError());
});

[‘sass:lint’] is daisy chained with [‘cssnano’] which optimizes, minifies, and creates a production ready, style.min.css

/**
 * Minify and optimize style.css.
 */
gulp.task('cssnano', ['postcss'], function() {
 return gulp.src('style.css')
 
  // Deal with errors.
 .pipe(plumber({ errorHandler: handleErrors }))
 
 // Optimize and minify style.css.
 .pipe(cssnano({
    safe: true // Use safe optimizations.
 }))

 // Rename style.css to style.min.css.
 .pipe(rename('style.min.css')) 

 // Write style.min.css.
 .pipe(gulp.dest('./'))
 
 // Stream to BrowserSync.
 .pipe(browserSync.stream());
});

[‘cssnano’] is daisy chained with [‘postcss’], which compiles, auto prefixes, and combines all media queries into style.css

/**
 * Compile Sass and run stylesheet through PostCSS.
 */
gulp.task('postcss', ['clean:styles'], function() {
 return gulp.src('assets/sass/*.scss', paths.css)

 // Deal with errors.
 .pipe(plumber({ errorHandler: handleErrors }))

 // Wrap tasks in a sourcemap.
 .pipe(sourcemaps.init())

 // Compile Sass using LibSass.
 .pipe(sass({
   includePaths: [].concat(bourbon, neat), // Include Bourbon & Neat
   errLogToConsole: true, // Log errors.
   outputStyle: 'expanded' // Options: nested, expanded, compact, compressed
 }))

 // Parse with PostCSS plugins.
 .pipe(postcss([

  // Only prefix the last two browsers.
  autoprefixer({
     browsers: ['last 2 version'] 
   }),

  // Combine media queries.
  mqpacker({
     sort: true 
   }),
 ]))

 // Create sourcemap.
 .pipe(sourcemaps.write())

 // Create style.css.
 .pipe(gulp.dest('./'))

 // Stream to BrowserSync.
 .pipe(browserSync.stream());
});

But first we’re going to “clean” our compiled files by deleting them with [‘clean:styles’]

/**
 * Clean compiled files.
 */
gulp.task('clean:styles', function() {
 return del(['style.css', 'style.min.css']) // Delete style.css and style.min.css from the hard disk.
});

And finally, with [‘watch’] we’re using BrowserSync to view our changes instantly in the web browser after everything has successfully run:

/**
 * Process tasks and reload browsers on file changes.
 */
gulp.task('watch', function() {

 // Files to watch.
 var files = [
   paths.sass
 ];

 // Kick off BrowserSync.
 browserSync.init( files, {
   open: false,             // Don't open a new tab on init.
   proxy: "foo-client.dev", // The URL of our local project.
   watchOptions: {
     debounceDelay: 1000    // Wait one second before refreshing.
   }
 });

 // Run tasks when files change.
 gulp.watch(paths.sass, ['styles']);
});

If your head is spinning, I can assure you so was ours!

But if you look at the inline documentation and comments; you’ll see that it’s actually a beautiful symphony of plugins working together in harmony, which ultimately make our workflow fast and efficient. (All the code above, executes in a few hundred milliseconds! ERMAHGERD!)

This enables the developers at WebDevStudios to type one command, and then spend all day focused on theming–with zero time lost doing any of those “tedious tasks” by hand.

Conclusion

As you can see, Gulp can be a very powerful tool, but it’s only as powerful as you make it! Because it’s written in JavaScript, there are many ways to accomplish the same thing. So remember–use Gulp the way that is most comfortable for you.

If large configuration files spread across multiple folders is a bit intimidating…then I would encourage you to check out the full Gulpfile.js in wd_s and then experiment with our setup. Maybe one day soon, you’ll be as excited as we are about using Gulp as a build tool. Thanks for reading!

Official Gulp Links:

• Gulp: Getting Started
• Gulp Documentation
• Gulp Recipes
• Gulp Plugins
• Gulp API

The post Gulp Configuration: A Beginners Guide appeared first on WebDevStudios.

First, a little more context:

Recently, the Front-end Developer team at WebDevStudios set out to create a user interface (UI) pattern inventory. The team recognized a set of UI patterns that were being created again and again across projects. We wanted a way to document these UI patterns, which would allow the team to be consistent, while incorporating best practices and our strive for accessible, robust standards. We researched tools and frameworks in order to try and find the best possible solution for documenting our patterns, across the team. Ultimately, we chose CodePen, because most of the team was familiar with it, and it allowed us to have a single source to house all our patterns. Check it out: WebDevStudios CodePen.

Simultaneously, there is an effort to aggregate all the patterns in to our WordPress starter theme: wd_s. This way the style of the theme gets applied to the patterns instantly, and allows for rapid-prototyping. Choose a UI pattern, or start theming, and either way they’re one and the same.

Now, let’s continue to extrapolate the differences between Style Guides and Pattern Libraries, and hopefully see where the two overlap, and where they differ.

Style Guide vs. Pattern Library

A Style Guide can typically encompass a company’s branding guidelines, which could include: logo usage, designated color palettes, and editorial tone. It is often wrapped in to a deliverable for, or by a company to work with outside vendors. Style Guides often fundamentally aid in establishing a company’s internal baseline for product and service goals, and exhibit a cohesive customer experience. Style Guides can directly influence the look and feel of a Pattern Library. Style Guides can stand on their own without data, while Pattern Libraries rely on some data to function.

Here are a few popular examples of Style Guides:

• Dropbox Branding Guidelines
• Draft U.S. Web Design Standards
• Best Buy Brand Guidelines

Pattern Libraries often encompass static UI elements, e.g. tabbed navigation, dropdown menu, accordion, and even common web page layouts, like grids. Style Guides do not always care about context, and relationships with data. Whereas UI elements, and their application in the overall user experience depend heavily on context and the interplay with content.

Here are a few examples of Pattern Libraries:

• MailChimp Pattern Library
• Salesforce Component Library
• Lonely Planet’s Component Library

Style Guide + Pattern Library = User Experience

So it is not really Style Guide vs. Pattern Library per se, but more like Style Guide and Pattern Library complement each other nicely.

The Style Guide establishes the root of visual presentation. User Interface patterns can be displayed in various contexts, and have different styles, which should be influenced by Style Guides. However, the UI pattern’s behavior should stand on its own, and not be affected by the Style Guide, or else it would hinder a positive user experience.

Where does rapid prototyping fit in?

By integrating barebones UI components into our wd_s WordPress starter theme we hope to enable our designers, front-end developers, and back-end developers to have a consistent library to reference, rapidly test for quicker feedback, and overall scaffold. So far, we’ve begun with a handful of components, but hope to increase the library in the coming weeks. Check out the Pattern Library branch of wd_s and subscribe for notifications on Issue #136 for progress and updates, and we would love to hear your feedback.

The post What is the Difference Between a Style Guide and Pattern Library? appeared first on WebDevStudios.

• Part I: History of wd_s
• Part II: Project Scaffolding with wd_s
• Part III: Future of wd_s

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.

Build Tools

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

This has also been in the back of our minds since 2013 when Stacy Kvernmo championed Atomic Design at the first WDSCamp.

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.

Sass Linting

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!

WP-API Support

There’s no denying how huge the WP-API is going to be, and while some believe that the days of using template tags are probably numbered, I doubt that is going to happen in the next couple of years. Internally we’ve decided to use Backbone and Underscore, however if using a tool like React or Angular makes more sense we’ll use those instead. As this technology continues to push forward and become refined, wd_s will definitely adapt to support the WP-API and become more and more Javascript focused.

Improved Documentation

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.

Join Us

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

The post The Future of WebDevStudios Starter Theme: wd_s appeared first on WebDevStudios.