On the one hand, it’s probably best to let users make mistakes, or format as they wish, and depend on human communication to clear things up— instead of trying to build in a bunch of extra structure designed to cover for mistakes.  It’s our view that the latter approach leads to bloated, overbuilt CMS systems that discourage accountability.  But at the same time, consistency and coherence of communication across a Web site is a really, really important thing— it is what distinguishes sites that serve as good vehicles for an institution’s messaging from sites that are just decorated Web pages.

We’re thinking about this right now because we are considering automatically converting the titles of news items in LiveWhale to Title Case.  The following three news headlines, though identical in content, send very different messages:

1.  White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
 

2.  White Whale Web Services to release new content management system, revolutionize CMS industry
 

3.  WHITE WHALE WEB SERVICES TO RELEASE NEW CONTENT MANAGEMENT SYSTEM, REVOLUTIONIZE CMS INDUSTRY
 

Although there might be a justification for #3 in a particular Web design, it’s clear that you wouldn’t want a user to enter news headlines that way.  For one thing, caps are just hard to read in many contexts; but on top of that, it’s always easy to {text-transform:uppercase} if you need caps.  My general preference as a design snob would be for #2, but that’s clearly not common practice— as much as I enjoy headlines like this (or this), that style is much more common in European news than American.

It’s also the case that styles #1 and #2 look terrible next to each other:

• White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
• Other CMS providers cower in fear

So.  Should we let users do what they will, and enter headlines according to any system they prefer?  Or should we legislate something?  It seems pretty clear from the above examples that— at least in the particular case of news headlines— legislating is the way to go.  And if you’re going to require a particular format for headlines, it seems pretty clear that Title Case Is Your Only Option.

So what’s the best way to do it?

You could, for example, simply ask the user to format the headline a particular way:

___________________________________________________
Please use Title Case for headlines.

Or, a bit more diplomatically, you could provide an example:

___________________________________________________
Example: Stock Market Soars on Rumors of Bailout

Alternatively, we could let users enter any headlines they want, and control the front end display with CSS’s text-transform property.  But that’s not going to work either, because these are the only options we have:

Title Case Is Great, But Not If You Capitalize Every Word In The Sentence.  Otherwise It Looks Hacky.  The text-transform property doesn’t have the kind of sensitivity you’d want in a good Title Case headline.  I am personally big on punctuation and capitalization styles that reflect spoken rhythms— that’s why, no matter what Douglas says, I always put a space after an em dash— and capitalizing “the,” “and,” etc. ruins the spoken rhythm of a headline.

So the only approach left— assuming you want to engage this issue at all!— is to automatically convert headlines into Title Case on the back end.  And that’s the whole reason I started this post in the first place.

It turns out that converting to Title Case is nowhere near as simple as you’d imagine.  Sure, we know that you don’t capitalize “the” or “a” or prepositions, etc.  But how about sentences like these?

Read markdown_rules.txt to Find Out How _Underscores Around Words_ Will Be Interpreted

Notes and Observations Regarding Apple’s Announcements From ‘The Beat Goes On’ Special Event

These sentences are from a suite of test cases for a Title Case script originally created by John Gruber of Daring Fireball.  We are planning to use the PHP version of the script to convert some of Southwestern’s old news headlines (originally entered with uppercase headlines) to a thoughtful Title Case, and are considering using it when headlines are created in LiveWhale in the first place.  In the process we discovered yet another odd, fascinating corner of the world of CMS development to geek out in.

With some thought, we were able to come up with a taxonomy of content photo sizing:

1. Constrained horizontally (e.g. in a sidebar):
   
   
2. Constrained vertically (e.g. to align alongside text):
   
3. Constrained both horizontally and vertically within a box:
   
4. Constrained both horizontally and vertically to fill the box, with the edges lobbed off automatically (e.g. when needed as specific design element):
   

I thought the fourth case would be the only troublesome one, but we knocked out uses 1, 2, and 4 rather quickly. Use 3, however, proved to be a problem; we just couldn’t get it to size appropriately for every test case. Unlike the others, it was unclear what dimension to constrain to: it varies not only for the same image placed in different spaces, but also for different images in the same-sized space:

