Posted on

How to Make Your Blogging Dreams Come True [Part 2]

Choose one small thing to start with that will move you toward your dream and do it to the best of your ability (tweet this).

I issued that challenge in a post How to Make Your Blogging Dreams Come True just over a month ago. Since publishing that post, I’ve had literally hundreds of readers email me to let me know that they’ve been using the mantra to move them toward their blogging (and non blogging) dreams.

As a result, I thought I’d circle back to it today to check in with how people are going as well as suggesting another strategy for helping you to move toward your dreams.

Last week, I spoke at the World Domination Summit about ‘getting dreams out of your head’. I finished my talk by suggesting those in the audience take a moment to tell the person next to them a dream they wanted to chase.

What I’ve discovered, over the years, is that when I share my dreams the chances of them happening increases. I think this is for three reasons:

Sharing Dreams Creates Accountability

Firstly, it creates a little accountability. When I share a dream I have (whether it be a big dream or a small one) I find it opens a conversation that becomes ongoing. The other person then has permission to followup and ask how the dream chasing is going and even if they don’t ask, I know they know… so I am motivated to pursue it!

Sharing Dreams Helps You Recruit Dream Collaborators

Secondly, I find that by sharing a dream with another person you often find collaborators who can help you make it happen. Just last week I told a friend a dream of mine and two days later I received an email telling me that they’d been thinking about what I’d told them and that they:

  • knew someone that I should talk to that had experience in that area
  • had just read an article that I should read that touched on my dream
  • wanted to offer to help with one aspect of making the dream a reality

Sharing your dream might just unearth the keys to make that dream happen.

Sharing Dreams Makes Them More Robust

Lastly, I find that verbalising a dream helps the dream to find shape. My dreams usually start off just living in my mind. But once I share it, verbally, I begin to hear the strengths and weaknesses of what I’m saying. By putting words to your dream, you begin to test it and shape it. When others ask you questions about it you’re forced to look at it in a more realistic way – something that helps to make it a more robust idea!

Who to Share Your Dream With?

So at WDS last week I asked people in the audience to share a dream with the person next to them. This took a few people out of their comfort zone but in the days that have followed, I’ve had emails from a number of people who took the challenge who have already seen their dreams becoming a reality. And it all started when they shared a sentence or two about their dreams.

Sharing your dreams with random people is certainly something that can have a big impact but you might want to be a little more selective than that, particularly if your dream is more personal or in its very early stages.

Sometimes you want to be a little careful about who you want to share a dream with because some people will bring their critical thought processes to the dream before it is ready to be critiqued. There’s certainly nothing wrong with having a dream ‘tested’ by such people but I tend to do this once a dream has been developed and becomes a little emote robust!

I have a small group of friends and team members who I know are great for listening to my dreams and ambitions. They are people who care for me, who I trust and who I know will encourage and give energy towards making dreams come true. They are also people who can tell me if an idea isn’t so great when required – without crushing my spirt 🙂

Challenge: Share a Dream

So here’s my challenge to you. Share a dream!

Do you have a dream that you’ve been struggling to get out of your head? It may or may not relate to blogging – either way, I encourage you to share it with someone.

You may choose to do this by sharing it with a trusted friend as suggested above.

Or if your dream isn’t so personal or you’re ready to put it out there more publicly you might choose to do it in comments below or you might even write a blog post about that dream.

But don’t keep it to yourself!

How to Make Your Blogging Dreams Come True [Part 2]
http://www.problogger.net/archives/2013/07/17/how-to-make-your-blogging-dreams-come-true-part-2/
http://www.problogger.net/archives/category/miscellaneous-blog-tips/feed/
@ProBlogger» Miscellaneous Blog Tips
Blog Tips to Help You Make Money Blogging – ProBlogger
http://www.problogger.net/wp-content/plugins/podpress/images/powered_by_podpress_large.jpg

Posted on

History of the WebDevStudios Internal Starter Theme: wd_s

One of the most exciting things of my job here at WDS is getting to spearhead our internal starter theme: wd_s. It has come a long way since its inception (a fork of Automattic’s Underscores) and it’s a thrill to help mold it into something that our agency uses on every project. Though it hasn’t always been that way…

In the spring of 2013, WDS started to take on more enterprise level clients. Internally, WDS was also hiring more and more developers to match the workload. Our internal project workflow was also pretty fluid. Developers were assigned to projects based on individual availability. The first person to start a project would generally spin up a Genesis child-theme, or use our own premium theme Startbox, or maybe even choose a theme they were familiar with.

Shortly after I was hired, we kicked off a build for Securelist. Based on my availability, it was up to me to choose a theme. Naturally, I asked around to see how everyone felt. Because of some recent hires, not everyone was familiar with Genesis or Startbox. Given the size and scope of this project, we decided against Genesis and instead I opted for TwentyThirteen.

