Tag: typekit

WordPress.com Custom Design: A Logical Price Rise?

WordPress.com has long provided a Custom CSS upgrade. I’ve been using Custom CSS here at ChangingWay.org ever since the blog has lived at WordPress.com and used the Simpla theme.

Custom CSS is now part of the Custom Design upgrade. Custom Design costs $30 per blog per year, twice what Custom CSS used to cost. So what else does the extra $15 buy? Well, you get more help with CSS from WordPress.com now. Back in the Custom CSS days, you paid to be able to edit CSS, and WordPress.com was explicit that it didn’t provide support to you in getting the CSS right.

But the main difference between Custom Design and Custom CSS is: Custom Fonts. In fact:

  • Custom Design = Custom CSS + Custom Fonts + Support.

Custom Fonts refers to the use of Typekit. CSS and Typekit go logically together, as I noted when I first tried Typekit. That was two years ago, before Typekit became available at WordPress.com. It would have made sense to me had Typekit been available as part of Custom CSS. After all, CSS allows you to specify fonts (among many other things), while Typekit lengthens the list of fonts you can use.

Instead, when WordPress.com first made Typekit available, it opened the Typekit door to all users, at no charge, while providing minimal support. I played around with Typekit at this blog, used it elsewhere, and responded to some questions about Typekit in the WordPress.com forums. But ChangingWay.org currently uses CSS, rather than Typekit, to specify fonts.

WordPress.com announced the Custom Design upgrade earlier this year. To recap, this means that for $30 per blog per year, you can get the combination of Custom CSS and Custom Fonts, with support for both. The combination is a logical one and, at less than $1 a week, seems reasonably priced – to WordPress.com, and probably to many of its bloggers.

But, to other WordPress.com bloggers, the bundling of CSS and Fonts into a single $30 package represents an unwelcome change. One blogger recently complained in the forums that he cannot use Typekit for free anymore (but follow the link to the thread for a way in which bloggers already using Typekit can continue to use it at no charge).

To me, Custom Design represents a doubling of the price I pay for using Custom CSS at this blog. I don’t need Typekit, and I don’t need CSS support. The price change is an input into my annual question: should I continue to pay for WordPress.com upgrades, or should I move to another WordPress host?

What are your thoughts on the Custom Design upgrade and its pricing?

Drupal and WordPress, Two Years On

Drupal and WordPress are often compared. Here’s a summary of my summary of a comparison between the two platforms: WordPress is easier to get started with; Drupal has the advantage when it comes to more complex sites.

That was two years (and two weeks) ago. A lot has happened in those years, and early 2010 is a particularly busy and important time for both communities: Drupal and WordPress. If I had to provide a soundbite (blogbite? tweet?) right now, it would be: Drupal and WordPress are becoming more similar.

The best example of convergence from the Drupal side is Drupal Gardens, the slogan for which is: “Building Drupal websites just got easier.” It was indeed easy to establish a little outpost of the Changing Way empire at Drupal Gardens. ChangingWay.org runs on WordPress.com, of which Gardens is the Drupal counterpart.

Gardens runs on version 7 of Drupal. I love this line from Jacob Singh about developing Gardens on that new version, rather than on version 6: it’s like playing Jenga on a cocaine addled elephant riding a skateboard being jabbed in the ass with a hot poker.

WordPress is also in the midst of a new major release. In fact, this very post is a fringe member of a current and ongoing series about WordPress 3.0. Much of what’s in 3.0 (e.g., multisite) is already in Drupal.

The above account of convergence between Drupal and WordPress is very broad-brush. But it’s also about as long as I like a single post to be.

Comments – especially yours – are excellent for filling in gaps. They are also excellent for asking questions, and for offering me inducements to write more detailed comparisons of Drupal and WordPress and the communities and organizations behind them…

Typekit for Freshy

Freshy is popular, with me and more generally here at WordPress.com. So Freshy is the second theme for which I’m posting a translation of blog terms into CSS selectors.

You need a translation like this in order to be able to use Typekit on your blog. So a theme-specific translation might be called a ThemeKit.

  • Everything: body
  • Blog title: #title h1
  • Blog tagline: .description
  • Post title: #content h2
  • Title of sidebar sections, including widgets: #sidebar h2
  • Horizonal menu: .menu

