I’m Writing a WordPress Book

I am writing a book about WordPress development. I hope it will inform beginner, intermediate, and advanced developers to all take more joy in their craft.

WordPress Patterns

Here’s the concept: It will be a book of patterns for WordPress development, with how-tos and essays organized in a non-linear, linked, self-reinforcing system — a coherent pattern language.

The book will describe masterful practices on a spectrum from philosophy, to information architecture, down to sound coding approaches for specific technical problems. It will guide developers to anchor their work in “the WordPress way”, identify the right tools for a given job, build in forward-thinking ways, and connect their work to related situations and patterns.

Something Different

To my knowledge, this is unique in the WordPress world. Code references serve a different purpose entirely: They’re more like a dictionary, useful to expand fluency but not a way to learn the language. One-off tutorials found through searches are how most of us learn the basics, but they are often of low quality and aren’t often helpful or available for advanced skills.

The brilliant Plugin Handbook comes closest to what I have in mind: it provides a comprehensive jumping-off point for how-to information, presented with context. In fact, I expect my book to often point back to the Plugin Handbook. But the pattern language format is distinct from the handbook format, and lends itself to different reading behaviors and learning styles.

The difference is all about how you approach the material as a reader. Handbooks are great for “get me up-and-running quickly”. Collections of pattern are  good for “given my need, give me a solid approach”, and for “given my problem, help me to understand the tradeoffs, the history, and and the why of the recommended solution.” Handbooks equip you with breadth; pattern languages go deeper, which is why they are potentially of use even to people with intermediate and advanced skill.

For Most Everyone

I think this concept could be useful for developers with intermediate and perhaps even advanced skill, as well as for beginners.

I wish I’d had patterns available to read when I started 3 years ago. I wish I had them to guide me still today, so I’m cautiously optimistic that others will find it useful, too.

To be sure that it is, I will ask a handful of other developers to review early drafts of my first few chapters. Their input will help me to course-correct and, I hope, confirm the value.

Open Source, Baby

In the spirit of open source, I am committed to making the book’s content freely available to everyone on the web. As I write, I will publish drafts (when I’m no longer embarrassed by them), and incorporate feedback while I edit. Eventually, when there is a coherent body of work, I expect to publish commercial e-books. Perhaps they’ll be GPL licensed (if that’s appropriate for the medium — I’ve yet to look into this at all).

I am writing at a slow pace, mostly due to spending a lot of time just researching and editing as I learn more. I have identified over a hundred potential chapters and expect that to double or triple. After four months I have a couple dozen chapters outlined and about half a dozen solid drafts — none of which are quite ready for review yet. I expect to accelerate a bit, but it will still be a good long while before anything is considered final.

All the more reason to publish drafts in the open: This way, I won’t have to wait for people to get some value out of the work.

Feedback is Love

Researching open source licenses for book content is on my todo list. I’d appreciate any pointers.

More generally, I would love to hear your reaction to this. Does the pattern language approach make sense as I’ve described it? Given your skills, do  you imagine this would be useful for you? Are there specific topics or patterns you hope this will cover? Are you interested in reviewing early chapters? Perhaps interested in contributing?

2 Problems with Blogging About Your Annual Goals

Wherein I write “goal post” several times, but never refer to sports.

This being the time of year when we’re all gearing up for the year ahead, I’ve enjoyed reading several people’s Goals for 2015 posts. It may be arbitrary to do this once a year, around the turn of the year, but I’m glad for the tradition. It gives me an excuse to learn about other people’s hopes and dreams for the year ahead. I find it particularly inspiring when the goals come along with down-to-earth plans for achievement.

There’s something I really don’t like about the writing form, though: Blogs, despite being one of the best publishing tools we’ve got, don’t lend themselves well for this use.

Let me walk you through the problems, and then the solutions — including a really fantastic plugin that will make a surprisingly big difference.

Problemo Numero Uno: Time Relevance

Blog posts capture attention for a little while after publishing — some for a very long time, although not many. Most are ephemeral.

This isn’t a problem usually. Posts shouldn’t continue grabbing attention forever. They become inaccurate in time as facts change, or they lose authority to newer web resources that do a better job of providing information.

