Tuesday, 26 January 2016

Sass: The @import Directive - Vanseo Design

Sass: The @import Directive - Vanseo Design

Sass: The @import Directive

Posted: 26 Jan 2016 05:30 AM PST

One way to writer DRYer code is to separate concerns and keep related code in separate files. This allows you to maintain code in one file as opposed to maintaining the same code over several or many files.

Container Ship

Naturally to be able to keep your code in separate files, you need to be able to combine them all back together. With CSS (and Sass) you can use the @import directive to include the content of one file in another.

For the past two weeks I've talked about @-rules and directives in Sass. Last week I focused on the @media directive. Today and next week I want to talk about @import.

The CSS @import Rule

The @import directive is a CSS @-rule that was briefly popular before falling out of favor due to performance issues. If you've been developing websites for awhile, you may remember using it a number of years ago.

Using CSS' @import you could include stylesheets inside other stylesheets. The included files could either be located on the same server or included with a URL to a directory on another server.

1  2  3  
@import "style.css";    @import "css/style.css";    @import url("http://domain.com/css/styles.css");

While this allowed developers to import CSS files into other CSS files, the practice fell out of favor mainly because of a performance hit in @import, but some other issues as well. Sass removes the performance hit because the @import statements are removed from your Sass code when it compiles to CSS.

The Sass @import Directive

Sass extends the CSS @import rule so that it works with .scss and .sass files. It imports the file referenced and any variables or mixins that are defined in the imported file can be used in the main file.

1  
@import "typography.scss";

Assuming there's a file typography.scss in the current directory, the contents of typography.scss will replace the @import statement.

Sass makes it even simpler. If you forget to include the extension, it will look for a file with the same name and either a .scss or .sass extension.

1  
@import "typography";

The statement above would find either typography.scss or typography.sass in the same directory as the file importing the typography styles.

By default Sass will include the content of the file being imported in place of the @import statement, but there are times when Sass will compile to a CSS @import rule. In other words you'll end up with an @import in the .css file instead of the code in the referenced file. Sass will compile to an @import if:

  • The file's extension is .css
  • The filename begins with http://
  • The filename is a url()
  • The @import has any media queries

Given the previously mentioned issues with the CSS @import rule, you probably don't want this and always want the content in the files to be included directly. As long as none of these four conditions exist the content of the file will be imported.

You aren't limited to a single @import statement. You can use as many as you like. For example importing three different files will import the content of each file in the same order they are referenced.

1  2  3  
@import "typography.scss";    @import "color.scss";    @import "layout.scss";

You don't have to use multiple @import statements to include multiple files. You can import multiple files in a single @import statement.

1  
@import "typography.scss", "color.scss", "layout.scss";

All three files would again be imported in the order listed.

Partials

Sass compiles all the .scss or .sass files inside the directory it's watching. However, when your goal is to import a file, you don't need to compile it directly.

You can tell Sass not to compile a file through the file's name. If you add an underscore to the start of the file name, Sass won't compile it. If you don't want color.scss to compile to .color.css, name the file _color.scss instead. Files named this way are called partials in Sass terminology.

You can skip the underscore when referencing a file inside an @import rule, the same way you can skip the extension.

1  
@import "color";

Sass understands to import the file _color.scss (or _color.sass) from the current directory, if present.

The ability to tell Sass which files to compile and which to only include in other files, allows you to create a file and directory structure that's easier for you to maintain, without ending up with a lot of extra CSS files.

Nested @import Directives

You'll typically include your @import statements at the top of the the importing file, but you can nest @import within other Sass rules similar to the way you can nest @media directives.

Let's say you create a partial named _nav-bkgd.scss that only includes the background color of your navigation items.

1  2  3  
li {      background-color: @ccc;    }

You can import the partial file directly inside the block of code that styles your global navigation, say inside a class named .global-nav.

1  2  3  
.global-nav {      @import "nav-bkgd";    }

Assuming the two files are located in the same folder, the code would compile to:

1  2  3  
.global-nav li {      background-color: @ccc;    }

You can't import everything this way. For example directives like @mixin and @charset, which are allowed only at the base level of a document are not allowed inside a nested @import.

You also can't nest an @import within mixins or control directives, both of which I'll cover in the future. I'll cover mixins later in this series and control directives in a series later in the year.

File and Folder Structure with @imports and Partials

