45royale

Goodnight, 45royale…

Matt Downey — Mon, 16 Dec 2019 18:01:25 +0000

45royale was founded in October of 2005. That’s a lifetime ago in internet years.

In those days, Web 2.0 ruled the land, the first podcast craze was just taking off, and the iPhone was but a twinkle in Steve Jobs’ eye.

We’re probably a little biased, but we feel like we hit the scene during the golden age of the web design. As a fledgling design studio learning the ropes, we achieved success by standing on the shoulders of giants. Zeldman, Cederholm, Bowman, Santa Maria, Shea, Snook, the guys at The Big Noob—all openly sharing what they were learning every day.

A brief history of 45royale

During the first few years of our existence, we were lucky enough to build a quick reputation. We hitched our wagon to quality work, word of mouth referrals, and doing right by people. Business was booming—we could hardly keep up with the opportunities.

In fact, most people don’t know this, but in February of 2009 Facebook approached us about joining their little upstart design organization. After a few interviews, we ended up declining because we had too much work and weren’t in a place to move to California (Adam and I had each bought new homes and were settling down). 10 years later, we shudder to think about how much money we could be swimming in right now. But hey, that’s life.

We aren’t complaining, though. We saw several amazing years filled with impactful projects, smart clients, and incredible growth. However, somewhere around 2014 we noticed the design landscape changing dramatically. For the first time in 45royale’s history, we started worrying about where the next project was coming from. And we weren’t alone—we asked around and a lot of design firms were feeling the crunch, too.

As agencies began to feel the belt tighten, design-forward companies were there to swoop up talent and bring it in-house. Aqui-hiring became the new norm, and a lot of our peers closed up shop.

Truth be told, we had offers landing on our doorstep, too. We flirted with a few big-name companies and even worked inside their organizations for a while on trial runs. But at the end of the day, nothing felt right. All this uncertainty dampened our spirits and we couldn’t help but think about what the future looked like for 45royale.

In 2017 we got really busy again and carried on, but it was too late—the seed had been planted and the rat race had taken its toll. By 2018, it was clear that we were all ready for a change. So at the beginning of 2019, we began the journey to dissolve 45royale.

Saying goodnight

Matt, Adam, and the rest of the team have moved on to other opportunities. However, we’ve decided to leave our site and blog up as a way to pay forward the knowledge we’ve gathered over the last 14 years.

We’d just like to say thank you to the generous and selfless web design community that’s helped us mature and master our skillset. Thank you to our clients who kept this crazy dream alive for almost 14 years.

But most of all, thank you to the incredible designers, developers, administrators, and mentors that made 45royale the amazing, remote-first company it became. Without you, none of this would have been possible.

Gift Guide for Creatives

Matt Downey — Fri, 23 Nov 2018 04:20:51 +0000

This year we put together some of our favorite items we either use on a daily basis or have on our own wish list. Grab something for yourself or a special creative in your life!

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer ut quam ac tortor dignissim euismod et sed felis. Aenean posuere id magna quis placerat. Ut turpis magna, aliquet eu cursus eu, hendrerit vel dolor. Curabitur malesuada sagittis egestas. Praesent elementum lectus vel euismod aliquam. Sed interdum ac tortor a gravida. Nam eu bibendum ligula. Fusce dui mi, consequat ac metus sed, lacinia efficitur ipsum. In ut risus malesuada, varius dui non, mollis est. Ut vehicula sed quam quis pulvinar. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Etiam congue venenatis laoreet. Duis hendrerit, quam quis faucibus consectetur, quam odio pharetra purus, vitae mollis ligula felis vel neque. Aenean sit amet dolor vitae ante ullamcorper vulputate.

Nunc ut tortor ligula. Integer molestie neque ac orci vestibulum pulvinar. Praesent sit amet diam luctus, malesuada leo ut, tempus ex. Duis nulla nisi, sagittis ac luctus vel, pharetra vitae leo. Nullam quis mauris ac turpis venenatis pharetra vitae eu libero. Etiam eget tortor non quam blandit luctus. Proin porta consequat mi, non consequat arcu. Nulla nulla nunc, maximus ac ultrices in, vehicula a nisi. Aliquam eu euismod lacus, eget blandit nulla. Cras dapibus libero quis nisl interdum, non ultrices nibh aliquet. Morbi tempus fringilla est nec scelerisque. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Vestibulum ut imperdiet nisl, in tempus tortor. Curabitur porttitor nisl nunc, sit amet sollicitudin dui rhoncus ut. Nunc iaculis sem ac nunc vestibulum molestie. Morbi tincidunt dignissim sem sed ornare. Etiam bibendum enim nulla, vel ullamcorper eros ornare et. Aliquam erat volutpat. Etiam malesuada lectus ipsum, eget porttitor eros pulvinar ut. Sed nec tortor nec nisi dignissim rutrum eu ut dolor. Aliquam id libero id ex fermentum mollis. Quisque ullamcorper est ipsum, quis pellentesque leo blandit vel. Donec quis fringilla neque. Morbi malesuada faucibus enim bibendum ornare. Vestibulum venenatis imperdiet dui in pretium. Mauris ultricies enim nec faucibus porttitor. Sed fermentum porttitor ligula ut hendrerit.

Nulla eros velit, congue quis cursus quis, finibus eu velit. Morbi feugiat accumsan efficitur. Vivamus rhoncus magna ut blandit posuere. Nam quis eleifend leo. Etiam a euismod urna, ut luctus purus. Nulla vehicula est eu tempor vestibulum. Duis viverra felis ac maximus laoreet. Proin eu placerat ante.