The very design of blogs encourages this. Eventually, posts are simply pushed off the home page to make way for newer posts. WordPress defaults to 10 posts on the home page. Publish a new post, and you push the eleventh most-recent one off the home page, where it’s less likely to be seen.

This does become a problem when the topic of a post justifies more than a few weeks’ or months’ attention.

Annual goal posts, for instance. Your goals for 2015 will be current and relevant for the whole year. How will people discover your goals post in July, when it’s far from the first page?

Why post your goals at all? Your goals are probably an important part of how we, your readers, will learn who you are and what you’re about. A few months from now, we might forget your goals. How will we know to help keep you accountable, pipe up with some coaching when needed, or celebrate your successes?

Thus, your goal posts deserve more prominent attention than they’ll get buried several pages deep.

Keep them on the home page

Your goal posts are worth a link from your home page, throughout the year.

You might add a link to the post from your sidebar. I don’t have a sidebar on my blog currently, so I’m opting to link to my goals from my main navigation menu. That’s some precious real-estate, but it’s worth it.

You might also consider making the post “sticky” to keep it pinned to the top of the front page. The check box for this is hidden behind an “Edit” button next to the “Visibility” setting in the post editor’s “Publish” box.

Click that unassuming 'Edit" button to the right of Visibility...
Click that unassuming ‘Edit” button to the right of Visibility…
... now you can stick it to 'em.
… now you can stick it to ’em.

But, this isn’t a great fit for Goals posts. While they’re important to keep prominent, they probably aren’t worth every reader’s attention, all of the time.

Problemo Numero Dos: Keeping Current

Your goals post, like blog posts generally, are snapshots in time. A goal post you publish in January reflects your sense at that time of what you want to accomplish, and reflect that you’ve made no progress yet — you’re just beginning.

But in real life, your goals are likely to shift, and you make progress towards achievement.

In other words, posts are great for sharing your goals when you form them, but they suck at keeping your readers up to date over time.

If I tell you my goals here, and you read this within a few days, you might think “Neat! Go Matthew!” But if you happen to be reading this in July, well that’s a much less satisfying experience for you, isn’t it?

Say July rolls around and you decide you really can’t or won’t complete one of your goals. Or, more happily, you achieve one. You could manually update your post, to keep its information current. But then you lose the snapshot of what your goals were at the time.

And, the revised post won’t pop back up into view at the top of your blog again, so people aren’t likely to get the message. If I’m following you through email, RSS, or social media, I get automatic updates when you publish something new, but nothing when you update something old.

“Easy,” you may be thinking, “I’ll write another post with the update.” Okay. But what if I stumble first on the original post, and never see the update? Okay, so just add a link in your original post to the update, and vice versa, to keep that from happening.

Well, (a) that’s one more thing you have to remember to do, (b) it’s tedious, and (c) now if I stumble on your update first, I have to go back and re-read the original to appreciate the entire context, which doesn’t make for an ideal reading experience.

You could do what a lot of people have done (including your’s truly), and write just an annual review. No updates at all between these arbitrary year-long intervals. But I know from experience doing this that my goals become easy to fall out of my mind. Not to mention fall out of my readers’ minds, which prevents them from keeping me accountable, and enjoying my successes with me. (See above.)

A Better Way to Blog about Goals

Here’s what I’m doing.

One: Publish a page with my 2015 goals

Why a page? Becuase this isn’t intended to be a snapshot in time, but a page I keep current with manual edits, and with automatically updating live data when available. This will continually show what I’m working towards, and how I’m doing on the path.

You may’ve noticed the page is linked to from my main menu: Goals

Two: Publish a post with my 2015 goals

This will sound redundant at first, but it won’t be. The post will be my snapshot in time, with a bit of added commentary as to how I’m thinking about my goals at this point in time.

Three: Post occasional updates

Perhaps I’ll do this monthly, but at least quarterly. As my goals page changes, these update posts will provide a record of running commentary and context. If I abandon a goal, finish one, or add something new, I’ll call attention to it in these updates.

Four: Use Threads to tie the update posts together

Threads is a WordPress plugin. Quoting from its description:

