Blogging Workflow: Moving Editorial Calendar to Lists

When Lists launched as part of Microsoft 365 this past summer, one of the built-in templates included with it was a Content Scheduler. This template was the most interesting to me because, like I identify in my Website Content Workflow post, I currently use a table on a OneNote page to manage my editorial calendar.

So I decided to give this Lists template a try.

Creating the list is very easy. It’s a matter of clicking a few buttons, setting a name and a location and the list is created.

But I want to customize the list a little bit to use my terminology and workflow.

Customizing the List

The list comes pre-populated with nine fields, several of which I decided to customize:

Content Type
Content Image
Draft Due By
Publish By
Status

I also added a few columns to enhance my workflow.

‘Content Type’ to ‘Post Type’

Since the only thing I’m using this for is to track entries in my blog, I don’t need a “content type” column. But I do need a column to track the types of posts in my blog, so I changed this to “Post Type” and changed the options to:

Blog Post
Page
Portfolio
Event

I also changed this to only allow a single selection.

‘Content Image’ to ‘Featured Image’

I changed this to “Featured Image” to match the WordPress terminology.

‘Draft Due By’ to ‘Publish Date (Planned)’

My goal is to post a blog entry every month in both of my blogs. For this blog, my scheduled post date is the first Thursday of every month. At any given time I’m working on about four different blog entries, so having a “draft due” column isn’t useful to me. Knowing the planned publish date, however, is.

‘Publish By’ to ‘Publish Date (Actual)’

And sometimes I miss my publication goal, so I like to keep track of when I actually posted my blog entries.

Status Column

The choices included with the “Status” column didn’t match the statuses I’d developed for my workflow, so I changed them to what works for me:

Planned
In Progress
Final Review
Posted
Deferred

Blog

I added this column to be able to track content for both my blogs.

Slug

The slug is a three to four word phrase that succinctly describes the blog entry. It’s used by WordPress as part of the URL and I use it to create a folder for storing my Word document and any related graphics and images.

Customizing the View

Customizing and creating views of Lists are both very easy and very handy. The standard, default view is “All Items.” I edited that view order the entries by the “Publish Date (Planned)” column so the newest entries are at the top of the list.

I also created a view for the planned, in progress and final review statuses so I can quickly see where I need to focus my attention.

Lists also has a handy calendar view, but since I’m only posting two entries a month, it’s not particularly useful to me right now.

Creating a Folder

My Office 365 subscription includes access to Power Automate, Microsoft’s tool for automating tasks and workflows. Using the data from a few of my Editorial Calendar list columns, I created a flow that automatically creates the folder where I save content and assets for a specific blog entry. (An automation in Power Automate is called a “flow.”)

The flow concatenates the planned publish date column and the slug column to create the folder. For this entry, the folder’s name is entry – 2020-12-03 – editorial calendar to lists.

Power Automate is an incredibly robust automation engine. My folder creation flow, while a time saver for me, barely scratches the surface of its capabilities.

To List or Not to List…

Moving my editorial calendar from a clunky, manually created OneNote table to Microsoft Lists was very easy to do. And the functionality available in Lists makes it easy to quickly see where I stand in the writing of my blogs. So far, I really like it. And according to Microsoft’s Roadmap, they seem quite committed to the product. (An iOS app is slated for release in the next few months which will make working with lists even easier.) I see potential for Lists to replace other tracking tools I’m using, like Excel, for other areas of Brettro.

Update: The Bland Brettrospective

It’s been a minute since I posted about creating a new custom theme for brettro.com, so I thought I’d post an update.

When I sat down and really started thinking about how I wanted to approach this, I realized how much had changed since I developed the last brettro.com WordPress theme. I decided I wanted to keep up with and learn about as many of those changes as possible throughout the entire design and development process, so I’m tackling each step with intention and a willingness to learn.

Step 1: Develop a Design System

Design systems seem to be the natural evolution of atomic design and provide an incredible amount of detail from the vision of a design to the exact pixel dimension of a rounded corner on a button and just about everything in between. I want to do a deep dive into this, create one for Brettrospective and document what I learn along the way.

Step 2: Use a New Tool to Design the User Interface

In 2017 Adobe released XD, an app specifically for creating user interfaces for websites and apps. From the little bit of it I’ve used, it seems to be an incredibly useful and functional app and one that I can see becoming the de facto standard for creating and prototyping interfaces. I’m excited to dive in and learn this tool.

