A New WordPress Plugin: Clean Notifications

HTML email gets a deservedly bad name mostly because it’s used to send out spam and marketing and also because it’s tough to work with from a design and code standpoint.

However, under controlled conditions and in limited circumstances, HTML mail can be a whole lot cleaner than plain text email. In converting Mike Industries to WordPress recently, one of the things I noticed right away was that the e-mails WordPress would send me when new comments and pings came in were extremely verbose. Since WP sends out plain text emails, all of the links get spelled out as raw, unstyled URLs and the emails end up containing probably twice the amount of visible characters than they need to. This is especially frustrating when you’re trying to read notifications from a mobile device like the Jesusphone.

What could possibly tighten WordPress’ email notifications into more aesthetically pleasing hyperlinked missives? A plug-in which sends out better formatted mail!

Enter “Clean Notifications”. A plug-in that took only 30 minutes to write but is capable of providing digital pleasure to people all around the world.

Here is what a WordPress email looks like before Clean Notifications:

… and here is after:

Note the economy of characters. Only the info you need, spaced for readability, and requires no configuration.

Download Clean Notifications and love WordPress just a little more.

Adding a “Subscribe” Bar to Your Blog

It makes me uneasy that such a huge number of people still visit blogs the old fashioned way: by checking them manually every now and then. This, of course, is in opposition to subscribing via RSS and then only clicking over when there is new content.

I am guilty of keeping an extremely unpredictable publishing schedule at Mike Industries, sometimes posting multiple times per week, and other times going almost a month without any new entries. For this reason, I wish all readers were subscribers. That way, no one would ever be greeting with old content.

In an effort to convert more casual readers to subscribers, and hopefully convert people onto RSS in general, I’ve developed a PHP-powered module which prompts users to subscribe to my feed if they aren’t already. Here’s how it works:

1. If you come to Mike Industries and don’t have at least one of two cookies, you see a bar encouraging you to subscribe via RSS or e-mail. One cookie is the “subscriber” cookie while the other one is the “promptclosed” cookie.
2. If a user clicks over to Mike Industries from my feed, I set the “subscriber” cookie. If a user manually clicks the “close this message” link in the module, I set the “promptclosed” cookie. Both cookies last for three months.

In order to accomplish this, you need to do a few things:

1. Write some simple HTML to display your prompt message. Include it at the top of every page of your blog, hopefully using something like PHP so you only have to do it once. Using PHP, or your dynamic language of choice, set the message to only render if neither the “subscriber” nor the “promptclosed” cookies are set. Here’s what mine looks like:

   <?php if (!isset($_COOKIE["subscriber"]) && !isset($_COOKIE["promptclosed"])) {?></p> <div id="subscribe_prompt"><a href="/feed" style="border-bottom: none; vertical-align: middle; position: relative;top: 2px; margin-right: 4px"><img decoding="async" loading="lazy" src="/blog/images/icon_feeds_black.gif" alt="" width="16" height="16" /></a>Subscribe to Mike Industries via <a href="/feed">RSS</a> or <a href="javascript:void(0)" onclick="document.getElementById('subscribe_emailform').style.display='block'">e-mail</a> and be notified of new stuff automatically.<a href="javascript:void(0)" class="subscribe_close" onclick="setCookie('promptclosed', 'closed', now, '/', HOST, '');document.getElementById('subscribe_prompt').style.display='none'">Close this message</a></p> <div id="subscribe_emailform"> <form action="http://www.feedburner.com/fb/a/emailverify" method="post" target="popupwindow" onsubmit="window.open('http://www.feedburner.com', 'popupwindow', 'scrollbars=yes,width=550,height=520');return true">Enter your e-mail address: <input type="text" style="width:150px; margin: 0 6px 0 6px; font-size: 10px" name="email" /><input type="hidden" value="http://feeds.feedburner.com/~e?ffid=64422" name="url" /><input type="hidden" value="Mike Industries" name="title" /> <input type="submit" class="button-search" value="Subscribe" /></form> </div> </div> <p><?php }?>

2. Modify the URLs in your feeds such that they pass a variable at the end like “how-to-make-a-margarita?subscribed=true”.
3. Using PHP, or your dynamic language of choice, insert code right above the code in step 1 which checks for the presence of “subscribed=true” in the query string and sets the “subscribed” cookie accordingly.

* Note: If you are using Mint w/ BirdFeeder like I am, you can skip steps 2 and 3 and just add the following to Birdfeeder’s class.php right above the line that says header("Location:{$_GET['seed']}");:

$subscriber_expire = gmstrftime(“%A, %d-%b-%Y %H:%M:%S”, (mktime()+(60*60*24*90)));header(“Set-Cookie: subscriber=true; expires=$subscriber_expire; path=/; domain=yourdomain.com”);