There are a lot of different ways you can organize your files and folders using @import rules and partials to help make your project more maintainable. I'll show you more next week, but let me at least show you one way today. I picked up from an article John Long wrote for The Sass Way.

I used this directory structure when building a small site for a client a few years ago. My .scss directory contained three folders (modules, partials, and vendor), each with one or more files inside. There's also one top level file, main.scss.

  • modules/
    • _color.scss
    • _typography.scss
  • partials/
    • _base.scss
    • _navigation.scss
  • vendor/
    • _ico-moon.scss
  • main.scss

The vendor folder holds any code you get from 3rd parties. In my example there's a file called _ico-moon.scss, which comes from vendor Ico Moon.

The partials folder includes code that will be imported in place into another file and then compiled with the rest of the code in that file. In my partials folder I have some general styles in _base.scss and navigation specific styles in _navigation.scss that I want to import and compile.

Technically the files in all three folders are partials as they all include an underscore, but partials is the name given to this folder in John's structure. Hopefully it's not too confusing. Feel free to change the name of the folder in your project to something else if it is confusing. The main point is these files contain code what will be included into another file and then compiled with that file.

The modules folder includes code that won't be compiled. It includes things like mixins and functions and variables. In my case, the two files _color.scss and _typography.scss both contained variables and nothing else.

A bit off topic, but I used the variable files to quickly show my client variations on the design. Instead of a single _color.scss file, I things like had _color-red.scss, _color-green.scss, _color-blue.scss where the color was the dominant color in the color scheme. It was a quick way to show the design with color variations and type variations.

Speaking of importing files, that's what the main.scss file in the directory does. At the very top of the file are a series of @import statements.

  • @import “modules/color”;
  • @import “modules/typography”;
  • @import “partials/base";
  • @import “partials/navigation";
  • @import “vendor/ico-moon”;

Note that because the files are all technically partials, you don't need to include the underscore or the file extension when referencing the file.

You can easily find more ways to organize your Sass files and folders in a project and I'll show you some next week. Hopefully the simple structure above gets you thinking about a structure that would work for you.

Closing Thoughts

The @import rule is one CSS @rule we've been told not to use for years, but all of its issues go away when you use the extended Sass @import directive.

You can help make your code more maintainable by using @import and breaking down large files into smaller and more focused files that get imported into other files and eventually one top level file that will be compiled into CSS.

There's no one way or right way to set up the structure, though there are some common threads to the different structures people use. Next week I'll show you a few more structures and point you to some resources with more details for how and why they were created.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 20 January 2016

Sass: The @media Directive - Vanseo Design

Sass: The @media Directive - Vanseo Design

Sass: The @media Directive

Posted: 19 Jan 2016 05:30 AM PST

One of the cornerstones of responsive design is the media query. The @media directive provides a mechanism for serving different styles to different devices with different characteristics. Sass both supports and extends the @media rule.

Illustration of a film projector

Last week I began a series about @-rules and directives. I talked about CSS @-rules in general and then walked you through a few Sass specific rules. Today I want to focus on one specific @-rule you likely use in your projects. I want to talk about the @media directive and what Sass adds to the directive.

The @media Directive

The @media directive in Sass works pretty much like the CSS @media rules you already use. Sass adds one very nice feature to the CSS rule, though it's not without some controversy. Sass lets you nest media queries inside the CSS rulesets they modify.

For example the following is permitted in Sass.

1  2  3  4  5  6  7  
.container {     max-width: 95%;     @media screen and (min-width: 30em) {       max-width: 80%;     }  }

If you get annoyed scrolling up and down a stylesheet between a set of rules and the media queries at the end of your document, you'll appreciate nested @media directives. Again the merits of nesting media queries is not without debate and I'll get that in a bit.

First here's how the previous Sass compiles to CSS.

1  2  3  4  5  6  7  8  9  
.container {      max-width: 95%;    }    @media screen and (min-width: 30em) {     .container {       max-width: 80%;     }  }

Notice that the @media rules bubbled up out of the ruleset for .container as CSS doesn't support the nested syntax.

For some people nesting media queries this way helps make their Sass code more readable and ultimately more maintainable.

You can also nest @media rules inside other @media rules.

1  2  3  4  5  6  7  
@media screen {      .container {        @media (min-width: 30em) {          max-width: 80%;        }    }    }

When nesting one @media directive inside another, the queries will be combined using the AND operator when the Sass is compiled to CSS.

1  2  3  4  5  
@media screen and (min-width: 30em) {     .container {       max-width: 80%;     }  }