Step 3: Assess my Development Toolbox

I want to take a look at the tools I use to do my actual development work. I’m both very comfortable with and a huge fan of all the tools I use. I know that Panic, the makers of Coda have Nova , a new code editor, on the horizon and I am very excited about that. And I recently decided to start using GitLab instead of Github. So those are a few changes on the horizon.

Step 4: Develop the Theme

Even though the Brettro WordPress theme won’t be available for anyone to use, I want to develop it to the standard that would get it approved for posting on the WordPress theme directory. Making sure it takes advantage of the newest features of WordPress is an important learning moment for me, as is understanding what elements must be and should be included in a theme. I plan to use the underscores theme as my foundation.

I also want to give some thought to what CSS framework I might use. My previous theme used Bourbon and Bourbon Neat. Recently the folks who created both frameworks discontinued development on Neat and are encouraging people to use modern, native CSS features like Grid and Flexbox. They’re smart to do so and I’m excited to dive into those two CSS features as well.

Documenting It All

Like I said in my original post about this, I plan on documenting the things I learn, the challenges I face and the victories I achieve while creating this new theme. So stay tuned…

Website Content Workflow

As I’ve (slowly) began writing again, I struggled to remember my workflow for ideating, writing, editing, storing and posting content. It seems like a smart thing to document and doing so was a great reminder of my process. So, here it is. It very closely mirrors the workflow I established at my full-time gig and is a workflow works well for one person writing content—mostly blog entries—for a small website.

The workflow is simple:

Ideate and Plan
Write and Edit
Publish

Ideate and Plan

I use OneNote to brainstorm, organize and schedule my blog entries. I have a section in my Brettro OneNote notebook called “Brettro Website Content.” Inside that section I created pages for each major section of the Brettro website:

Blog Entries
Pages
Portfolio

Each page is then split into two sections:

Brainstorms

This section is a freeform, bulleted list of ideas for entries; sometimes a bullet is just a word and sometimes it is a more in-depth, complete thought.

Schedule

This section is a four-column table:

Title: the title of the entry
Description: the description is a more fleshed-out version of the brainstorm bullet and many times becomes the entry’s excerpt
Scheduled Post: anticipated posting date; my goal is to post every two weeks, but clearly that hasn’t been the case in 2019.
Actual Post: the date the entry is actually posted.

Like I said in my “My Creative Toolbox” entry, I love OneNote and went all-in on OneNote in 2014 and never looked back. It’s available on every device, it’s easy to send items to it from other apps and its interface is elegant.

Write and Edit

Brettro’s content template in Microsoft Word

Years ago I created a content template Word document that includes places for the excerpt, the meta description, meta tags (though those are less necessary now), the copy and custom text for both posting to Facebook and Twitter. The template has worked really well.

File Structure and Storage

In order to have my drafts and related imagery available everywhere, I keep my website content on my OneDrive. (I have an Office 365 subscription, which I find very useful.) I have a folder named “Brettro Web Content” with four folders inside it that match my OneNote pages—blogs, pages and portfolio—and then an additional one for graphics.

Inside each of those folders I create a unique folder for each blog entry, page or portfolio item (respectively) so that I can store the text and any graphics or photos together. For consistency, I use the following naming conventions for those content folders:

Blog entry: entry - YYYY-MM-DD - slug
Page: page - section - slug
Portfolio: project - YYYY-MM-DD - slug

The graphics folder contains template Photoshop and Illustrator files for sizing featured images and images in the content column correctly.

Publish

Posting an entry to WordPress is a copy-and-paste effort from the Word doc. On the Windows version of Word there is a “Post to Blog” functionality that, for whatever reason, isn’t available on the Mac. That’s disappointing because I think having that functionality would be nice. For the moment, I open my content entry in Word, open WordPress and then copy and paste the content and upload the images to create my entry.

Content Management Systems I’ve Used

In my two decades of developing and managing websites I’ve used quite a few different website content management systems (CMS). I thought I’d take a minute to document each of them, where I’ve used them and which I prefer.

Content Management Systems I’ve Used

These CMS’s I’ve either developed for, used on a production website or both. They’re listed alphabetically.

Big Medium

Used from 2006 – 2010.

This file-based CMS I used for smaller sites for several years until I realized the developer had essentially stopped working on it (this was in late 2008/early 2009). Soon after, he announced its end of life.