If you have ongoing themes you write about on your site, you can use Threads to show those posts in a timeline, with a link to the timeline from each of the posts. This helps you avoid feeling like you have to rehash too much history about the topic in each post.

I first discovered Threads on plugin author Alex King’s site. I’m not sure why a lot more people aren’t using it. It’s a brilliant idea with brilliant execution.

Alex has a Year in Review thread, among others. You’ll see at the bottom of this post that I’ve started doing the same thing here. I’ll also start another new thread for posts related to my 2015 Goals. It will provide a timeline for context and a running record of my goals at a glance.

Out of snapshots will emerge a story.

I want you to do this

Why not give this a try? Setup a page as the main home for your goals, install the Threads plugin, post updates naturally as there’s news about your goals, and add thread metadata to your posts as you go, just like you do with tags and categories.

It’s just a few simple steps for you, and a much better experience for your readers like me.

Here’s to your success in 2015! I look forward to reading all about it.

This post is part of the thread: Annual Goals and Review – an ongoing story on this site. View the thread timeline for more context on this post.

In Search of Applications Build with WordPress

For all of our talk within the WordPress community about building applications with our favorite CMS, I know of very few branded apps out in the wild. I’d like to know of more, to help spread the word and point to when we’re pitching app development at Rocket Lift.

Specifically what I’m looking for are “web application built with WordPress”, defined* as:

  1. Use WordPress as primary framework on server(s) and to render HTML, CSS, and JavaScript (WordPress can be customized as needed)
  2. Users create accounts and log in to use the service
  3. Generates revenue for the operator
  4. Is not simply an e-commerce store selling downloads or physical merchandise.
  5. Bonus criteria: Provides some service beyond managing website content (which WordPress does out of the box)

I know of exactly one application that meets all of these criteria: Hellobar.

When I asked this question Saturday on Twitter, some people suggested HappyTables.com. HappyTables looks like a great service, but it is a “vertical” — WordPress fine tuned to manage specific kind of websites (in this case for restaurants) — and thus it doesn’t meet my “bonus” criteria. I don’t mean to say HappyTables isn’t an application. Criteria number five is a bit arbitrary and reflects that I’m looking for applications outside of WordPress’ core strength of website publishing.

If you know of something that meets these criteria, please post it in the comments!

Thanks. :)

*I’m sure these can be better defined if needed, and I’ll update based on feedback.

Slides and reflections from my presentation on WordPress Developer Tools

On Tuesday I gave a remote virtual presentation titled “WordPress Developer Tools” to the Room to Think coworking community in Richland, Washington. My slides are posted here.

The slides are built with the web-native Reveal.js, and the source is here on Github. I am so in love with Reveal.js. So long, Keynote! Thanks to Flynn O’Connor for turning me on to this at BeachPress.

This was my first experience giving a tech talk, my first WordPress talk, and my first remote talk (meaning it was delivered over a video conference with screen sharing). I gave the talk from my bedroom at the BeachPress house in Rockaway Beach, Oregon. I learned several good lessons, thanks in part to the great feedback I was given:

Giving talks virtually

  • Not compromising on internet bandwidth is important. (Duh.) It wasn’t fair to the audience that I didn’t make absolutely sure ahead of time that my up and down times were good.
  • At the beginning, establish good and bad ways to give feedback during the presentation. I wasn’t able to hear audience members far away from the microphone and also missed some messages in the Google Hangout’s group chat window because I wasn’t paying attention to it.
  • I didn’t know at one point that our connection dropped for several moments because I was looking at my slides instead of the Hangout window. I’ve seen similar issues in presentations where I’ve been in the audience before, and I’m not sure how to fix this.
  • I’m interested in giving virtual talks more often because they’re more nimble — I can give them from anywhere with (good) internet, etc. — and also better for Earth than flying all over to speak in person. I’m not saying conferences and events are bad, just that I’d like to explore and promote how virtual talks can work well to be really great experiences, to lower the tech industry’s carbon footprint a bit. On the whole, this experience seemed to support that it is possible to pull this off and do it well, if I pay more attention to the details listed above.