Vivamus hendrerit risus velit. Vestibulum dolor elit, facilisis et enim sit amet, pellentesque pharetra metus. Sed eu dapibus leo. Mauris nec sem at dui venenatis viverra a vel nisl. Praesent massa mi, venenatis a enim ut, iaculis mattis erat. Donec diam dui, pulvinar id tincidunt pulvinar, tincidunt et risus. Sed aliquam eros sodales pretium interdum. Integer eget mi vel mi vulputate porttitor at tristique tortor. Mauris sapien augue, euismod ac sodales at, pharetra ut erat. Praesent suscipit ante vel vestibulum lobortis. Cras rutrum consectetur augue ac feugiat.

Thanksgiving Poster Giveaway

Matt Downey — Mon, 19 Nov 2018 20:35:09 +0000

It’s almost Turkey Day here in the U.S. and you know what that means—it’s time for our 2nd Annual Thanksgiving Day Poster Giveaway™!

And this Thanksgiving, we’re celebrating you, our amazing 45royale community. We’re super thankful that you guys choose to hang out with us, learn with us, and share with us. It’s been such a fun year and we are incredibly grateful that you’ve joined us along the way.

As a token of our appreciation, we’ll be giving away the incredible “Grand Canyon National Park” poster by the good folks at DKNG. This 18″ x 24″ color screen print is set on 100lb. French Construction Pure White cover stock and is absolutely gorgeous.

Want a chance to win this beaut?

It’s easy. Simply leave a comment on this article telling us what you’re thankful for. It can be anything—your family, your job, the Bitcoin you cashed out just before it tanked. Literally anything. Just be sure to leave us a way to contact you in case you win!

We’ll accept comments until Friday, November 23rd at 11:59pm ET. On Monday, November 26th will pick a random winner from the comments and get in touch.

For those of you in the States, we hope you have an amazing Thanksgiving surrounded by good food and even better people. Take care and good luck!

Update: And the winner is…

Congratulations Phillip, you’re the lucky winner! We’ll be in touch soon to get details on where to ship the poster. A big thank you to all that entered, we’ll do it again soon!

How to craft the perfect web developer portfolio

Matt Downey — Wed, 03 Oct 2018 20:06:50 +0000

Earlier this week, we were asked what we look for in a web developer portfolio.

And as luck would have it, we have quite a few thoughts on the matter. We’ve worked with a lot of front-end developers over the years. In that time we’ve come to know what good development portfolios look like.

So this week we took some time to jot down our ideas and thought we’d present them here as part of our Ask45 series. By the way, if you’re new to the series and want to catch up, check out Part 1 and Part 2.

For this article, we’ve broken things down into three sections: The design, the information, and what we find lacking in most portfolios. We’ll start with the hardest part of the portfolio for many front-end web developers.

Designing a web developer portfolio

We understand, most web developers aren’t designers. But that doesn’t mean you get a pass—your site still needs to look good.

Luckily, there are things you can do to ensure your site looks well-designed and considered. Basic design principles can go a long way. Pay attention to details like white spacing, typography, information hierarchy, and calls to action. These simple tactics will organize and elevate your site while drawing people in.

Pay attention to details like white spacing, typography, information hierarchy, and calls to action.

Also, make sure there is a sense of personality and creativity to your portfolio. Don’t be afraid to let people see who you really are. Use a friendly and down-to-earth tone throughout to give people the sense that they’re having a conversation with you.

Finally, we’ve noticed that many web developers go overboard with animations and the latest design gimmicks. We get it, you’re good at CSS. But don’t fall into this trap. As with most things in life, especially animations, less is more. Show good taste and restraint; the animations should enhance the design, not be the main event.

What we’d like to see in your developer portfolio

Knowing what to feature in their portfolio is another roadblock for web developers. What you include could vary depending on your experience and level of project documentation, but here a few things we look for:

Show big brands first

Big brands spend millions per year developing recognition. If you have worked with a big brand, leverage their familiarity and put them front and center. Even if it’s subconscious, showing a bigger brand can help raise the perceived quality of your work.

Case studies

These can be difficult to put together, but a detailed case study is a great indicator of project outcomes. Referencing the client and showing screenshots are not enough. You’ll want to write about your process, your contributions, technologies used, obstacles overcome, and specific deliverables.

You’ll also want to share real data and results when possible. If we see, “I helped Microsoft increase their page load speed by 10x and reduced errors by 25%”, we’re instantly intrigued. Metrics hold weight, make sure you’re keeping track of them along the way.

Show that you take code seriously

It’s important for someone reviewing your portfolio to know that you take pride in your craft. Code examples are sometimes hard to actualize, but links to your Codepen or Github can be beneficial. Not only is your code on display, but it also shows that you’re part of a larger community and you contribute to the cause.

You may also want to consider blogging about your craft. Writing articles about web development and offering solutions to problems on a daily basis can be powerful. It doesn’t hurt to flex your development muscles and remind potential clients that you’re a subject matter expert.

A word of caution about blogging though: If you can’t commit to it, it might be better to put your time elsewhere. An inactive or outdated blog can be worse than having no blog at all.

Common shortcomings in many web developer portfolios

We’ve seen a lot of development portfolios and have some suggestions to help fill the gaps. First and foremost, focus on your communication, speed, and reliability.

Communication is key

