In the process of developing and refining our CMS, the question occasionally arises whether or not we should convert text inputs from format X to format Y. These questions range from the innocuous and straightforward (should we convert curly quotes to straight quotes? or vice versa?) to the more insidious (should we correct a misspelling? should we move close quotes to outside a period?).
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?
Read more »
Tags: code, development, livewhale, lwblog, php, Title Case, whitewhale
Comments: One comment »
Last week, we flew Alex out to the Bay Area for some company togetherness and to devote some serious time to the aforementioned yet still-unannounced internal project. An also-secret major feature of said project required us to use PHP to place arbitrarily-selected images in arbitrarily-sized spaces (without, of course, unattractively stretching or squishing the image).
With some thought, we were able to come up with a taxonomy of content photo sizing: Read more »
Tags: code, development, images, livewhale, lwblog, photos, resizing
Comments: None »
Internet Explorer 6 is a web development headache for many reasons, but its lack of support for PNG alpha transparency is one of the most grating. It’s more-or-less a given that any cutting-edge design (even a relatively minimalist one) is going to have a place where one layer shines through another, or a single transparent image should be matched to multiple background colors, or—most commonly—anti-aliased text is placed over a photo or texture.
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.
Tags: code, CSS, development, ie6, internet explorer, png
Comments: 5 comments »
My favorite part of programming has to do with maintaining and using code over the long term. In this sense, reusable APIs and frameworks are central to my work process. Adding a new feature to a project generally does not involve coding something wildly unique or reinventing the wheel. While the various ways in which you interact with web applications vary greatly on the surface, under the hood there should be a level of consistency, in which code is reused, flexible, fast, and straightforward. If you do a lot of form processing, for example, you might maintain a set of commonly used input validation functions. If you’re working with a solid application layer, whether for security, templating, or database functionality, etc., it will evolve over time and become something incredibly powerful, accounting for important trends in the industry which can easily be applied to past projects, as well as accounting for the various server environments in which it needs to run.
Read more »
Tags: api, code, development, framework, open source, programming
Comments: None »
At White Whale I maintain several libraries of code which involve performing tasks over FTP. PHP has an FTP extension that works pretty well for FTP-related code. The major flaw with it is that it only supports FTP and FTP+SSL. As we start working more and more with SFTP servers, many of these libraries needed to add SFTP support.
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. Read more »
Tags: code, development, ftp, php, sftp, ssh
Comments: One comment »