Overwhelmed

Posted by Scott on . 4 Comments.

More and more lately I’ve been feeling overwhelmed by the sheer quantity of great stuff on the internet. I sit down at my computer, intending to spend a half-hour in my feed reader, and the next thing I know, it’s three hours later, and I’ve managed to clear out my unread list. But the trick is that I haven’t actually read any of it! All I did was bookmark it for later consumption. Typically, this pattern holds for a week or two until the backlog of bookmarks becomes so daunting that I’ve started avoiding it. Finally, I’ll sit down and plow through the list, skimming at best, wildly reblogging and saving links to delicious in the hopes that I’ll remember that one article next time I’m trying to use webfonts.

In a nutshell, my system is broken. I’m trying to consume too much, and it’s overwhelming me to the point where I’m barely consuming at all. The worst part, though, is that I’m spending so much time trying to stay “caught up,” that I’m not producing anything myself. I’m not blogging, designing, or even uploading photos. I spend what spare time I have watching TV with Annie or playing video games, and feeling guilty about the growing backlog of links, and the fact that I don’t blog anymore.

“I am fascinated,” I insisted, “That’s the problem. I am suffering from fascination burnout. Of all the things that are fascinating, I have to choose just one or two.”
– Neal Stephenson, Anathem

I know this is ridiculous. I have some kind of OCD when it comes to my feed reader. I can’t just skim, or read a little bit. I’m worried that if I don’t stay on top of things, I’ll miss the next big thing that everyone is talking about, or the hot new technique that will make my next site more awesome. It’s crazy, I know, but I can’t help it. I’m a completionist. I have the same problem with video games. Leaving audio logs unfound, or hidden packages uncollected makes me feel like I’m not getting my money’s worth, and sometimes it actually drives me to avoid finishing a game because I can’t handle the idea of just playing it without doing everything.

So. This post is an attempt to force myself to break the cycle. I’m announcing that I have a problem, and I’m going to do something about it. I’m going to go ruthlessly purge my feed reader and twitter list down to the absolute essentials. I’m going to plow through (and likely delete the majority of) my link backlog. I’m going to try to spend more time creating than consuming.

Web Developer Job Descriptions by ZeFrank

Posted by Scott on . 0 Comments.

ZeFrank recently posted these brilliant job descriptions, and I’m reposting them here because I don’t want to lose them if he takes down the “help-wanted” page.

Full or Part Time Front End Developer/Interaction Designer (4+ years experience):

Ideally you should know what the following acronyms stand for and be able to use any one of them to fix a leaky pipe in my bathroom: CSS, HTML5, PHP, AS (AS3, AS2), C++ (for mobile), and all sorts of APIs. You should know by experience that whatever you don’t understand you can learn quickly. You should be awesome at making JavaScript do things it wasn’t designed to do. You should be okay at making Photoshop do what it was designed to do. You should have sent at least one email to someone you have never met telling them that they should stop using tables. You should know how to interact with a database in a healthy, grown-up, passive-aggressive way. You should tell your coder friends that you are a designer and your designer friends that you are a coder. You should have friends but it is okay if you don’t. You should find an exhilarating beauty in finding a simple solution to a problem. The word “iterate” should roll off of your tongue like a mantra.

Part Time Graphic Designer/Illustrator/Interaction Designer (4+ years experience):

You should be comfortable designing anything that needs designing. The phrase “Please make that look more like a Muppet vomited SteamPunk.” should seem like satisfactory art direction, and to be honest there was no need to use the word “please”. You should feel slightly anxious when you see something that isn’t properly aligned. You should know the difference between art and design, and you should love getting into those kinds of arguments. You should feel relieved that I am kidding. You should be awesome at Photoshop and Illustrator and you should be able to use HTML and CSS well enough to defend your work against Internet Explorer. You should love to draw and know how to animate. The word cute should not offend you. You should have had a prior job that made you question your profession. The word “iterate” should roll off of your tongue like a mantra.

Intern (6-9 months):

All of the above should simultaneously intimidate you (at least a little) and interest you (a lot).

Best Practice: Use @font-face for Custom Fonts

Posted by Scott on . 2 Comments.

I just wrote the following for our marketing team to understand how to sell font solutions to our clients. If you have any feedback, I would love to hear it in the comments section!