Documentum

Used from 2002 – 2006.

I used this while I worked at the U.S. Senate Sergeant at Arms. It was more than we needed and not easy to use. I stopped using it because I changed employers.

DotNetNuke

Used briefly in 2006.

When I left the Senate and started at my new full-time gig I inherited this CMS for our intranet. I immediately dumped it for flat HTML. The backend was clunky, creating templates was difficult and managing users was not intuitive.

ExpressionEngine

Used from 2009 – 2017.

I also absolutely loved ExpressionEngine. When I started using it in 2009 it was a cutting-edge CMS for both membership sites and for creating a website with a unique content model. The user and developer community were actively engaged and its creator, the developer community and the plugin development community were second-to-none for support. The product was rock solid. After several years, open-source and equally capable products like WordPress and Drupal drained interest in a product with a price tag. I ultimately stopped using ExpressionEngine because the plugin community dwindled, the product was slow to provide updates and it was becoming harder and harder to find developers who had used the product.

WordPress

Used from 2008 – present.

I absolutely love WordPress. The backend interface is gorgeous. Those who use it to publish websites find it incredibly easy to use. With the right plugins, it can power a very high-traffic, high profile website. The user community is massive. This is my “go to” CMS for just about every project.

On ExpressionEngine vs. WordPress

Several years ago I decided to take a look at the popular web-based content management systems available, choose two of them and focus my website development efforts around them.

It was time. I had been a strong proponent of Adobe Contribute for years as it made managing websites for non-HTML savvy folks very, very easy. But I saw value in web-based products versus buying an app that needed to be installed on a computer.

The Analysis

So, I looked at Drupal, ExpressionEngine, Joomla! and WordPress. I know there are others, but these are the ones that jumped out and appeared to have a strong, committed developer base.

Truthfully, my review was not scientific, but the biggest factors in my assessment were:

Aesthetics of the product’s website and admin,
The commitment of the teams responsible for updating and upgrading the product,
The apparent size of the product’s developer base,
Availability of documentation,
The price, and
How quickly I felt comfortable creating a site using the product.

The Winners

WordPress was an instant winner. The price tag was right, the commitment of not only its creator but also of the core team made was evident and documentation abounds. Also, the admin area for entering and managing content was—and remains—beautiful. It was a natural choice.

At the same time, I kept hearing of this product called ExpressionEngine. I didn’t know much about it, except that it was used by some high-traffic, high-profile websites. And that impressed me. The product was in transition moving from a very solid version one-dot-something to version two. They had a beta of version two available, so I downloaded it, found a book about it and got busy. Out of the box, EE is powerful and incredibly customizable. I was initially a bit overwhelmed by the granularity of the settings, options and capabilities, but I was impressed by a clean admin interface, a very strong and responsive support forum and the commitment of the community behind the product.

So there were my two winners: WordPress and ExpressionEngine.

The Ones Who Didn’t Win

It’s unfair to call Drupal and Joomla! “losers” because they didn’t lose. To say they “lost” implies that the products did not meet any of my very non-scientific criteria. They both do have strong developer bases and committed teams to improving and updating the products. Documentation abounds and they’re both free. And they each have an incredible global installed base.

But I just did not feel comfortable using them. And that’s the non-scientific part of it, really.

Why brettro.com is WordPress

Shortly after choosing both WordPress and ExpressionEngine, I had a major project where EE was the perfect choice. I still manage that website today, use EE daily and absolutely love it. (I wish I could tell you what that website is, but I am ethically bound not to.)

Because I was already using EE on a daily basis, I felt that I needed to use WordPress on a website that I would also manage daily so that I would become equally as familiar with it. And so I chose WordPress to be the CMS as I began to redo brettro.com.

So there it is. My reasons for choosing and using the web-based content management systems I do.

What CMS’s do you use? And why?

Submitting to Subversion

This is the first in a four-part series about how Brettro integrated Subversion into its workflow. Part two will discuss the products Brettro uses to manage its SVN repositories, part three will discuss how Brettro uses SVN with ExpressionEngine and part four will talk about how Brettro uses SVN with WordPress.