Giving talks on WordPress

  • My slide deck skews a bit heavy in the beginning toward explaining why it’s even a good idea to think of WordPress as a serious platform. I think I may feel a bit defensive about this, which I’ll work to get over.
  • Similarly, this should have been two separate talks. I plan to split them — one about WordPress as a framework, another about technical dev tools.

Giving tech talks

  • I thought I was exempt from the Law that Live Coding Demos Don’t Work because why?

My Talk Submission for WordCamp Portland 2013

This year’s WordCamp Portland organizers are trying some experiments this year with selecting speakers. First, they’ve asked for submissions in the form of video pitches. And, for the first time, the conference has a theme: Permanence.

I was planning to put a lot more time into this, but was strongly encouraged not to, so I knocked it out in about 20 minutes this evening after a full day of coworking at BeachPress. The video is fairly lo-fi, and straight to the point: Introducing the topic, describing its relevance to the conference’s theme of permanence, and introducing myself as the right person to give the talk.

Here’s my submission. It’s all about checklists.

Aren’t I cute? Vote for me!

Just kidding. There’s not actually a way to vote. But I’d love your feedback.

Lisa Sabin-Wilson on Women in the WordPress Community

In an interview on Code Poet, Lisa Sabin-Wilson answers Michael Pick’s question about whether she’s found any additional challenges as a woman in what has been a male-dominated field.

In the WordPress community, at least, it seems like a non-issue, to me. However, that does not mean that we should be happy with maintaining that as status quo. I think the WordPress community is doing much to the effort of keeping it that way and presenting a model to the tech world, at large, on how life should be for women in tech.

It’s only one perspective, as she is careful to point out, but I’m really glad to hear that.

Managing a business with custom WordPress

We’re building systems on top of WordPress to manage every part of our business at Rocket Lift.

The WordPress platform essentially manages content and authentication for us, gives us frameworks to build custom UI and our own functionality, and offers extra features in the form of plugins developed by a large community. It gives us everything we need to rapidly build our own custom tools that fit our own process, style, and needs.

We’re tackling the low-hanging fruit first: We’re customizing P2 to make our internal discussions less reliant on third party limitations, and we’re building a Parking Lot for action-oriented discussions we’ve identified to iterate on the way we work (We treat our Parking Lot as a sacred commitment that we need to have a conversation soon, even if we don’t have time for it right now. WordPress will help us keep these top-of-mind with simple widgets and other other UI elements to display posts of our custom post type).

We’re also dogfooding tools to tame the content management gremlins that plague our client projects. I believe I speak for all of us when I say we are so excited about these tools, and can’t wait to share then when they are ready. Soon!

And then there’s our roadmap. Which is, you know, only kind of insanely ambitious.

  • A project management calendar, building on the awesome The Events Calendar to add some features we have never seen, desperately want, and believe that you, dear reader, will find killer.
  • Internalize our task management… Basically, we want a place to store “everything I don’t need to focus on right now”, something like Asana but with a saner awareness of task relationships.
  • Dashboards to pull in data from third party services for display in custom at-a-glance views. Individuals will be empowered to build their own dashboards with custom UI building blocks we create, combined with pipes to data from awesome API-backed sources like Pipedrive, Harvest, Github, and &! plus our own WordPress-based data.
  • If Intuit continues to refuse us easy access to our data, then maybe some day in the far future we’ll ditch QuickBooks. And won’t that be satisfying.

This is a lot to tackle, even without that last whale of a wish list item. This approach violates common wisdom in lean startups that says “Don’t build what you don’t have to”. I’m the one driving this; I’m probably crazy.

Yes okay, but we’re taking this one small piece at a time. This roadmap may span years. More importantly, we do custom work with WordPress every day, and have seen its potential as an application framework grow dramatically even in the past year, thanks to the addition of fundamental tools like wp-cli and the positive trend of plugins being architected (in some cases re-architected) for extensibility and interactivity by embracing core APIs and the hooks and filters pattern. WordPress has ripened.

We’re scratching our own itch here, and we’re doing what we can with what we have, where we are. Fresh off the the high of last weekend’s WordCamp Portland, we’re emboldened to push forward with these ideas.

Right now this is just words. Stay tuned to see what we can deliver.

Categories do it wrong

I don’t know what categories are for in WordPress.