When it comes to working with developers, it’s not always about who’s got the cleanest code. You’re still hired to be part of a team working towards a common goal. Showing that you can communicate and deliver assets on time is more than half the battle. Building trust with potential clients or project partners will help you immensely.

Having thoughtful testimonials will put potential clients at ease and help reiterate your value.

Build trust with social proof

Trust can be hard to convey online, so why not let others do it for you? Include testimonials from former clients to help tell your story. Having thoughtful social proof of your skillset will put your potential client at ease and help reiterate your value.

Paint a picture of what it’s like to work with you

You might also consider showing your potential client what it’s like to work with you. Share details of your up-front requirements. Let them know that you have a dedicated Slack channel for weekly check-ins and a GitHub page to track development progress. Reassure that when the project nears the end you’ll help them with the launch and code/asset transfer.

Even though every project is different, this will give the client peace of mind knowing that there is a process in place.

Bringing it all together

We hope we shed some light on a few points of emphasis we look for when hiring web developers. Take some or all of these suggestions and apply them to your site—we think you’ll see great results.

If you have any questions, please feel free to leave us a comment below. Even better, if you put this article to good use, leave a link to your site below so we can check it out.

Our web design process: A blueprint for successful projects

Matt Downey — Thu, 27 Sep 2018 21:47:55 +0000

We’ve been designing and building sites and applications for over twelve years. In that time, we’ve learned a lot about clients, projects, and how to implement a successful web design process.

And if you’re a regular reader of our blog, you’ll know that we’re big on sharing that knowledge. We’ve written about all sorts of topics. WordPress, Github, CSS, copywriting, version control, mobile design—the list goes on and on. You name it, we’ve probably touched on it in one way or another.

It’s in that spirit that we’ve put together a five part series about our web design process. Some of the topics covered in this series will be a simple refresher for day-to-day Project/Product Managers. But for those just getting started in the industry or struggling to manage projects effectively, you should find value here. Let’s take a look at what we’ll cover.

A project-centric approach to the web design process

We start at the beginning of the web design process, showing you how to get clients and maintain relationships. We’ll then move on to best practices for contracts and schedules. The final article will cover topics that tend to make a lot of people uncomfortable. Specifically we’ll take a look at how to tell if a project isn’t going well and what red flags to look for when thinking about moving on from a project.

Here’s a look at each of the the articles in the series, as well as a brief synopsis of what we cover in each:

How to get web design clients
In Part 1, we start the series by addressing the issue of getting clients. We’ll walk you through our method for finding new business, initial conversations, and what to keep an eye on when evaluating a new client relationship.

Are web design contracts necessary?
Part 2 is all about the business of web design. Dealing with contracts is probably the least exciting part of a project, but one of the most important to ensure a successful outcome.

Project schedules: How to set expectations and ensure success
Part 3 is all about developing and maintaining a realistic project schedule—the single most important function of successful web design projects.

Time tracking leads to smoother projects and proposals
In Part 4, we talk about why time tracking is crucial. When you know how long things take, you and your team are equipped to make smarter decisions for your company.

When a web design project goes wrong…
Unfortunately, sometimes even the best laid plans go awry. In the final article of the series, we help you decide if you should move on from a web design project.

We hope this sheds some light on our process

It’s our intention to put you on a successful path towards project amazingness. If you have any questions or would like any more information on any of the topics above, please don’t hesitate to leave us a comment. Good luck, here’s to a ton of happy, productive, and successful web design projects!

Set up a modern web development environment

Matt Downey — Fri, 21 Sep 2018 02:46:21 +0000

Web development in 2021 can be a bit overwhelming. There are so many new tools and techniques that it’s easy to experience paralysis by analysis.

If you’ve been struggling to put the pieces of the puzzle together, we hope that this article will help. We’ll cover the web development tools we use here at 45royale to build client projects locally before pushing them out to the world.

Two notes before we begin:

1. The environmental set up outlined below can handle anything from custom web applications to WordPress sites. The latter will be our focus in this article, but if your project requires a server and/or database, this set up will still work.

2. We aim to make this article a step-by-step guide you can follow along with. We’ve included a lot of images for reference, hoping to make your pathway more clear. If for any reason you feel that something doesn’t make sense or could be more clear, please reach out in the comments. We’d be happy to include more detail where we can. Onward!

Getting started with your web development environment

The first thing we need to do is to get familiar with Local by Flywheel.

Local makes building WordPress sites super easy. It’s a free tool that Flywheel has created to quickly and easily set up WordPress environments on your own computer.

We’ve used MAMP for many years, but with Local, it’s dead simple to get a site up and running. With options for one-click WordPress installation and flexible environment options (we’ll see that in a minute), it couldn’t be easier to jump right in.

Install Local by Flywheel

First, head on over to Flywheel’s website and download Local. Once you install and open the app, Local will walk you through the steps to set up your first WordPress site.

Local will configure your VirtualBox and Host Machine for you, just sit back and let it do its thing. Once it’s done, it will show you a blank dashboard where your projects will show up once they’re created.

Go ahead and click “Create a new site”.

Local will then prompt you to fill out information about your new site. In this example, I’ve named mine MDv2 and given my local site a domain of [html]mdv2.local[/html]. You can select other URL patterns, but I like using [html].local[/html]. Double-check the site path and make sure “Don’t use a Blueprint” is active. Click “Continue” to move on to the next step.

Next, Local will ask you to select your environment. For most people, the “Preferred” tab is what you’ll need. However, you can customize your settings to match your needs.