About a year ago I tackled the task of integrating version control into my coding practices. I had spent a frustrating amount of time either recreating my code base as I started on new projects or backtracking and rewriting code when I would get a flash of inspiration to try something new. Also, I have both an iMac and a MacBook Pro and I use them interchangeably and wanted to be able to have the most up-to-date code on both of machine. Plus, it seemed all the pros were doing it—and since I consider myself one—I should join the gang.

Why Subversion?

Usually I do quite a bit of research, compare features and discover the value of one product over another. In choosing SVN, however, all I knew was that the WordPress Core Team used it. That, in and of itself, was a strong enough testimonial for me to dive right in.

Getting Started

When I know nothing about a topic, I buy a book, which is the first thing I did. I picked up Apress’s Practical Subversion, second edition, plopped down and started reading. I read chapters one, two and six completely as they provided an overview of version control in general, a “crash course” in Subversion and best practices in using Subversion. (By the way, Subversion is also known as SVN.)

Although clearly and plainly written, I was still confused as to the best way to get started and the best way to integrate SVN into my current workflow. I asked folks how they used it. I tweeted about my confusion consistently. I read blog entries and articles ad nauseum. I definitely hadn’t had my “ah ha!” moment yet.

Integrating SVN into My Workflow

As it turns out and after some starts, stops and stumbles, I realized that my current workflow wasn’t so much a “workflow” as much as it was a “jumble-of-tasks-that-stumbled-over-themselves” to get a project done. So I began to map out two workflows: one for managing Brettro web properties and one for creating and managing client web properties. This was really helpful as it:

Clarified the basic SVN concepts of trunks, tags and branches, and
Formalized how I create, produce and maintain website code.

Creating a Foundation: My HTML ‘Codebase’

With a better understanding of the basic SVN terminology and process, I decided to start with a fresh series of HTML, CSS and JavaScript files that would serve as the basis of all my website code from hereon out; and I’d call it my “codebase.” This seemed to be a great time to:

Make the switch from HTML 4/XHTML 1.1 to HTML5,
Adopt HTML5Boilerplate, a well-maintained framework established to ensure HTML5 code worked fairly well on legacy browsers (like any version of Internet Explorer before IE9),
Adopt 960.gs, another well-maintained framework established to ensure CSS consistency across browsers, and
Create the Brettro website design style manual.

With my basic HTML5 codebase complete, it was time to venture into the world of SVN. My goals at this point:

Be able to modify my HTML5 codebase as necessary for both my purposes and as both HTML5Boilerplate and 960.gs released improvements,
Create a branch of this codebase for my ExpressionEngine development,
Create a branch of this codebase for my WordPress development.

Repositories, Trunks, Branches, Tags and Working Copies

Let’s get some basic terminology out of the way:

Repository: the “repository” (or “repo”) is the container where your SVN-managed code is kept;
Trunk: the “trunk” is the main codebase of a project where most of your development will occur;
Branch: a “branch” is an offshoot of the trunk (do you see the tree metaphor?) whereby you might want to try out an idea or a feature that may not actually make it into production;
Tag: a “tag” is a copy of either the trunk or a branch frozen at a specific point in time, such as a release (the tree metaphor comes to a screeching halt here); a tag is never modified once it’s created;
Working Copy: the “working copy” is either the trunk or a branch copied to your computer from the repo to allow you to make changes.

After all this reading, contemplating, starting, stopping, deleting and creating, I settled on a basic structure that works for me. I’d like to think it’s a pretty common structure because it is based on my understanding of how WordPress organizes their SVN repository (and I like to use best practices because there’s no need to reinvent the wheel):

Trunk

This is where I do my “next major version” development. For example, right after I finished my HTML5 codebase, HTML5Boilerplate released version 2 of their product. Rather than integrate those changes into version 1 of my codebase, I’ll integrate them into version 2 and do that development here.

Branches

When I imported my initial HTML5 codebase into my first SVN repo, I immediately created a branch and named it “1.0.” The “1.0” branch is my working copy of my HTML5 codebase code where I squash bugs and make minor fixes, then release them as dot releases. These releases are merged back down to the trunk so that they are included in the next major version codebase release.

Committing to SVN (See what I did there?)

By finally having an understanding of basic SVN techniques, by documenting my SVN structure and practices and by creating my first version controlled codebase, I was ready to take a deeper dive. Next I created branches of my codebase for both my WordPress codebase and my ExpressionEngine codebase. Stay tuned to the next three parts to learn what software I use and what workflow I use to manage sites built with either of these content management systems.