When a client’s design calls for a custom font in the headlines, there are a variety of solutions we can recommend, ranging from sIFR to image replacement. Each solution (detailed below) offers advantages and disadvantages, so the correct choice may vary from client to client. In general, however, @font-face will provide the best long-term solution and ease of development.

@font-face

CSS3 adds the ability to serve a custom font from the server. It works beautifully, and is well supported in modern browsers*, including IE6+, FF3.5+, Safari 4+, and Chrome 4+. This is the way custom fonts should be handled. That said, there’s one barrier to adoption: Since the font is hosted on the server, you must have a font that is licensed by the foundry (the company that made the font) for web use. There are many free, open-source* fonts available, and a growing library of fonts that can be licensed* directly from the foundry. The cost for a web license (which is frequently separate from the regular cost of the font) ranges widely depending on the foundry.

We encourage our clients to use this method, despite the extra cost, as it is legal, accessible, requires no extra development time, and is the most future-proof solution. Compared to @font-face embedding, every other solution listed here will cost extra (in the form of development time). By purchasing the font license, they are supporting the foundry that made their font, and making their website more adaptable for future edits.

Additionally, for any advanced font styling such as gradient fills, drop-shadows, glows, backgrounds, etc., @font-face is the only solution. You simply cannot recreate these advanced CSS styles on dynamic headlines through sIFR or cufón.

Pros: native font rendering, accessibility, graceful degradation, and advanced font-styling through CSS.

Cons: must use an open-source font, or purchase a license for a commercial font.

Cost: just the cost of the font license. no extra development cost.

TypeKit

Typekit is essentially a hosted version of @font-face. It handles the font licensing and embedding for you, in exchange for a subscription fee. As long as the font(s) the client wants are available in their library (which is pretty large and incorporates several large foundries), this is a very good solution for a very reasonable cost, which could be rolled into the ongoing budget for hosting. The only real downside is that it requires javascript and since it’s a hosted solution, you’re relying on another company’s uptime. I haven’t heard of any issues with Typekit’s uptime, but it’s worth noting.

Pros: handles all the @font-face embedding and licensing for you. Likely cheaper than a license direct from the foundry.

Cons: requires javascript and yearly subscription fee. if typekit goes down (not likely to happen), then the client’s fonts are unavailable.

Cost: depends on website traffic – ranges from $25 to $99/year

sIFR – not recommended

sIFR is a dynamic flash-replacement technique which uses javascript to target certain headlines on the site (eg, all H2s, or all H4s in the sidebar). It reads the text, calculates the dimensions the HTML headline would have occupied, and replaces it with a flash movie that renders that headline’s text in the client’s font. This was the most popular method before @font-face came along, but the project is dead in the water now, and hasn’t been updated since October 2008. It’s difficult to implement, though it’s still a decent solution due to the built-in graceful degradation – users without Flash or JS will see the regular HTML headlines, not a broken flash movie. This is also the only dynamic solution that doesn’t require a license from the font foundry.

Pros: graceful degradation, widespread flash adoption, and legal to use with any font.

Cons: complicated and limited. Basic text replacement works great, but more complicated things like nested styles within the headline are difficult or impossible. Project is no longer being developed, and is poorly supported.

Cost: At least 3 hours of front-end development PER headline style, and further QA, since the site now has to be tested with and without flash.

cufón – not recommended

Intended as a replacement for sIFR, cufón uses javascript instead of flash to dynamically replace headlines. It’s easier to set up, but has some serious accessibility concerns, and may not be legal to use without a license from the foundry – and if you have a license, you might as well use @font-face instead.

Pros: less complex than sifr

Cons: accessibility concerns, and since the font isn’t embedded in flash, it may not be legal unless you have a license from the font foundry.

Cost: At least 3 hours of front-end development PER headline style, and further QA, since the site now has to be tested with and without javascript.

Image replacement – not recommended

Using CSS, we replace individual headlines with images containing that headline set in the client’s font. This solution is time-consuming and difficult to edit, but works well on sites with a small number of headlines that don’t need to be edited very often.

Pros: gives the client exactly what’s represented in the comp.

Cons: requires lots of image production time to create every headline image, and corresponding CSS production time to write code to replace all those headlines with their images. Making edits in the future is difficult, because someone will need to make a new image and edit the CSS. Likely impossible to implement in a dynamic CMS like Drupal.

Cost: 10 minutes per headline, minimum.