I’m currently drafting a post that defies categorization. It draws on a some recent life lessons in self-improvement (Personal) to explain why and how I’m going to attempt to use this website (Meta) as a proving ground for how WordPress (WordPress) can replace Twitter (Technology), which is an incredibly important albeit flawed service (Cyborg Anthropology).

If Categories hold any value, I suspect it is as a tuner into high-level channels, e.g. useful for top-level navigation. As in, are you hear to hear my ramblings on religion? Awesome, here’s a category for you [and link to /category/religion/]. If you know me from WordPress-land, well then here [/category/wordpress/]. But right now, at this early stage, I’m not confident what this blog’s themes will turn out to be.

And furthermore, those high-level channels break down when a piece is about ALL THE CATEGORIES. I don’t expect to frequently write pieces that tie all of my interests together… but I have a hunch I may surprise myself.

The nomenclature and concept of “Tags” make far more sense. I’m never shy to assign a long string of Tags to a post — as many as are appropriate. Although they may not identify high-level themes, at least I know what to do with them.

Whereas, when I’m slapping nearly every Category my site uses (present and future) on a single piece, it feels redundant, wrong, and frustrating.

I’ve been using categories because they are there, and my use has been sloppy. I’m in a pre-paving-the-cowpaths phase. The cowpaths aren’t clear yet — the grass hasn’t even grown up yet to be trampled. High level themes are vague.

So it’s time to stop with the Categories. Tags will do for now.

Todo: Expunge categories from the front-end, and live without them for a while.

(Not Completely) Grokking Post Formats

Wherein I revisit a debate from a year and a half ago to stir up trouble.

WordPress 3.1 dropped in February of 2011 and introduced Post Formats, a new taxonomy indicating a post’s front-end presentation context. Formats include Aside, Status, Image, and Video among others, and the idea is for themes to vary their presentation based on what the thing is. Twitter-like post about what you’re doing right now? Give it a Status format, and smart themes will, for example, omit the title in the front-end. Short-form note? Call it an Aside, and perhaps a theme will slap an “aside” watermark in the margin and hint with typography that this is one of your less-serious works (of brilliance).

The WordPress core team decided to standardize the available formats, and not offer APIs to extend them, so that you could expect your content to port gracefully when switching to a new theme. Theme developers were evidently in an uproar about this, considering the number of articles lead developers wrote around the time of 3.1’s release to explain and clarify their rationale for rigid standardization. See Otto’s for example, and a longer list linked on the Codex page under External Resources. WordPress’ philosophy includes decisions, not options — but developers typically enjoy a back-door escape clause when the decided defaults don’t suit them, in the form of functions, filters, and hooks to add to– and override defaults. In this case, post formats fundamentally require standardization, thus extensibility would undermine the entire feature, and thus no APIs exist to add “custom post formats” (which, to be clear, do not exist — there are only the standard formats). The core team’s explanations focused on this point, and on the fact that post formats are merely a custom taxonomy, and that in fact site developers already can create their own custom alternatives if they need to, using the same APIs that core uses to implement post formats.

I get that. Standardization is important.

But, I’m also sympathetic to the themers’ desire to add to the array of standard formats without having to do any re-implementation. Re-implementation seems inelegant — I’m thinking mainly of code bloat.

I know I am extremely late to this party, but there is a compromise that seems… well, obvious to me. I can’t imagine I’m the first to consider this, and there’s probably a compelling argument against it — which I’d like to hear.

I would propose to have custom post formats that require a fallback to a standard format. In practice, when loading a post, WordPress would check to see if it’s format was supported by the theme, and if it is, it would be passed to the theme as that format, but if not, it would be passed to the theme as the standard fallback format. It would be up to the theme developer to consider graceful degradation in their design process.

I believe this would only require two API methods: (1) A function to register custom post formats, that requires you to declare a fallback to one of the standard formats. This code would be inappropriate for a theme and would belong in a plugin (because if the theme were swapped out, the database entries specifying the new custom post format would be left with garbage). (2) A function to add theme support for a specific non-standard format.

I would use a mechanism like this to, for example, register a custom format for dictionary Definitions. I’d make them fall back to the Aside format.

Can anyone explain why this isn’t a good idea?