Brettro Re-Launches brettrospective.com

About nine months after starting this redesign in earnest, I am thrilled to announce the new brettrospective.com!

But nine months?!??

Yep. While it did not take an actual nine months to develop the design, write the code and move the content into WordPress, the Brettro website always took a back seat to both my client work and my full-time job.

The good news is, that in that time period, I really focused on developing better coding practices and on developing a solid codebase from which I can tweak and grow. I have integrated the 960 grid system and the HTML5 Boilerplate frameworks into a very solid HTML5 codebase. For customers, this means fast-loading, search-engine-optimized code. For me, it means quicker development times.

What’s Next?

While I have a solid code foundation and a great look-and-feel, this site is not yet complete. I still have a ton of content left to add. Brettro is not just a web design company, it also does identity, print and video work, plenty of which I have left to add to the Portfolio section. Stay tuned every week for updates.

Looking Back

Truly one of the most fun things about moving forward in any design is taking a look back at what was. So, of course, we’ll do that here. The images below are of the three previous Brettrospective website design. Laugh, smile and enjoy!

The homepage for the second iteration of brettro.com

The homepage for the original brettro.com

Strategory

About nine months ago, I wrote about a strategic shift in the foundational elements Brettro will use to design websites for its customers. The rumblings about HTML5 were becoming louder, I had just finished deploying my first full-scale, medium size website using ExpressionEngine and I had deployed a handful of mediocre (on the coding side) WordPress sites. (They have since become less mediocre.) The benefit of using products with a solid, committed design, developer and fan base behind them, like ExpressionEngine and WordPress, really began to gel with me.

Platforms and Coding

My skill is in coding, my passion is in creating meaningful, usable user experiences and content, my “superhero strength” is managing projects and my “weakest link” is my design chops. Recognizing this, I decided it was time to step up my game and create a plan combining my skill, passion, “superhero strength” and “weakest link” into a functioning business strategy and workflow.

Step one:

professionalize my internal processes,
document coding standards for Brettro,
develop a sustainable platform for client documentation, and
really sink my teeth into merging my “mad coding skills” with the best practices for developing websites using both WordPress and ExpressionEngine.

In that time, and largely through Twitter, I have found an incredible and helpful community surrounding both EE and WP. I started more professional code management using Subversion (and an amazing Mac client called Versions). I have launched my HTML5 codebase. I have created nearly 13 WordPress plugins (and, in many cases, had to completely scrap and re-create them as I learned more and more about WP coding best practices).

In short, I’m well on my way to achieving my goals of becoming more familiar with and better at coding for two brilliantly executed, powerhouse web publishing platforms.

But there’s more to do…

Design, Design, Design

If anything has suffered through all this, it is the design of the Brettro web properties. They are certainly not horrible—and definitely don’t rank amongst the legacy 1996-era sites with all the visual appeal of an avocado green refrigerator—but they are my weakest link.

With comfortable knowledge of HTML5, Subversion and WordPress under my belt, it is time to focus on Step Two: creating a visually rich, responsive, usable, compelling interface for our websites. (The Brettro web properties use WordPress, but that’s a different discussion for a different time. Coming soon, though.)

I’m excited by this next step. Design has always been the biggest struggle for me. I understand the basic concepts, but the crippling self-doubt (which apparently plagues most of the design types I follow on Twitter) about the elegance and visual appeal of the concepts I develop keep me from executing my best work. It’s in there. I know it is. I just need to take a deep breath, walk away from time-to-time, and push through the doubt.

Soon enough you’ll see those efforts come to light. And your feedback will be important.

But there’s still more to do…

Content, Education, Engagement

This is the point where I become so overwhelmed by the sheer volume of things I need to do, learn and participate in. But then I recognize how excited I am by all of it! And really, this batch of “more to do”—also known as Step 3–is really best done by intertwining it throughout the other efforts on a day to day basis:

Education in this arena never stops. And that’s one thing I absolutely love about it.
Strategically writing content for the web is such a compelling activity, especially with advocates (and professional heroes of mine) like Kristina Halvorson and Erin Kissane making such strong showings for its benefits
And Washington, DC has some absolutely brilliant programmers and designers with which to engage. I look forward to becoming an active and beneficial part of the community.

So, guess what? It’s time to get busy. Come back to read about and see the progress as it unfolds. It’s going to be exciting!