The media queries (screen and min-width: 30em) have been combined into a single media query that contains them both.

Expressions in @media Directives

In Sass, @media directives can also include expressions like variables, functions, and operations. Since I haven't covered either of the latter two yet, here's an example using variables.

1  2  3  4  5  6  7  8  9  10  
$media: screen;    $width: 30em;    @media #{$media} {      .container {        @media (min-width: $width) {          max-width: 80%;        }    }    }

First I created two variables ($media and $width) and then I used them in place of their values (screen and 30em) inside the @media directives.

Notice that I used variable interpolation, #{}, to include the variable $media, but didn't when I included $width in the nested media query. In the latter case I simply include the variable. Either way is allowed.

The Sass compiles to the same CSS as the previous example.

1  2  3  4  5  
@media screen and (min-width: 30em) {     .container {       max-width: 80%;     }  }

Should You Nest Media Queries?

I've been frustrated more than once by having to scroll up and down a stylesheet to compare properties and values inside and outside media queries, especially when the original selector is near the top of the document and my media queries are at the end.

If you've ever felt the same, you'll probably appreciate that you can nest your media queries and have them bubble up during compile.

However, you should understand the downside to nesting @media rules in Sass. While each @media directive will bubble up, they don't combine, which could potentially leave a lot of repetitive @media directives in your CSS.

For example say you have two containers with different values for their max-widths, but each container changes the value of its width property under the same conditions (min-width: 30em).

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  
.container-1 {     width: 95%;     @media screen and (min-width: 30em) {       width: 80%;     }  }    .container-2 {     width: 90%;     @media screen and (min-width: 30em) {       width: 75%;     }  }

Ideally you'd want the compiled CSS to show a single media query with the rules for both selectors inside a single media query. Perhaps something like this:

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  
.container-1 {      width: 95%;    }    .container-2 {      width: 90%;    }    @media screen and (min-width: 30em) {     .container-1 {       width: 80%;     }     .container {       width: 75%;     }  }

Unfortunately Sass can't currently do that. Instead the Sass above compiles to the following with two separate media queries using the exact same conditions.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  
.container-1 {      width: 95%;    }    @media screen and (min-width: 30em) {     .container-1 {       width: 80%;     }  }    .container-2 {      width: 90%;    }    @media screen and (min-width: 30em) {     .container {       width: 75%;     }  }

For this example the extra bit of code isn't a big deal, but for a real project the duplicate queries add file weight and also make it difficult to see everything that changes inside media queries with the same set of conditions. If you nest them, they'll be spread throughout your document.

I don't think there's an automatic right or wrong answer to the question posed by this section. There are pros and cons to nesting and whether you nest your @media directives or not is up to you.

If you work on larger projects and/or tend to modify everything in a single media query at the same time, you probably don't want to nest your @media rules.

On the other hand if you work on smaller projects and/or tend to modify one component of the design at a time you might prefer to nest your @media rules.

For example I'm more likely to adjust only one component of the design at a time. I find it easier to have all my navigation code, both inside and outside media queries, near each other when working on a site's navigation. I also tend to work on smaller projects. I more likely to nest my @media directives because of both.

In general nesting your @media rules will make your code easier to read, but lead to less DRY CSS after compiling. That may or may not be an issue depending on the specifics of your project.

Closing Thoughts

Sass adds the ability to nest media queries inside the selectors they modify. This can be a good way to keep related code together and you may find it easier to maintain nested @media rules. I generally do.

However, depending on your project and how you prefer to work, you may find the cons of less DRY CSS outweigh the benefits of having styles inside media queries next to the styles they modify.

I don't think there's a right or wrong way when it comes to nesting @media directives and the choice is more personal preference than anything else.

Next week I'll talk about another @-rule that you may have used before, the @import rule. I'll walk you through using the directive in Sass an then show you how you can use @import to organize your file and directory structure so you can write more modular and reusable code.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 13 January 2016

Sass: @-Rules and Directives - Vanseo Design

Sass: @-Rules and Directives - Vanseo Design

Sass: @-Rules and Directives

Posted: 12 Jan 2016 05:30 AM PST

While CSS isn't a programming language, it includes some programming-like features. For example @-rules provide a simple control mechanism for running one block of code instead of another. Sass as you would guess extends these rules and provides a few of its own.

The @-symbol