It was one of those problems that is as easy to describe–”fit the image in the box”–but hard to wrap your mind around programatically. We knew there must be simple logic to it, but despite examples in Photoshop and repeatedly walking through the problem we were having trouble making sense of it. Finally, we realized that the key comparison is the ratios of the images: if height_original:width_original > height_target:width_target constrain by height; otherwise, constrain by width. We actually managed to make an educated guess at the solution before we fully understood the problem, but we did some old-fashioned pen-and-paper work to prove ourselves right.

The ins-and-outs of this backend code and logic no doubt are pretty dry to much of our audience. But this sort of problem is one of my favorite parts of my job: working through the logic of it is completely fun stuff to my inner geek, but more importantly there’s a great satisfaction in knowing you’ve found that killer solution. When you get home, it’s hard to explain to your significant other why spending the afternoon on this one simple function wasn’t a waste of time–heck, sometimes it’s tough to get that across to your boss. But here’s a case where, by taking that time, we were able to both clearly define all the ways we employ content photos on the design-side and create a single function that quickly fits any given photo to those uses. And that not only solves an immediate goal, but we can take that solution with us. We nailed it. And we may never need to think about image sizing again.

Getting these PNGs to actually be transparent is no longer a major issue—we’ve used a few different approaches over the years, but settled on Angus Turnbull’s iepngfix.htc as the most straightforward drop-in solution out there. The way it works is just really smart.

But while building out some recent client projects, we just couldn’t get it to catch. We checked and double-checked the file paths, and re-exported the PNG images, and finally copied a working example from a live client site, but nothing seemed to do it. Because IE has no decent debugger, I removed the conditional comment to see what I could learn in Firebug.

It turns out that our staging server sends the .htc file as text/plain, while the working client version was serving text/x-component. Changing out server config to mimic this fixed the problem. Later, some Googling revealed that the release notes for the newest beta version address this (and even include a PHP solution that serves the file while sending the correct headers).

There are still a whole host of limitations: no repeating images, weird layering glitches that happen even in IE7, and really bizarre link clickability issues. But iepngfix gets far enough to solve 90% of the problem.

Maintaining code libraries does not have to contribute to bloat, either. The idea of a framework is to implement core APIs that are used from project to project to build functionality specific to that job. The independent framework itself will not absorb any of this site-specific functionality, contributing to bloat. A good framework plateaus, only growing incrementally upon necessity and relevance to the entire breadth of your work. Furthermore, more robust frameworks are modular, loading on the components they need. Sometimes explicit control is desirable, in which certain users are authenticated and given access to particular modules or plugins. Other times code logic dictates which portions of the framework need to be loaded and deployed. It may be desirable to go for a model in which services are dynamically registered within mechanisms central to the framework.

It’s particularly exciting to be in a position where you can rely on a powerful foundation of tried-and-true code, and be free to unleash your creativity in terms of how those static APIs are deployed from project to project. Broader communities might also benefit from your work if you can isolate and open-source particular APIs that contribute to smart application development, and certainly there are great options out there which you can adopt and benefit from yourself. Just as with any other career, the knowledge you gain, tools that you build, relationships that you make, over time, help to define who you are and what you can bring to the table in terms of problem solving, creativity, and commitment to the industry in which you work.

There is an SSH2 module that requires a little more effort to set up on your web server, but enables support for SFTP servers. The question is then, how can I integrate this extension and its features into an existing FTP codebase in an efficient manner? Furthermore, the SSH2 module’s syntax is not as straightforward for basic FTP tasks as the actual FTP extension is.

The answer is really pretty simple. I created an FTP wrapper class which runs in one of three modes: FTP, SSL, or SFTP. Depending on the mode, the wrapper class reroutes its method calls to the appropriate extension. All the methods for this class exactly match the ones for the FTP extension. In the case of FTP and SSL, it is easy to map the methods from one to the other, because they’re exactly the same. In the case of SFTP, there’s a translation layer which converts FTP commands in the FTP extension’s syntax to the SSH2 extension’s equivalents.

The reason this approach is efficient is because all the existing code can be painlessly converted to the wrapper class, such that SFTP is instantly supported. No alternate SFTP code paths, no significant code rewrites, no new syntax to follow. What it boils down to is one extra step to specify the FTP mode, and then just prefixing each FTP function call with the wrapper object (i.e. ftp_put to $ftp->ftp_put). Done!