For example, you can change your versions of PHP and/or MySQL if your project has specific needs. For our purposes though, we’ll go with the “Preferred” environment. Click “Continue” to move to WordPress Setup.

Here you’ll enter your credentials for your WordPress installation. Enter the username, password, and email address you’ll want to use on your local WordPress site.

Under the Advanced Options you have the ability to select if your WordPress install will be a Subdirectory or Subdomain multisite. For most people, you won’t need to select these. But in case you do, you can adjust those settings here.

We won’t need any of the advanced options so let’s move forward by clicking “Add Site”.

Local will now gather all the settings you input and prepare your environment. This includes building the databases, getting the servers up and running, downloading WordPress, and more. In a matter of seconds you’ll be up and running with a WordPress site.

When Local has finished, you’ll see your site appear on the dashboard. It shows your local environment specifics, a button to “View Site”, and more.

One thing to point out here that some people miss: Have a look at the “Live Link” button at the bottom. If you enable Live Link on your site, you’ll be able to send a link of your local site to a friend or client and they’ll be able to see your progress along the way.

No uploading to a server, no configuring a domain. Simply share the link with them and they’ll be able to see your site along with you in real-time. It’s magic.

So now you’re set up with Local and you have your WordPress site ready to go. Let’s move on to the next step which is getting a theme installed on your site.

Underscores: The best starter theme we’ve found for WordPress web development

Before you start diving into your site, it’s important to take a step back and set yourself up for success.

If you’re building a custom WordPress site from scratch based on a design you or a designer came up with, you’re going to want to start with a blank slate. That’s where Underscores.me comes in.

Built and maintained by the folks at Automattic (the people behind WordPress), Underscores is one of the best themes you can start out with. With “ultra-minimal CSS” you’ll find far less bloat than you would on other “starter” themes.

But the best part about the Underscores theme is that it gives you proper, well-commented WordPress page templates to start with. It’s literally the best theme we’ve found to start custom projects, we think you’ll love it.

Installing Underscores

Head on over to the underscores.me home page and start creating your theme. If you’re in a hurry, simply input your theme name into the input field and hit “Generate”.

However, we recommend filling in some of the advanced options so that we have a more complete theme. At a minimum, we fill in the options in the screenshot above.

After you click “Generate”, Underscores will package your theme and download it to your computer. Once you unzip your new theme (ours is called mdv2), add it to your WordPress site by moving it into the [themes] folder at [html]Local Sites ➝ app ➝ public ➝ wp-content ➝ themes[/html]. Next, you’ll want to activate the theme.

Activating your new WordPress theme

Now that your new theme is in your [themes] folder, let’s jump into WordPress and activate it.

Point your browser at your newly created site (our example lives at mdv2.local). Use the same login credentials you input during the Local installation to get into the Admin panel.

Go to the “Appearance” tab in the left sidebar and select “Themes”. You should see your new theme there (ours is mdv2). Click “Activate”.

Go back to your site and you’ll see that the default WordPress theme is gone and a standard, un-styled theme has taken its place. We now have a fresh start for our design styles.

So far, so good? Well, buckle in, because we’re about to get to take things up a notch. This part of the article can get a little complex, so take it slow and we’ll walk you through it.

Codekit: Build websites faster and better

Codekit can do many things, but it’s probably most well known for it’s compiling, pre-processing, minification, and image optimization. All the things you want in your modern site build to keep file sizes and server requests to a minimum.

Codekit is a life-saver, a time-saver, and a sanity-saver. Yes, it costs $34, but it’s worth every penny.

With incredible support and documentation, we’re sure that Codekit will change the way you build sites.

But wait, before we get started with Codekit…

Because Codekit has built-in compiling, we need to add two folders to the WordPress theme we just activated: a Source folder and a Build folder.

The Source folder is where we’ll add our images, Javascript, and Sass files. We’ll actively work on those files for our theme, and as we save them, they’ll be copied over to our Build folder already compiled and minified. It’s important to remember that you’ll never edit any of the files in the Build folder, only in the Source folder.

…ok, now we can install Codekit

Once you’ve downloaded, installed, and opened Codekit, you’ll see a blank dashboard. Click on the “Add a project”.

From here, you’ll want to hunt down your theme folder. Once you find it, click “Add” and Codekit will create a new project for you.

You should see all the files and folders here, including the new Build and Source folders you just made.

The first step after confirming that your theme files are showing up properly is to click the Settings icon on the left-hand side of the page. You’ll see a lot of options appear, click on “Browser Refreshing” first.

To enable automatic browser refreshing on your project, make sure to toggle on “External Server Required” and enter your Local site address in the input field.

Next, click on “Build Settings” underneath “Browser Refreshing” to set up the compiling. Make sure that “This project uses a build folder” is checked, the folder names are correct (they should be by default) and click “Apply Changes”.

Now you’ll want to set up the Sass options. Under “Languages”, select “Sass”. Set the “Output Style” to “Compressed” and make sure “Create a source map” and “Run Autoprefixer” are selected. The autoprefixer will append all browser-specific CSS to your stylesheets, a time-save and a half. Make sure your settings match up to the screenshot’s before moving on.

Now that we have all our settings saved, it’s time to download Bootstrap.

But why Bootstrap?

Bootstrap is, among other things, the most popular HTML, CSS and Javascript library in the world. It is well maintained and updated by a core team of developers on Github. Their goal is to “move the web development community forward by pushing for newer CSS properties, fewer dependencies, and new technologies across more modern browsers”.