A few months ago I published a series meant to be an introduction to Sass. The series covered the very basics and discussed topics like nesting and variables. If you missed the previous series or would like a Sass refresher, you can find all the posts below.

This time around I want to focus on @-rules and directives in Sass. Today I'll offer some general thoughts before looking at a few specific @-rules. Over the following weeks I'll talk in more detail about some other directives you're likely to use when working with Sass.

First a quick refresher about @-rules in CSS

CSS @-rules

CSS @-rules are instructions or directives to the CSS parser. One directive you're likely familiar with is @media which provides conditional statements about the size and orientation of the screen among other things. Using @media we can deliver specific sets of styles to different devices.

1  2  3  4  5  6  7  8  9  
body {     font-size: 1em;    }    @media (min-width: 48em) {      body {        font-size: 1.25em;      }  }

Here the font-size of the body depends on the conditions of the @media rule.

In addition to @media, there are a number of other CSS @-rules you might have used or be familiar with. @charset, @font-face, @import, @namespacing, @supports, and @keyframes for example.

Sass supports all CSS @-rules and it adds extra features to some. It also supports a few Sass specific directives that aren't available in CSS alone. Let's look at a few.

The @at-root Directive

The @at-root directive tells the compiler to move nested code to the root of the stylesheet. It allows you to nest rules inside a selector for the purpose of maintenance while Sass movies the code back to the root of the stylesheet when it compiles to CSS.

An example will probably make this clearer. Say you have a 2-column layout with a main content area and a sidebar and both are wrapped with a container div. Your HTML could look like this.

1  2  3  4  
<div class="container">     <div class="main"></div>     <div class="side"></div>    </div>

You wouldn't do this in practice, but for this example let's assume it's easier for you to maintain your code if you decide to nest styles for the .main and .sidebar divs inside the ruleset of the .container div.

1  2  3  4  5  6  7  8  9  10  11  
.container {      width: 100:      .main {        width: 67%;      }      .sidebar {        width: 33%;    }  }

That means on compile your selectors will have an extra level of specificity as in .container .main instead of .main and .container .sidebar instead of .sidebar. You could use the @at-root rule in this scenario.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  
.container {        width: 100:      @at-root {        .main {          width: 67%;        }    }      @at-root {        .sidebar {          width: 33%;      }    }    }

Wrapping an @at-root rule around the .main and .sidebar styles moves both selectors back at the root after compiling to CSS.

1  2  3  4  5  6  7  8  9  10  11  
.container {      width: 100%    }    .main {      width: 67%;    }    .sidebar {      width: 33%;  }

The @at-root directives also works with multiple levels of nesting. Here an h1 selector is nested two levels deep.

1  2  3  4  5  6  7  8  9  10  11  12  13  
.container {      width: 100%;      .main {        width: 67%;        @at-root {          h1 {            width: 100%;          }      }      }  }

When the code compiles the h1 selector will be at the root.

1  2  3  4  5  6  7  8  9  10  11  
.container {      width: 100%;    }    .container .main {      width: 67%;    }    h1 {      width: 100%;    }

Notice that the h1 moved to the root of it's most distant ancestor (.container), not it's nearest one (.main). Since .main doesn't use the @at-root directive it remains nested inside .container.

A single @at-root directive can also contain more than one selector. Here I added a second heading inside the @at-root.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  
.container {      width: 100%;      .main {        width: 67%;        @at-root {          h1 {            width: 100%;          }        h2 {            width: 100%          }      }      }  }

When the Sass is compiled to CSS both the h1 and h2 selectors are moved to the root of the document.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  
.container {      width: 100%;    }    .container .main {      width: 67%;    }    h1 {      width: 100%;    }    h2 {      width: 100%;    }

You may be wondering why you'd want to do any of this and you'd be right to wonder. There probably won't be many times where you want nested Sass to compile to the root of your stylesheet. Keyframe animation is one use case and David Conner offered three more use cases for using @at-root.

  1. Modify an element's use of a class
  2. Escaping @supports for fallback code
  3. Removing specificity for items that will likely get modified while still keeping the organization of nesting

Check the previous link for details and David's examples.

(without: directive-name) and (with: directive-name)

By default anything inside an @at-root directive will bubble up through all its parent selectors. You can also direct @at-root to bubble up outside of nested directives as well. You do this by using (without: directive-name).

Here's an example where the h1 is nested inside both a selector (.container) and a directive (@media).

1  2  3  4  5  6  7  8  9  
@media screen {      .container {        @at-root (without: media) {          h1 {            width: 100%;          }      }      }  }