Deconstruction Can Sometimes Inhibit Construction

Let me set the record straight: Genesis is fantastic. It’s stable, secure, and mature. I’ve contributed to the codebase, have been known to champion it in a blog post or two, and even have a Sass version on Github. However, for large, 100% custom builds, working with an opinionated hook system instead of actual template files can get pretty awkward. As rock solid as Genesis is, it doesn’t exactly follow what WordPress considers “the standard” way to build a theme either. By choosing TwentyThirteen, we were able to get a bunch of real template files that adhere to WordPress theming standards. This was important, since there would be a few us working on this together, and we needed to maintain the code for an extended period of time; and potentially with a bunch of new hires.

If you’ve ever worked on a single build with a group, you know how important standards are. It’s really hard to work (together) if there isn’t a baseline set of rules. That is exactly what frameworks like Genesis, Bootstrap, Foundation, jQuery, etc… provide: opinions and standards which are there to help you get things “done” faster. When a development team is familiar with these standards, you maximize profits. However, too many opinions and rules can also inhibit construction and, frankly, get in the way.

Growing Pains

By the fall of 2013, Underscores was really gaining traction in the WordPress community. It’s an unopinated “bare bones” theme, built specifically to help you and I get a theme up and running quickly. What’s more is, it’s built upon WordPress theming and code standards. It’s also maintained by engineers from Automattic. For all intents and purposes, it’s the “official development theme” of WordPress.

We took notice here, and wondered what it would look like to combine the best things of Underscores with our own premium theme framework, Startbox. Brian Richards and I spent a few weeks that winter trying to create a product that would be both unopinionated and provide developers with an excellent starting point for projects. Brian integrated an amazing collection of template tags, the Theme Alliance hooks, and I converted all the CSS to Sass and added support for Grunt. Just reading the changelog is making me all kinds of nostalgic!

During StartBox’s development, WDS was still growing rapidly. 2014 would be here soon, and some huge projects were coming along with it. Even though we had made significant progress on StartBox, it was decided that StartBox would be shelved. Startbox wasn’t the only WDS premium product to be shelved, WDS simply did not have the bandwidth to maintain some of our premium products in the face of client work. The math just didn’t add up.

Gettin’ Sassy

Undeterred, we immediately decided to take another look at using Underscores. Having worked with it while trying to get the best parts into Startbox, plus all of my experience with Sass, I created a (very basic) Sass template which we would use with fresh clones of Underscores.

In February of 2014, we were frustrated with having to apply this Sass template over and over for new builds. I decided to submit a pull request which include a (very basic) Sass implementation. This pull request sparked a 5 month long discussion. After much debate, Sass was finally added in July of 2014.

While this was a huge win, it just took too long. While I believe it is paramount that WDS use what I call “the official development theme” of WordPress, we simply could not wait for development tools like Sass and Grunt. We decided to fork Underscores.

WDemocracy

One of the other things I love about working here is the democracy. We have a weekly call with just the Front-End Developers where we talk about all kinds of things front-end related. We also discuss the features, pain points and the roadmap for wd_s. Just scroll through the Github issues and you’ll see the democracy at its finest. Before we forked Underscores, we set a couple of rules:

  1. We would try to stay as current as possible with Underscores.
  2. No versioning, releases, milestones, or tags.
  3. No opinions outside the tools necessary to do our jobs.

Once we forked, we immediately got busy doing cool things with Grunt, like adding support for sprites, javascript concatenation, minification, and SVGs. We added support for Livereload, PostCSS, Bourbon and Neat too.

More Than A Starter Theme

Having all these front-end tools available has it made spinning up a new project efficient . It’s become a teaching tool too. Many of the people here who’ve contributed to it, had never contributed to an open source project before. It’s also become a testing ground for front-end theory. We’re able to play with the latest front-end trends like SVG sprites and PostCSS – and really put these workflows through their paces.

Not every new “trendy” thing ends up staying in the theme, we dropped Font Awesome in favor for SVG icons after clients complain about Font Awesome icons looking terrible at small sizes. Because there’s no versioning (or worry about legacy support), my favorite “feature” of wd_s, is how fast we can adapt and adopt to keep pace with how rapid front-end development moves.

Join Us

wd_s is about eighteen months old and is it perfect? Nope. But it’s also not opinionated either and has just enough rules to allow for agile development. wd_s provides an excellent starting point for developers to spin up a new project. We invite you to fork our starter theme. Kick the tires, poke it with a stick, make a pull request of your own, and join the democracy! We’d love to have you: https://github.com/WebDevStudios/wd_s

The post History of the WebDevStudios Internal Starter Theme: wd_s appeared first on WebDevStudios.com.

Powered by WPeMatico

Posted on

The Future of WebDevStudios Starter Theme: wd_s

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.

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.com.

Powered by WPeMatico