Voila. That’s it. An unobtrusive message encouraging you to subscribe which goes away after you either subscribe or decide to close the message.

Interestingly, I got this idea while experimenting with Google AdSense several months ago. I only wanted to show the ads to casual passers-by (perhaps coming in through search engines) and not to Mike Industries subscribers. Now that we have the ability to set cookies and identify who is a subscriber, we can do all sorts of things. I can imagine a small subset of features on the site which are perhaps only made available to subscribers. Who knows. I like the possibilities though.

How To Keep Widgets From Slowing Down Sites: WEDJE

The whole world is going to widgets. This overused, overhyped term refers to third-party code one places on their website or blog in order to display such things as Flickr photos, Twitter status, or iTunes playlists. Everybody and their mom is putting out widgets these days, and although only about 1% of them are useful or interesting, they are an important new distribution mechanism that is changing the way companies think about syndication.

But there is a big problem with widgets: they slow down the sites that use them. In the best case, you have a company like Flickr whose servers are almost always snappy, and in the worst case, you have a young startup that is constantly struggling against increasing demand and occasionally can’t serve up any code at all.

The problem is that in either of these cases, the completion of your site’s loading and rendering depends on someone else’s code living on someone else’s server. Including a fast and reliable Flickr widget still slows your site down by at least a split second and including a less stable one can leave your site hanging indefinitely.

We’ve been developing what we think is going to be a gangbusters widget at Newsvine over the last few months but just as we were getting ready to deploy it, Intern Rob and I hacked together what we think is a method of deploying widgets in such a fashion that they don’t affect the load times of their parent sites whatsoever.

Following is a breakdown:
Read more…

Drag N’ Validate

Ever find yourself debugging XHTML via your browser’s View Source command? I do it all the time. You know the routine:

1. You add a module somewhere on the page and it’s borking your layout.
2. You hit View Source.
3. You drag-select the module in question, paste it into a Stickie Note, manually indent your tag tree with tabs, and then find out where your tags are unbalanced.

It’s a pain in the ass and maybe there’s a better way to do it, but here’s a tool I’d love to see:

Drag N’ Validate (or Dragon Validate) — Drag select a block of XHTML in any application, right click to pull up a contextual “Validate” menu, and the application will autotab the block for you and point out any validation errors.

That would be money.

Two Week Code Pushes: Fast or Slow?

I just finished reading a TechCrunch interview with Andrew Anker of Six Apart about their excellent new service, Vox. It’s a nicely conducted interview about a well-designed product that I think will be very successful, but this line struck me as a bit odd:

“Very early on in Vox’s development, we created a two week rapid iteration cycle where we made sure to push code religiously every two weeks. By doing that, we made sure that we were building a design cycle that was always two weeks away from fixing any problem.”

Do bi-weekly code pushes qualify as “rapid” these days? Even at Disney, we generally didn’t take much longer than that, and at Newsvine we push every single day. Multiple times even. We like the rapid pushes so much, in fact, that we even set up a machine to triumphantly speak out the filepath whenever someone pushes out code: click for a sample.

Maybe it’s because I’m impatient about site improvement and problem solving, but Andrew’s statement — if it were applied to me — would advocate a deliberate slowing down of the push cycle (perhaps for the better).

Does anyone else agree? With web technologies the way they are today, do you consider religious code pushes every two weeks a fast thing or a slow thing? Are scheduled infrequent pushes (meaning, much less than once a day) preferable to your development habits?

Mint Not Considered Harmful

I’ve always wanted to write one of those “considered harmful” essays, but then I remembered Eric Meyer’s “Considered Harmful Essays Considered Harmful”, so I’m writing a “Not Considered Harmful” essay instead.

The subject for the day is Mint… something I find to be extraordinarily harmless. Beneficial, actually… the polar opposite of harmful. Yes, I know I’ve already written about my love for Mint last week, but a few things have developed since Mint’s release that I feel require comment. Here are a few of those things:

1. Lots and lots of people have purchased and downloaded Mint, and as far as I know, there’s only been one request for a refund. Yay!
2. Shaun is completely bogged down helping people one-on-one (even over IM!) work through various intricacies of their server setup and how it relates to Mint installation. He is also simultaneously adding improvements here and there to the install process as well as fostering the development of the Mint Forums. In short, the man is slammed.
3. Although the lion’s share of comments and blog posts I’ve read around the net are positive, I did see two isolated negative posts which went all the way from questioning whether or not people deserve to be compensated for software they develop to whether or not the group of Mint beta testers was somehow in the wrong for posting about Mint.

Read more…