Use native fonts instead – not recommended

This isn’t really a solution, since it doesn’t use the client’s font. I’ve just included it for completeness’ sake. This approach means that we ignore the custom fonts and use one of the limited set of “native” fonts instead. In practice, this means using Arial for sans-serif fonts and Georgia or Times New Roman for serif. If the client’s font isn’t very distinct, then this can be a good choice.

Pros: requires no development time at all.

Cons: does not use the client’s font.

Cost: none.

Further reading:

Best Practice: Use native form elements whenever possible

Posted by Scott on . 0 Comments.

I just wrote the following for our marketing team to understand why we recommend not styling forms. If you have any feedback, I would love to hear it in the comments section!

Our recommendation is that only minimal styling be applied to form elements. When possible, using the native form elements is the most accessible solution. When we do apply styles, we should make sure that it degrades gracefully, and doesn’t cause problems in older browsers. Clients need to understand that making forms look identical across all browsers is NOT possible. This is a limitation inherent to the browsers themselves. (see the further reading below, in particular, Eric Meyer’s post.)

In the past, we have tried to promise cross-browser styling, such as by using the Uniform jQuery library, and have found, without exception, that this adds a dramatic amount of time to the front-end development of the site, due to the difficulties of forcing styles onto elements that weren’t built to support those styles. If a client insists on heavy form styles, we should make sure to charge an appropriate amount to cover the increased development and QA time.

Some things are relatively easy to style, such as plain text inputs and submit buttons. Other things, such as drop-down menus, radio buttons, or file select inputs, are nearly impossible to style. Since we can’t say for sure what works and what doesn’t, we’re left with a fairly vague recommendation to use “minimal styling” on form elements. In practice, this translates to borders, padding, and background colors on text inputs, though even these will look somewhat different across browsers. We can also do pretty much anything to submit buttons, because we can replace them with images — though again, there are difficulties, and the native buttons are more accessible and recognizable.

Further Reading:

How to Change the Content-Type Meta Tag in Drupal

Posted by Scott on . 0 Comments.

I’m working on an HTML5 theme for Drupal 7 right now, and I needed to change the meta content-type tag. By default it looks like this: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />, and I needed the updated HTML5 version: <meta charset="utf-8" />. Normally, you can replace these things in one of the theme template files, but in this case, the meta tag was hard-coded in the Drupal source code somewhere, so I needed a programmatic solution. Here’s what I found for both Drupal 6 and 7.

Drupal 6

The meta tag is stored in the $vars['head'] array, so we can simply use the php str_replace() function to change it. Just drop this code into the template.php file for your theme.

// replace the meta content-type tag for Drupal 6
function YOURTHEME_preprocess_page(&$vars, $hook) {
  $vars['head'] = str_replace(
    '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />',
    '<meta charset="utf-8" />',
    $vars['head']
  );
}

Drupal 7

This is slightly more complicated in Drupal 7, because instead of storing the meta tag directly in a variable, the attributes for the tag are stored in an array, which is later converted into markup. Now, we could still edit that markup, but it’s more elegant to update the attributes in the array before it’s turned into markup, rather than rely on a string replace. Here’s how to do it. Again, just drop this code into your theme’s template.php file.

// replace the meta content-type tag for Drupal 7
function YOURTHEME_html_head_alter(&$head_elements) {
  $head_elements['system_meta_content_type']['#attributes'] = array(
    'charset' => 'utf-8'
  );
}

You can use this technique to update any setting stored in that array. To see what your options are, add print_r($head_elements); inside that function. It’ll display the contents of the array on your page (though you may need to view source to make any sense of it). To edit a different tag, just replace system_meta_content_type with the item you want to alter. You can even remove an item from the array entirely like this:

// remove a tag from the head for Drupal 7
function YOURTHEME_html_head_alter(&$head_elements) {
  unset($head_elements['system_meta_generator']);
}

This is a perfect example of one of my frustrations with Drupal. For the most part, the theme system is well thought out, but if you stray from the beaten path by trying to do something they didn’t think you would need to do, you have to do it programmatically. It’s hard for me to fathom why certain parts of the markup, like this meta tag, are locked away, instead of making everything available in the theme layer. Still, this code should give you the tools you need to gain access to them.

Note: This was originally posted on my work blog, and I’m re-posting it here for archival purposes.