Note: if you want the same font for post titles and sidebar section titles, you can use the selector h2, and it will apply to both. Freshy is a relatively simple (in a good way) theme.

Typekit Made Simpla

The previous episode of Typekit Tales focused on the hero’s struggles with Typekit at WordPress.com, and involved his getting help. Help did arrive, followed by some thoughts about easing the struggle.

This post is intended to ease the struggle for those who follow the hero along the Simpla path: in other words, for bloggers who use the Simpla theme, especially at WordPress.com. In order to apply change the fonts you use, here is how to refer to some of the parts of your blog.

  • Everything*: body
  • Blog title: #header h1
  • Blog tagline: #header p
  • Post title: .entrytitle h2
  • Title of sidebar sections, including widgets: #sidebar h2

* Note that everything means everything not overruled by more specific CSS selectors.

I used Anisette STD Petite for everything, then Intruder Alert for the headings. As before, I chose those particular typefaces because they are distinctive rather than because I think that they improve the blog. So they will survive at this blog only in the illustrative image.

The post title should probably read Typekit for the Simpla Theme, but I couldn’t resist the one you see above.

Trying Typekit

Intruder Alert! That’s the name of the font currently gracing the title (Changing Way) at the top of this blog.

I chose that particular font to check whether I could get Typekit working here at WordPress.com. It’s hardly a subtle change from Tahoma, the main heading font for this blog, and it looks nothing like Georgia, the workhouse here. For this testing, I wanted an intrusive font, and was amused when I found one appropriate in name as well as in appearance.

This isn’t the first time I’ve tried Typekit, or posted about it. In my earlier post, I recommended that Typekit be available at WordPress.com, and linked it to the CSS upgrade.

Typekit has since arrived at WordPress.com, but doesn’t require the CSS upgrade. Well, in a way it does. Consider the following barriers to changing the CSS on a WordPress.com blog: (1) it costs money; (2) it requires knowledge of CSS; (3) it requires knowledge of the way CSS is used in the blog’s particular theme.

I find the third and last of these barriers to be the highest. What heading level does a WordPress theme use for the blog title? for the tagline? for the post title? for headings in the sidebar? And what other selectors (besides h1, h2, etc.) are used, and how are they used? The answer varies between themes.

The theme I’m currently using, Simpla, uses h1 for the blog title. So to test Typekit, I used its kit editor to associate h1 with the distinctive Intruder Alert. That font was for some reason applied to the blog’s tagline (rather than to its title).

I emailed Typekit support over the weekend, and today received a response. I needed to use the selector #header h1. At a more general level, I need to be aware of CSS selector specificity.

My point, and I do have one, and I am getting to it, is similar to this one. Getting TypeKit to work on your blog can be frustrating especially if you are not familiar with CSS. That’s a quote from (and a link to) a guide to using Typekit at WordPress.com. The guide is good, but the quote could be more specific. You need to be familiar with the CSS of the theme.

My CSS isn’t terrible. I’ve tweaked a few themes, including Simpla for this blog. I found Typekit it harder to apply Typekit to that CSS than I did to tune the CSS itself.

I suspect that using Typekit is trickier than editing CSS. I’m generalizing, not only from my own experience, but from what others have written (in, for example, a post in the WordPress.com forums).

So, although Typekit has lower financial barriers to use than the CSS upgrade, it has higher overall barriers to use. I have concerns about this. One is that it’ll cause frustration for WordPress.com bloggers who see that they can try Typekit for free. The other is that Typekit support may be swamped. Anyway, time to email thanks to the Typekitter who supported me.

Typekit, WordPress, etc.

TypeKit is a web service that allows you access to hundreds of fonts for your websites. I’ve just started using Typekit on my Android Icon blog, since I think that blog should use Droid fonts on as many platforms as possible (i.e. not just Android).

Android Icon is self-hosted (i.e. unlike Changing Way, it doesn’t live at WordPress.com) and so I can use plugins there. There’s a Typekit plugin, and I may well try it.

Typekit isn’t currently available at WordPress.com. I hope that it will be available soon.

Typekit would be good for WordPress.com, for those who blog there, and for Typekit. It would help WordPress.com profits by making the Custom CSS upgrade more attractive. It would help bloggers who want to use different fonts. For Typekit, it would bring attention and customers, some of whom would switch to paid versions of Typekit.