Besides being very popular, Bootstrap also shines a spotlight on being a responsive, mobile-first framework. Out of the box, Bootstrap makes your site look great across several device types—saving you tons of time and money.

Convinced? Ok, let’s install Bootstrap

Click on the cloud icon in the sidebar to see all the packages available in the Codekit library. Do a search for “bootstrap” and install the latest version (as of this writing, that’s 4.5).

Once Codekit finishes installing Bootstrap, you’ll see a new folder in your theme directory called [html]bower_components[/html]. This is where Bootstrap lives. We’re now ready to move on to the next steps of adding and configuring Bootstrap for our WordPress theme.

Before we configure Bootstrap, read this…

Before we go further, it’s important to note that you don’t want to edit any of the files or folders inside the [html]bower_components[/html] folder.

Why you ask? The most important reason is that when a new version of Bootstrap is released, you’ll likely want to upgrade. And if you’ve edited those files to customize your site, all of those edits will be blown away when you upgrade. That’s no good.

So now you may be asking, “Ok, then how will we customize our version of Bootstrap for our new site?” Good question, and it’s simple really. We’ll copy the code from a few Bootstrap files and put it inside our Source folder to edit and customize without overwriting the source Bootstrap files. Easy as pie.

Configuring your site to use Bootstrap

Remember when we added the Source and Build folders to our WordPress theme folder above? Well, now we’ll want to flesh these out a bit further.

First, in the [html]Sass[/html] folder, create a new file called [html]styles.scss[/html].

Also in the [html]Sass[/html] folder, create a sub-folder called [html]variables[/html]. Inside of the [html]variables[/html] folder, create a new file called [html]_bootstrap.scss[/html].

We’ll need both of these files in the following steps.

In your text editor, go to your theme directory and go to [html]bower_components ➝ bootstrap ➝ scss ➝ bootstrap.scss[/html].

Copy everything underneath the commented section (all of the [html]@import[/html] code) and paste it in to your newly created [html]styles.scss[/html] file inside the [html]sass[/html] directory.

Next, go to [html]bower_components ➝ bootstrap ➝ scss ➝ _variables.scss[/html]. Copy all of these styles and paste them in to the [html]_bootstrap.scss[/html] file inside the newly created [html]variables[/html] folder in the [html]sass[/html] folder.

Now we’re ready to start editing our Bootstrap files without overwriting the core framework files in the [html]bower_components[/html] folder. Boom!

One thing to note here as an aside from the incredible Bootstrap documentation: “Every Sass variable in Bootstrap 4 includes the [html]!default[/html] flag allowing you to override the variable’s default value in your own Sass without modifying Bootstrap’s source code. Copy and paste variables as needed, modify their values, and remove the [html]!default[/html] flag. If a variable has already been assigned, then it won’t be re-assigned by the default values in Bootstrap.”

Setting up your stylesheet foundation

In the screenshot above, you’ll notice that the code looks a lot different than it did in the [html]bootstrap.scss[/html] file we just copied over. That’s because I’ve made some edits which I’ll explain in more detail below.

The first line references the [html]functions.scss[/html] file inside of the core Bootstrap folder. This is imported first so that all the other Bootstrap styles and mixins can run smoothly.

The second line references our custom Bootstrap file we just copied over from the core Bootstrap folder and put in the [html]variables[/html] folder.

After that, we [html]@import[/html] all of the other Bootstrap styles and dependencies we’ll need on our project. These include mixins, root, reboot, type, images, code, and grid.

Below those you’ll notice that we still have a TON more styles we could import from our Bootstrap core framework. We’ll only add them as needed so we don’t overload the server with requests.

Adding additional styles

After we have our basic [html]styles.scss[/html] file set up, we can start building upon it.

In the screenshot above, you’ll notice that I have added some new style declarations in the form of [html]@import[/html]. I’ve created a [html]blocks[/html] folder for general layout CSS, a [html]pages[/html] folder for page-specific CSS, and a [html]_general.scss[/html] file for global styles. I [html]@import[/html] them all below the Bootstrap styles so the fall beneath them in the cascade and override any unwanted/unneeded styles.

A couple of odds and ends you need to do to get your stylesheets up and running

1. Delete your theme’s default styles

Go into the theme’s [html]style.css[/html] file and delete everything but the comments. This will remove all the default styles from the Underscores theme and replace them with Bootstrap’s default styles.

2. Set up your Sass stylesheet to compile to the build folder

In order for your site to use your custom styles, you need to tell Codekit how to compile your stylesheet.

In Codekit, click on your [html]styles.scss[/html]. On the right, under “Output” make sure when the file changes it’s set to “Compile It”. Set the path to [html]build/css/style.css[/html]. That folder probably won’t exist yet, but you can add it during this process. Once you set the output path, click “Compile” and you should have your first stylesheet compiled.

3. Enqueue your new stylesheet

Before your new styles will show up on your theme, you need to tell WordPress where they live. Open up [html]functions.php[/html] inside of your theme folder and find the line that says “Enqueue scripts and styles”.

Update the path for the stylesheet to the following, noting that you’ll need to replace [html]mdv2[/html] with your theme name:

[php]
wp_enqueue_style( ‘mdv2-style’, get_template_directory_uri() . ‘/build/css/style.css’ );
[/php]

While you’re in there, and if you plan to use Javascript on your site, update the script enqueue as well with the following (remember to change the theme name):

[php]
wp_enqueue_script( ‘mdv2-style’, get_template_directory_uri() . ‘/bower_components/bootstrap/dist/js/bootstrap.min.js’, array(), false, true );
[/php]

