Page 244 of 429

My Suite of Apps: Safari

November 11, 2014 / Tom / 0 Comments

I know – Chrome is arguably the best web browser (or at least the most popular) on the market right now. Ever since the first version was released, I used it religiously (and I used Firebug and Firefox when I needed developer tools until Chrome’s finally shipped).

But when the latest version of OS X shipped, I decided to give Safari a try if for no other reason to see if the claims about its speeds were true, and to take advantage of Continuity.

Like any other web developer, I still have other browsers sitting on my machine so that I can use them for testing and so on, but I’ve actually been using nothing but Safari since Yosemite’s launch and I haven’t missed my other browsers.

In fact, I’ve enjoyed using Safari more than any other browser because of its integration with other devices.

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?

Tom McFarlin

My Suite of Apps: Safari

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