Here's how the Sass is compiled to CSS.

1  2  3  
.container h1 {      width: 100%;    }

Because the @at-root directives contained (without: media), the h1 bubbled out of the media query. Here's the same Sass after removing (without: media).

1  2  3  4  5  6  7  8  9  
@media screen {      .container {        @at-root {          h1 {            width: 100%;          }      }      }  }

The Sass will compile to:

1  2  3  4  5  
@media screen {      h1 {        width: 100%;      }  }

Without the (without: media) part of the directive, the h1 styles have bubbled out of the .container class, which is its furthest ancestor, but it remains inside the @media directive.

If you want to break out of multiple directives, you can include both directives inside the (without: directive) separated by a space as in:

1  
@at-root (without: media supports)

There's a corresponding (with: directive-name) to list those directives that should be included instead of excluded.

1  
@at-root (with: media supports)

Finally, there are two special values than can be used with either (without: ) or (with : ). The value "rule" (without: rule) is the same as an @at-root without any query. The value "all" (without: all) moves the styles outside of both directives and all ancestor selectors.

The @debug, @warn, and @error Directives

This next group of directives are related to each other as you can probably guess by their names.  The @debug, @warn, and @error directives  can help you correct issues with your Sass code.

@debug prints the value of a SassScript expression to the standard error output stream. For example if you add the following line of code (a color function which I'll cover in a future series) to the top of your .scss file:

1  
@debug darken(#339966,20%);

you'll get back:

1  
Line 1 DEBUG: #1a4d33

In my case the standard error output stream comes through in CodeKit. You might see it in a similar app or your browser. The line number matches the line number where you added the @debug code.

While I used the darken function here, you can use any Sass expression (again, more for the next series).

1  2  
@debug 12em / 3em;    @debug "Sass"+"script";

@warn is similar to @debug in that it prints the value of an expression to the standard error output stream. There are two differences when using @warn.

  1. You can turn warnings off using the –quiet command line option or using the :quiet Sass option.
  2. A stylesheet trace will be printed out along with the message so that the user being warned can see where their styles caused the warning.

Because you can turn off warnings, if you absolutely must see the feedback, you're better off using @error.

@error throws the value of a SassScript expression as a fatal error and includes a trace stack. You would use @error more when working with mixins and functions, but as I haven't covered either in this series yet, I'll hold off on an example.

Unfortunately there's no way currently to catch errors.

Closing Thoughts

Hopefully that wasn't too steep an entry into Sass' @-rules and directives. They're no more difficult to use than CSS @-rules like @media or @font-face.

My guess is you won't use @at-root too much and even @debug, @warn, and @error won't find their way into your code until and unless you start writing more complex @mixins and functions.

Next week I'll take a look at @media and the features Sass adds to what I assume is a familiar directive. In the weeks that follow I'll talk about @import, @extend, and @mixin, all of which I expect you'll use regularly in your Sass.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 6 January 2016

My Goals for 2016 — Reworking My Business Model - Vanseo Design

My Goals for 2016 — Reworking My Business Model - Vanseo Design

My Goals for 2016 — Reworking My Business Model

Posted: 05 Jan 2016 05:30 AM PST

Happy New Year. I hope you've recovered from the weekend and are feeling back into the swing of things. Are you ready for 2016? I know I am. I've been thinking about what I'd like to accomplish this year.

2016 Calendar

Last week I looked back and 2015, specifically the goals I set around this time last year to review my success in completing them. Today it's time to set goals for 2016.

If you've read these posts in years past, you know some years I do better than others when it comes to accomplishing my goals. While I do want to complete all the goals I set, it's not really the point for me. Thinking through what I want to accomplish for the year gives me a direction to follow. It gives me time to think about where my business is and where I want it to go and how I might get there.

If you haven't seen my previous goal setting posts or if you want to look at them again, here they are.

If you want to see if I completed the goals in I set in previous years, check the list of review posts, which I added to last week's post.

Thoughts and Goals for 2016

I thought I would organize my goals into themes again this year, but in a different way than last year. I now have or will soon have three sites to run and I have goals for each of them. I thought the sites would make for good themes and I added a general theme at the end for those goals that don't belong to a only one of the sites.

My overarching goal the last couple of years has been to transition to a different business model. If you look over the list of goals below I think you'll agree the transition is still in progress and involves reworking my two existing sites and launching a third.

  • VanseoDesign.com
    • Create more products
    • Content audit
    • Site improvements
  • Small-Business-Forum.net
    • Relaunch forum
  • StevenBradley.me
    • Launch site
  • General
    • Continue productivity improvements
    • New writing rhythm and more efficient content creation
    • Guest writing and other media

Just like last year I'm setting eight goals within four themes. Let me run through each of the sites and fill you in on what I hope to achieve and then I'll run through the general goals.

VanseoDesign.com

For years the business model for this site has been me selling design and development services to clients. Last year I stopped taking on new clients, though a significant part of my income did come from existing clients. I don't expect this will be the case in 2016 and I'll need more income from other sources.

Create More Products

Naturally if my goal is less services and more products, then I need to create more products. Books are one obvious product. I currently have my CSS Animation book for sale at Amazon and iBooks and wherever ever books are sold and I sell my book Design Fundamentals here.

I expected to have more books written heading into 2016, but unfortunately this was one goal I didn't quite accomplish last year. I do have a book about flexbox close to being ready and I have ideas for more books after.

I'll stay modest this year and set a goal of having at least one more book for sale heading into next year.

Books aren't the only product I can create, though. I'm thinking about how I might add a membership side to this site. I'm trying to decide what would be a fair balance between free and commercial content and I'm thinking through how the whole set up would work. For the most part I know what I want to do, but I have some decisions I still need to make.

I don't expect I'll have anything set up by the end of the year and my goal is more to make progress toward the eventual goal.

Perform a Content Audit

Like I said, I still have some decisions I need to make and I'd like more information before making them. Some of that information will come through a content audit.

I've been writing for this site for about 10 years and there's a lot of content here. I removed a large number of posts when I moved hosts in the summer and there are still more than 700 left.

I want to spend a month or so looking over the content on the site and compiling information about it in a spreadsheet. I want to think about the purpose the content serves on the site and whether or not it could be tweaked to contribute to different purposes.

Site Improvements

Another goal I often set, but don't often accomplish quite the way I intended. A part of me is ready to redesign this site. It's been a few years with the current design in place. The changing business model, changes in technology, changes in my thinking all make me think the time is right for a new design.

I doubt that's achievable given the work I'll be doing for my two other sites. Instead my goal is to make some improvements to the existing site.

There are a few specific things I want to work on, some you might recognize if you've been following along with my goals the last few years. I don't need to do all of these to consider this goal a success, but these are some of the projects that need my attention.

  • Rework the Book(s) section of this site — It needs to be plural, since I've written more than one book and plan to write more. I don't care for the long sales page I have right now. It's not me and I want to rework the page and create a template for what I hope will be more books for sale.

  • Remove the Work section — If I'm not longer offering design and development services, it doesn't make sense to have a section that tries to sell those services. I'll need to rework the About section too and probably tweak a few other pages as well.

  • Fix the Archives page — I know, I've been saying for years it needs to be better organized and I keep putting it off. The server move helped fix some issues and now it's on me to fix the rest.

  • Rework the forum — There's a forum here for anyone who's purchased Design Fundamentals. It's not active at all and that's my fault. I don't think my plans for it were good and I need to rethink if I want to keep it and if so what it should be.

  • Improve navigation to post series — I've done a pretty awful job of making it easy to get from one article in a series to the others. I'd like to change that. One of the things I'd like to learn from the content audit is which posts should have navigation to each other so I can figure out the best way to provide that navigation.

That seems like a lot as I type it out, but I'll do my best.

Small-Business-Forum.net

On and off over the years, I've said I want to do something more with my forum. There are a couple of ads in place that pay my hosting bills, but I've always thought there was more potential with this site. Time has usually been what's kept me from doing anything more with it.

Over the summer I started regular talks with a couple of friends and together we're going to build up a site around the forum using the same business model I want to put in place on this site.

My partners in the business will probably be creating most of the content at first for the site, though I have some specific tasks to complete as well.

Relaunch Forum

The main goal is to launch the site that will become the new home for the forum. We have a domain set up and now it's up to me to design and develop the site.

It will take a significant part of the year for my to accomplish this. All three of us have other responsibilities and we aren't going to rush to get this going. I think we'd all like the relaunch to occur this year, but none of us are expecting it to happen in the next few months.

I want to move the forum from vBulletin to a WordPress/bbPress combination and then we're going to need to test. I'd like the new platform to have as much feature parity as possible for forum members so I'll be searching and setting up plugins. At some point I'll need to design a theme for the site and develop it.

The plan is for my partners to create most of the content we'll need for launch, while I get the site ready.

If you see my forum on WordPress at some point later in the year, you'll know I've completed my part of this goal.

StevenBradley.me

This is my new site about writing, creativity, and productivity. At least it will be once it's launched. At the moment the site is a signup form for a newsletter I'm sending out regularly. Each newsletter contains an original piece of writing by me and I've been sending them out once every three weeks.

Launch Site

My goal is to launch the site and incorporate working on it into my daily and weekly routine. Less time spent on client work will mean more time available to work on this site, though I expect I'll need to do more than just pencil out one and pencil in the other.

There are a couple of major tasks I'll need to complete to launch this site.

One is to write content for the site. Aside from the usual about and contact pages you find on most websites, I want to launch with a number of articles and essays already written. I have ideas for topics and I have notes written for some, but I don't have any ready to be published.

Another task is to finish the design and then develop the site. I have a prototype set up. I'm still working out a couple of things and I've hedged on making a few decisions I need to make. Once the decisions are all made and I've solved the issues I'm still working out, I'll need to turn the prototype into a working WordPress theme and then fill it with the content I've hopefully written.

If sometime during the year I post an announcement here that the new site is ready and live, you'll know I've completed this goal.

General

The goals in this theme will impact everything I do, though they don't specifically belong to any of the three sites. They all deal with either productivity or creativity or some of each.

Continue Productivity Improvements

This is my ongoing goal as I hope to become more productive every year. Last year I switched from using Things as a task management suite of apps to using OmniFocus for the same task and project management.

New software means changes in the way I get things done. I switched apps in part to force myself to rethink how I was organizing projects and tasks as the specific work I do started to change.

I managed to rethink things enough to get by, but I know I can and should make more improvements with the new system. I expect I was as I learn to use OmniFocus better and as I'm forced to make changes when my system bumps up against the limitations of the software.

Find a New Writing Rhythm

It's possible this goal just needs time. There's a limit on how much I can write in a given day or week and I've developed habits and routines to maximize my output.

For most of the last 10 years the majority of my writing has been for this site. Starting this year that will change as I attempt to write regularly for sites other than this one.

It's going to take me some time to figure out how much I can realistically write and how to allocate my time to the different things I want to write.

I think I know how I'm going to have to alter my routines, but altering them takes time and I expect I'll be working all year on developing a new writing rhythm and figuring out how to create content more efficiently.

Guest Writing and Other Media

Since I'm giving up income from design and development services, I need other sources of revenue. Guest writing is one way I can do that and it's something I've done on and off for a few years.

There really is a limit on how much I can write and it's not based on how many available hours I have. I can only write so much in a week so more guest articles likely means less content for myself.

One goal I've listed in the past, but never managed to accomplish is getting better creating video content, specifically screencasts. Often sites that accept guest authors prefer and will pay more for video content and I think it will ultimately prove to be more efficient for me to produce, assuming I ever figure out how to do it in the first place.

My goal isn't to only give other sites video, but rather learn to produce screencasts so I can use some here and sell some to other sites. Overall I think the mix will make me more productive and since my new business model calls for more video it allows me to spend time on one task that serves multiple purposes.

Closing Thoughts

Eight goals over four themes seems doable, though I really don't expect I'll be able to accomplish everything I mentioned. I never have and despite eight and four being the same numbers as last year, this year's goals seem like a lot more work as I'm writing them down.

My overarching goal is to continue to transition my business model and how I make money. Sounds simple enough, but it means changing many things that had become a routine part of my day.

There are obvious concrete steps I need to take to complete the goals I'm setting, but I have a feeling the one that will prove most important, most time consuming, and most difficult to accomplish will be finding a new writing rhythm and creating content more efficiently.

The plans I have for reworking my business hinge on being able to create more content with higher quality. That has less obvious steps and will come down to practice and repetition and some trial and error.

As I do each year I'll ask if you set goals for the year and if so have you found the practice helpful? I do find it helpful to both set goals and review them each year. It keeps me thinking about my business and it creates a guide I can follow when I'm not sure how to spend my time throughout the year.

Happy New Year. May 2016 be a good year for everyone everywhere.

Download a free sample from my book Design Fundamentals.

The post My Goals for 2016 — Reworking My Business Model appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Subscribe to: Posts (Atom)