Finally, here’s what you should do next…

Setup basic styles

The first thing I like to do after getting my web development environment in order is to update some of the basic styles. Setting up things like typography, grids and grid-columns, and gutter-width will give you a good foundation for your build.

Setup your hosting

The second thing I do is get my hosting setup. I’ve tried several hosts over the years, including Digital Ocean and Bluehost. But recently, I’ve found Kinsta and have been over the moon with the performance and service.

Kinsta is managed WordPress hosting built on Google’s Cloud Servers, so they’re incredibly fast and efficient. I urge you to give them a try—plans start at just $30/month.

Ask a question

If something is unclear or you’re confused, please don’t hesitate to leave us a comment below. This is a lot of info to document and explain, so any insight you can give us to make this article better is appreciated! We hope this helps and can’t wait to hear from you.

Build automation and deployments with Buddy

Adam Little — Thu, 13 Sep 2018 20:37:10 +0000

Whether building a product from scratch or doing a simple redesign, it’s important that our development work happens in the background.

Why in the background? For many reasons. The first that comes to mind is so we don’t show our work to the world while it’s still in progress. Another, and far more worrisome, is so we don’t impact anything on the client’s live Production site.

A simple way to get around some of that is by doing development work in a local environment. But many times the client needs to be able to see the progress that’s being made for their own eyes. Or may need to start adding content for the site or application on their own. They can’t do that if you’ve got everything locally.

To address all these issues, we use a web accessible Staging environment for every project. And because our local environments are in sync with Staging, we can show our work to the client without the fear of having anything we do (or they might do) impact a live site.

Improving our workflow with build automation tools

We’re a small remote team. As such, everyone pitches in during a project build. That’s why we prefer our designers and developers to have a more “hybrid” skillset. Designers should be able to code and developers should be familiar with design tools like Sketch.

A designer waiting on a developer to update a client’s site leads to an unnecessary bottleneck.

But while having hybrids on our team is great, there is an inevitable tipping point. There are times in a project when one of our designers can find themselves in feeling a lack of confidence. Handling build compiles or accessing a server’s command line, comes to mind. This can lead to a bottleneck.

For example, the client might need a small change that is simple for a designer to make locally. However, pulling those changes on to a staging server so the client could see them would require us to wait on a developer to run the commands.

We tried various automated deployment solutions in the past with varying degrees of success. In the end we found ourselves reverting back to doing things by hand. It was tedious, but more reliable.

As we got busier though, this became less of an option because the bottleneck kept getting worse. Designers were waiting on developers. Developers were being interrupted with small frequent changes. Nobody was happy.

What we needed was a reliable build automation solution that integrated with the way we work.

Enter Buddy, a build automation app that makes our lives a lot easier

At the start of a project last year, one of our developers mentioned that he wanted to try this new app called Buddy. He had used it on a personal project and found that it was a great way to push code to a server.

At its core, Buddy allows you to run your apps in disposable sandbox environments and automates cloud and server deployments with ease.

Buddy’s deployment pipelines were exactly what we had been looking for. Not to mention it’s easy to use and well designed interface was perfect for our less technical team members.

The app allows you to create a project that can be filled with multiple pipelines. Which for us, is mainly a Staging pipeline and Production pipeline.

Add a new pipeline

Buddy integrates with our GitHub account and allows us to create a pipeline that ties in with a particular branch in a given repository. It has options to 1) trigger the pipeline with manual execution, 2) listen for a push, or 3) run recurrently (ex. every night at 6pm for example).

Within each pipeline you configure actions that you want to run once it’s triggered. There are endless options including transferring data to a server, running commands, executing scripts, building an image, and more.

Add new actions

How we use Buddy

For most of our projects, we configure actions for both our Staging and Production servers. For Staging we have Buddy listen for a push on our Staging branch. Then it automatically connects to our server with the proper credentials and executes a [html]git pull[/html] to transfer the latest build.

We always make sure that someone is watching and ready to act in the event of an issue.

Production is set up in almost the same way, but since Production is typically more sensitive, we set the trigger to manual. That way someone has to go in and manually trigger the pipeline when we launch or have significant updates to make. We always make sure that someone is watching and ready to act in the event of an issue.

Another great part about Buddy is that it supports over 30 integrations. They have an API that allows them to integrate with services including GitHub, Slack, Shopify, and S3 just to name a few.

Since we find ourselves in Slack quite a bit, we’ve integrated Buddy so that we can run production deployments for 45royale.com right from there. Once we have a discussion in our [html]#development[/html] Slack channel that our Staging changes are approved, one of our admins types [html]’deploy /run'[/html] which triggers the Buddy Production pipeline of our master branch. And just like that our changes are live on Production!

Run the pipeline

We’ve been super happy with our improved build automation workflow. In fact, we’re constantly finding new ways to make things more efficient with Buddy.

If you’re not sure how Buddy would fit in to your workflow and environment, I’d suggest browsing through the Guides on their website. They have a great collection of articles that help you through various services and workflows that make using Buddy so powerful.

Have you used Buddy before? If not, what tools do you use to eliminate bottlenecks in your workflow? We’d love to hear more about your experience and/or thoughts in the comments below!

Using CSS Scroll Snap for images and content

Matt Downey — Thu, 06 Sep 2018 22:08:38 +0000

Google Chrome turned 10 this week and the internet is abuzz about the browser’s new look.

