Lessn Shortlinks WordPress Plugin

January 15, 2011 – 1:00 pm

I recent­ly pur­chased the somad.es domain for use with my own URL short­en­er. (Van­i­ty or own­ing my own URLs: you decide.) I decid­ed to use Alan Hogan’s Lessn More, an improved fork of Shaun Inman’s Lessn. I then decid­ed I want­ed to inte­grate the short­link into my Word­Press install, but the exist­ing WP Lessn plu­g­in isn’t very good. Its admin page does­n’t adhere to WP secu­ri­ty best prac­tices, it does­n’t use WP’s HTTP API, and it does­n’t prop­er­ly inte­grate with WP 3.0’s short­link API. In short, it does­n’t do things the WP way.

So, I made my own lit­tle plu­g­in. I did­n’t want anoth­er plu­g­in set­tings page, so you have to hard­code your Lessn URL and API key. It inte­grates with the “Get Short­link” but­ton on your write/edit post screen, and the rel­e­vant short­link HTTP head­er and meta ele­ments are auto-insert­ed. Only the “post” post_type will get Less­n’d by default, but see the bot­tom of the plu­g­in for how to add addi­tion­al post_types.

Now, I just need to fig­ure out how to inte­grate short­links for humans rather than just machines.

Tagged , , , , | By Matt | Posted in WordPress | Comments (4)

FontFriend 2.5

January 11, 2011 – 7:51 pm

Font­Friend was designed and cod­ed as dur­ing the twi­light of the pre-web­font era. In fact, it was abstract­ed out of some code I’d been using while devel­op­ing the CSS font stacks for my Word­Press theme The Eru­dite. I haven’t been using it much as of late, as I’ve been wear­ing my devel­op­er hat more than my design­er one of late.

But, as I’ve been tin­ker­ing with pos­si­ble redesigns of my per­son­al site, I’ve been play­ing around with web­fonts a lot, a work­flow that nev­er crossed my mind when design­ing it. So, rather than putting my design ener­gy to work on my site design, I decid­ed to extend Font­Friend to sup­port cus­tom Font Fam­i­ly lists.

Font­Friend’s new cus­tom font fam­i­ly list

This is a fea­ture for front-end designers/developers, so there is no user-fac­ing UI for this fea­ture. Instead, on a site that you want to test web­fonts on, you can pro­vide that Font­Friend will rec­og­nize in one of 2 ways:

1. A data- attribute on the body element

<body data-ff-families="OFL Sorts Mill Goudy,PT Serif,Crimson,Tinos,League Gothic">

2. A JavaScript array

The nice part about the JS method is that you can use your JS con­sole to set the var before invok­ing FontFriend.

<script>
  var fontFriendFamilies = ["OFL Sorts Mill Goudy", "PT Serif", "Crimson", "Tinos", "League Gothic"];
</script>

That’s it! Use whichev­er nota­tion suits your work­flow. See it in action right now by vis­it­ing the updat­ed Soma Web Font Spec­i­men and invok­ing the book­marklet (you’ve already installed it, right?).

Tagged , , , , , , , | By Matt | Posted in Design | Comments (3)

Doing Things the WordPress Way

January 10, 2011 – 9:00 am

This past Fri­day marked the sec­ond Win­nipeg Word­Press meet­up, and it was fan­tas­tic. It also marked my first time pre­sent­ing on a tech top­ic, and I thank every­one for let­ting me ram­ble for a while! Len from WPCana­da has a great write­up of the event and has high hopes for the future.

My pre­sen­ta­tion was on Doing Things the Word­Press Way, which cov­ered a few things I’ve picked up along the way as a WP devel­op­er. A few peo­ple asked for the slides, so here they are:

Doing Things the Word­Press Way (on Slideshare)

Big thanks to Ian Stew­art for orga­niz­ing the event, and to the Digi­he­dron crew for host­ing us. Sub­scribe to the Win­nipeg Word­Press meet­up blog for updates about future events.

Tagged , , , | By Matt | Posted in WordPress | Comments (6)

Better Web Reading

January 3, 2011 – 12:23 pm

It’s damn hard to read web con­tent some­times. Too-small text, arti­cles split over mul­ti­ple pages, gra­tu­itous ban­ner ads, design that steals you atten­tion from the actu­al con­tent: these all con­spire to make read­ing on the web—especially long-form content—frustrating, painful and some­times down­right infu­ri­at­ing. 2010 saw two major approach­es to this come to some degree of promi­nence, and both have made me so much happier.

Readability

The first approach makes in-brows­er read­ing bet­ter through the Read­abil­i­ty book­marklet. It strips away every­thing except the text you’d like to read, sized and for­mat­ted appro­pri­ate­ly for on-screen read­ing. Safari incor­po­rat­ed Read­abil­i­ty tech­nol­o­gy in its Read­er func­tion­al­i­ty in Safari 5, bring­ing bet­ter read­ing to folks who have no idea what a book­marklet is. What I espe­cial­ly love about Safari Read­er is that it does a good job of string­ing a mul­ti-page arti­cle into a sin­gle page.

Read it Later

The sec­ond approach is using a third par­ty ser­vice like Instapa­per (which I use and love) or Read it Lat­er to extract the main con­tent from a web page and read it lat­er on a vari­ety of a devices. Both have iOS apps that sync with the ser­vice to give you the con­tent you’d like to read, even offline. This is a vast improve­ment over the old “I’ll leave this tab open and come back to it lat­er” approach that rarely, if ever, worked in practice.

Both of these trends in web reading—especially the first—demonstrate that peo­ple are no longer putting up with design that dis­re­spects con­tent. They want design that puts con­tent first, like The Eru­dite, which has been down­loaded 92,832 times as of this writ­ing. Hope­ful­ly we’ll see less need for Read­abil­i­ty as web design­ers start mak­ing actu­al­ly read­able sites.

Tagged , , , , | By Matt | Posted in Design | Comments (2)

Testing IE9’s WOFF Support

December 28, 2010 – 10:00 am

IE9 offi­cial­ly sup­ports the new WOFF for­mat for embed­ding web­fonts. And there was much rejoic­ing. But, the ques­tion that’s been nag­ging away at me has been: how do we as web devel­op­ers account for IE’s lega­cy EOT for­mat while giv­ing pref­er­en­tial treat­ment to the emerg­ing WOFF standard?

The short answer is: keep using Paul Irish’s bul­let­proof smi­ley syn­tax. WOFF will be loaded by browsers that under­stand it, and lega­cy IE ver­sions (8 and under) will load EOT.

The long answer: every src dec­la­ra­tion with­in the @font-face block effec­tive­ly resets the CSS parser’s attempt to find the appro­pri­ate font file. The ren­der­ing engine will use the first viable font source in the last src dec­la­ra­tion inside each @font-face block. Paul Irish’s smi­ley syn­tax works per­fect­ly here, since the first src dec­la­ra­tion is only under­stood by IE < 9 (due to the EOT for­mat), while the sec­ond src dec­la­ra­tion is under­stood by >= IE9 and all oth­er good browsers.

This pro­duces a win-win sit­u­a­tion. Good browsers that aren’t IE ignore the first src dec­la­ra­tion because EOT is not viable to them. IE9 prefers the sec­ond src dec­la­ra­tion because it under­stands EOT.

I have a few test cas­es to view. They’re also avail­able on Github.

Tagged , , , , , | By Matt | Posted in Web Standards | Comments (4)