Page 243 of 428

My Suite of Apps

November 11, 2014 / Tom

Over the last few years, the categories and tags on this blog have renamed consistent. That is, the categories with which I started out with haven’t been changed, removed, or have seen any additions since I’ve been running this blog.

Generally speaking, I say that’s pretty good – it means that all of the content that I’ve wanted to share has fit within the categories that I originally planned. As such, when I set out to write about the things that, y’know, originally wanted to write about, I had defined the focus of the content and have done relatively well at keeping content consistent within those categories.

Today, I’m going to be adding a new category to the blog (I know, I know – call down, right?) in order to support some upcoming articles that I’ve been planning to write but never really had the desire, need, or want to do so.

Using GitHub Issue Checkboxes

November 10, 2014 / Tom / 0 Comments

One of the things that I like most about working with issues in the context of GitHub is that you can classify them based on what type of issue. That is, they can be be bugs, enhancements, features, or any other custom label that you opt to display them.

On top of that, GitHub-flavored markdown also makes it easy to to write well-formatted issues and comments on these issues. Over the course of this year, one of the things that I’ve found myself using more and more when filing issues has been using checkboxes to help break issues down into more incremental steps.

Your Decisions Are Weak (Throw The Baby Out With The Bath Water)

November 7, 2014 / Tom / 0 Comments

It seems to be relatively common in the online developer community to easily dismiss others’ work when it doesn’t align with whatever we consider to be the best way to go about doing something.

I think it’s fair to say that this is something that we’ve all seen, too: Think about one of your favorite libraries, frameworks, applications, dependencies, or whatever, and then think about how critical and dismissive other people – or even ourselves – can be of the work.

Honestly, there’s nothing wrong with being critical – I think it’s helpful because it forces us to justify the decisions that we’ve made, defend our rationale, or even rethink our approach.

But when it comes to dismissing something solely because you dislike how it’s done represents a ill-formed perspective on the work that someone has done and a lack of understanding as to why things are the way they are.

A WordPress Theme Development Process

November 6, 2014 / Tom / 0 Comments

Although I still stand by the idea that we all have the ability to decide how complex or how simple we create our themes, I do think that there’s something to be said for identifying the core problem a given theme is trying to solve.

That is to say, is a given theme trying to:

Target landing pages for a certain type of niche business?
Create a reading experience that looks ideal on mobile devices?
Serve as a tumblr-esque type of blog?
Meant to serve as an online journal for, say, photos or music or videos or something similar?
…and so on

In short, I think that when someone asks you “what does your theme do?” or “who is your theme for?” then you should be able to quickly give an answer. Saying something like “this theme is for the small business owner who runs a restaurant, or a body shop, or a photography studio, or a convenience store” is too broad.

If we use personas as a way to identify who our themes are for, and a persona represents an actual type of person, then doesn’t it seem highly unlikely that a person who runs a restaurant may also be the type of person who is a mechanic and/or a photographer?

What I’m trying to say is that whenever we sit down to begin planning out and building our themes, I think that we need to do a better job of identifying both who the theme is for the and what the problem space is that we’re attempting to enter.

Some personas should be taken more seriously than others, I think.

Of course, this isn’t to say that some teams don’t already do this. In fact, I can think of quite a few who do and who do it really well. Other times, though, I think that many try to create themes more or less to show off what they can do with WordPress rather than to truly serve a need that a potential set of customers may have.

So where do this leave us? That is, how can we do a better job of approaching theme development in such a way that’s it’s solving problems and catering to a certain type of customers rather than just trying to be the next flashy product that offers n-number of a features and m-number of options?

How To Remove TinyMCE Buttons From WordPress

November 5, 2014 / Tom / 0 Comments

Depending on the level of customization or the level of formatting your customer wants or you want to give your users as it relates to the WordPress post editor, you may need to remove TinyMCE buttons from the WordPress editor.

Although it’s relatively easy to remove all of the buttons and, say, focus only on the HTML view, it’s also possible to remove individual buttons from the post editor so that the user only has a subset of the options that are typically available.

TinyMCE Buttons

Say, for example, you want to remove everything from the second row exception the formatting drop-down that let’s you select the heading size, paragraph, or pre elements. It’s easy to do this using one of the hooks that WordPress provides.

Tom McFarlin

My Suite of Apps

Using GitHub Issue Checkboxes

Your Decisions Are Weak (Throw The Baby Out With The Bath Water)

A WordPress Theme Development Process

How To Remove TinyMCE Buttons From WordPress