And rightly so—the design is by far the most notable change for the majority of people using Chrome on a daily basis. The team at Google has updated the look of the browser and unified branding across all platforms including desktop, Android, and iOS.

But amidst all the hullabaloo around the new look and features, there’s something new that you may have missed in the update. Google Chrome 69 now supports the CSS property [html]scroll-snap-type[/html].

CSS Scroll Snap? What the heck is that?

From the MDN web docs, CSS Scroll Snap is “a module of CSS that introduces scroll snap positions, which enforce the scroll positions that a scroll container’s scrollport may end at after a scrolling operation has completed”.

Scroll Snap is a module of CSS that introduces scroll snap positions for content.

With Chrome 69, using the [html]scroll-snap-type[/html] property will allow you to create a better carousel experience on your site. You no longer have to use Javascript to align and find the center of an image inside a carousel window.

And it’s pretty easy to implement, too. It only takes adding a few lines of code to your CSS to achieve this behavior.

Adding Scroll Snap to your CSS

Implementing the [html]scroll-snap-type[/html] property is a breeze. It only takes a few lines of code to achieve the desired behavior.

Simply declare the scroll snap positions by telling the browser where to stop after each scrolling operation and the content will land there perfectly.

Here’s an example of an image carousel with images scrolling and aligning to the center of the container:

[css]
#scroll-container {
scroll-snap-type: x mandatory;
overflow-x: scroll;
display: flex;
}

#scroll-container img {
scroll-snap-align: center;
}
[/css]

Easy, right? And the best part about adding these properties to your carousel is that it will work even if the images are different sizes or are larger than the scroll container. In other words, the container height won’t change, but you’ll still be able to have images/content of varying width. Not too shabby!

To see the Scroll Snap property in action, have a look at the demo Google put together. The top demo uses Javascript on the arrows to control the images, while the bottom demo uses simple vertical scrolling built in to the browser.

Remember that Scroll Snap isn’t available in all browsers… yet.

Of course, the big caveat. Unfortunately we have to mention that Scroll Snap is still considered an experimental CSS property and is not supported by all browsers. You’ll want to hold off using the scroll-snap-type property if your user base or customers use a specific browser not supported.

What are your thoughts on the Scroll Snap property? If you have any questions or comments, we’d love to hear from you below!

WordPress Gutenberg: A beginner’s guide to the new editor

Matt Downey — Thu, 30 Aug 2018 03:49:21 +0000

If you’re in the open-source or web development space, you may have heard about WordPress Gutenberg by now.

Gutenberg is the name of the new content editor for WordPress that will become the defacto standard for building out pages and posts. It’s a massive shift in how we interact with the platform and, ultimately, how we’ll build WordPress sites.

Over the past several months we’ve talked to some of our clients and were surprised to know that they knew nothing about this holistic change to the software. As such, we decided to put together this beginner’s guide to the Gutenberg editor that will be coming down the line later this year in WordPress 5.0.

So what is WordPress Gutenberg?

In its simplest form, Gutenberg is the evolution of the WordPress editor. The final product will come standard as a part of WordPress 5.0 core, set to release sometime in 2018. The actual release date is unknown, but seeing as we’re at version 4.9.8 at the time of this writing, we should be seeing it soon.

Gutenberg will replace the Classic editor and will be built on Github using the WordPress REST API, Javascript, and React. These technologies will make adding media rich content to posts and pages a breeze.

This transition will also help to solidify WordPress as a modern content platform on par or ahead of other Content Management Systems and blogging platforms like Medium.

The editor will endeavor to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take short codes, custom HTML, or “mystery meat” embed discovery.

— Matt Mullenweg, Founder of WordPress

But all this means nothing if we can’t experience these new changes for ourselves first hand, right? Well, you’re in luck. WordPress has made it available as a plugin so we can start kicking the tires. Onward!

Installing WordPress Gutenberg

You can download Gutenberg directly from the WordPress repository on Github, or install it from the Add Plugins tab in the Admin section of your site.

WordPress Gutenberg via Add Plugins menu

Keep in mind that you will need to be on WordPress 4.8 or later in order for Gutenberg to run on your site.

Now that we’re up and running, let’s have a look at what we can do with Gutenberg.

A first-hand look at Blocks in Gutenberg

Right off the bat you’ll notice that the new editor looks and feels much different than what we’re used to. More whitespace for writing, a cleaner document sidebar, and a new section in the sidebar called Block.

The Gutenberg demo post

In the new editor, everything is a block. Text, images, widgets, galleries, custom HTML chunks… everything.

Since content is broken down into sections, you can easily insert, rearrange, and style your posts at will. The editor will even group your blocks by frequency of use to ensure the blocks you use the most are available when you need them.

Developers will love Blocks, too

But blocks don’t just make it easier for bloggers and site owners to maintain their sites. No sir. Blocks also make it easy for WordPress developers (like ourselves) to provide clients with unique, theme-specific content.

A custom block created by Organic Themes

In simpler terms, this means that we can develop a unique section or layout that can be directly edited by a client within the editor without them touching a line of code. They’ll have a beautiful WYSIWYG experience with less chance of ruining the markup, layout, or look and feel of the site. For developers (and clients), this is huge.

These types of customization are but scratching the surface. With the new editor, you can create tons of custom block types for your client’s specific needs. If you want more information about where to begin, WordPress offers a set of block design do’s, don’ts, and examples. It’s a good place to dive in to this kind of thing.

Is the new Gutenberg editor right for you?

