Author: Tom (Page 243 of 428)

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?

Continue reading

By their nature, WordPress themes are open source. Whether or not you want to be is kind of a moot point because anything work that is a derivative of a GPL-based work must be licensed as GPL, as well.

WordPress is GPL, thus plugins, themes, and any other work that’s built on top of it should be GPL’d, as well.

When you’re working on a plugin or a theme or any other project, this doesn’t mean that you have to have the repository open. By that, I mean you can work on the code in a private repository on GitHub and, when the product is ready, have it released as GPL and then share it with users, customers, and so on.

Such a great open source contributor.

Honestly, though, unless you’re running some type of hosting platform where people sign up for the service and install themes (think WordPress.com or Evermore), then they have to get the source code anyway in order to install the theme on their server.

Nonetheless, I still feel like there’s a little resistance when it comes to working on a theme (or a plugin, even) in a public repository where anyone and everyone has the ability to fork it, open issues, offer suggestions, issue pull requests, and so on.

Continue reading

Niche WordPress themes is regular of topic of discussion for those involved in creating themes for WordPress. Discussions range from debating whether or not niche themes are dead all the way to why niche WordPress themes continue to be one of the ways to create something unique for WordPress.

Regardless of where you fall on the topic, niche WordPress themes currently exist – and need to be maintained – and will likely continue to be created for the next few years.

One of the challenges that comes with creating niche WordPress themes is how to manage certain aspects of WordPress that are typical for standard publishing themes but aren’t necessarily required for niche WordPress themes.

Continue reading

When building things for the web, we normally refer to “the stack” as the set of software that we use that powers an entire application. Generally speaking, this usually consists of three things:

1. The database
2. The application layer (or the server-side programming language
3. The front-end

Today, there are many different types of data stores available: We can use anything from a traditional database to using a document-based database system, or some type of abstraction provided by another service like Amazon.

For the application layer, we can have Rails, PHP, .NET, Python, and who-knows-how-many-more. And for the front-end, we generally use HTML/5, CSS/3, and JavaScript (and variations thereof).

But if a stack usually refers to a set of languages, tools, or technology that goes into building something, and each area of an application can be further divided into subsets (like with the front-end), does it make sense to have terminology for each of these areas as well?

Continue reading