The new block capabilities are remarkable and greatly extend the core features of WordPress. We think our clients will see a lot of value in the upgrade to the new editor. But to be clear: Yes, Gutenberg will be the default editor shipped with WordPress 5.0 sometime this year. But no, you don’t have to use it.

If you’re not great with change or run in to issues with existing content on your site, WordPress will give you the option to install the Classic editor (presumably as a plugin) so that you can continue to use WordPress like before. This makes some people feel better knowing there’s a fall back in place in case they decide the new editor’s not right for them.

So since we’re talking about who this new editor is for, let’s take a high level look at some of the pros and cons of Gutenberg to figure out if it’s right for you.

Gutenberg pros:

It brings WordPress in to the modern world with a better writing platform.
There is more focus is on crafting your content and less with fussing with the editor.
Custom blocks (as we mentioned above) will be game changers for developers such as ourselves. Giving clients flexibility to add their own content inside a unique layout without them breaking the site is priceless.

Gutenberg cons:

Initially you could see compatibility issues with plugins and themes. Sometimes developers drag their feet with updates and fall short of updating their products for major releases. If you have a site-dependent plugin, make sure to check if it’s Gutenberg-compatible early on before upgrading to WordPress 5.0.
Yes you can revert to the Classic editor using a plugin, but Gutenberg’s layout and features are the future of WordPress—it’s not going anywhere. If you’re not comfortable with it, you may find yourself jumping ship to another platform.
There have been rumors that Gutenberg does not live up to accessibility standards. This may be fixed by the time WordPress 5.0 launches, but some people have raised concerns already.

In conclusion

The new Gutenberg editor is ushering in a new look, mindset, and positioning for WordPress. After playing around with the plugin, we’re super impressed with the editor and its functionality. Blocks are an amazing improvement to content layout and will give visual editing a major upgrade. We can’t wait to dive in and see how we can creatively help our clients produce better looking and functioning posts and pages.

Now it’s your turn. Have you tried out Gutenberg? If not, how come? We’d love to hear more about your experience and/or thoughts in the comments below!

Web typography: Define early, design quickly, and set defaults

Matt Downey — Thu, 23 Aug 2018 22:09:50 +0000

There’s no question that web typography has come a long way in recent years.

As browsers have adapted to include embedded fonts, the options for designers seem endless. Web font services like Typekit, Google Fonts, Edge Web Fonts, and more make it easier than ever for designers to express themselves with type.

Add a [html]@font-face[/html] declaration to your CSS or include a snippet of Javascript and you’re off and running.

Web typography is more than picking a good looking font

Finding and using the perfect type face for a project is definitely a major part of the equation. But here’s so much more that goes in to choosing particular styles and weights.

In fact, we are often asked about our approach to setting and defining type in projects. We’re asked about our process, how we deal with modular scale, and things like vertical rhythm. In fact, we recently had a question from one of our 45royale Collective members, J. Glerum about this very topic.

If you’re wondering how to join the 45royale Collective (our private Slack workspace), sign up for our newsletter and we’ll send you an invite!

Originally Adam (our Project Manager) answered his questions in the Slack channel, but I thought it might also be beneficial to expand on his thoughts and share them here.

Question 1:

Do you define fonts and weights early in the process, or do you start laying things out and then pick fonts that “look good”?

Our process usually includes a research and discovery phase where we define fonts and weights before jumping in to layout. We create a style guide for the client, exploring the brand and competitors to find the right type face for the tone we’re matching.

The style guide is almost always the way we begin with type on a project

If we’re working on an internal project or the rare project exploration without a timeline and budget concerns, we tend to explore a bit more. But this is a rarity, and the style guide is almost always the way we begin with type on a project.

Question 2:

Do you define a modular scale early using something like modularscale.com? Do you create separate scales for headings and body copy? Separate scales for mobile and desktop views?

Not typically, but it depends on how much time we’ve alloted for in the research and discovery portion of the project.

If we have a long runway with design comps and have the ability to holistically create a site or app from scratch, then we’ll absolutely set the modular scale for a project.

Even if we don’t have a lot of runway, we try to build our typography scale in to the code base we’re using. If we’re using a framework like Bootstrap 4 (which we used for this site and many others), we adjust our scale at the code level so everything is calculated from a root base. This makes organizing and scaling our site design easy as pie.

Question 3:

Do you set line-heights and margins on your elements (default paragraph size, [html]h1-h4[/html], etc.) to align things to a grid and use vertical rhythm?

Yes, we always set defaults. The way a site feels and how the type is perceived is almost always a result of vertical rhythm. Piggy-backing off of Question 2, a lot of times we set this in extended design phases or more frequently, in the development phase.

I will caveat this by saying that sometimes these scales or rigid values don’t always “seem” right. It could make sense mathematically, but it just doesn’t feel right for the design or layout.

Breaking your pattern, scale, or grid can seem scary. But sometimes you have to buck the system in order get the organic and natural feeling you’re looking for from your typeface. You’ll want to consider the client message if you break pattern though, as this can interrupt or change the tone of the site.

Getting the most out of your web typography

To wrap things up, there are so many tools available on the modern web that it should make the designer’s job much easier.

Where designers need to focus is not on the tools themselves, but on the principles and fundamentals of setting and defining type on a project. Having the ability to embed a font doesn’t mean you’ve chose the correct style for the message, tone, and conversation your client wants to portray. With great power, comes great responsibility.

We’d love to hear your thoughts on web typography and for you to share some of your best practices. Leave a comment below and let’s keep the discussion going.