Chapter 42

When you’re maintaining a software product which evolves and expands in order to remain competitive and make itself more useful to a user base, it’s easy to forget to keep all the moving parts in line with changes and new features as you roll them out. However, if this issue isn’t dealt with, bugs and performance issues will inevitably arise.

LiveWhale, our CMS, is essentially a module-based system. Individual modules can be provided to our customers on a per-client basis. Each module is a self-contained element, that “registers” itself in the CMS framework, thereby establishing its functionality throughout. A module is responsible for creating and managing its own data, but if it is flagged as group owned, access to that data is handled by LiveWhale’s users and groups system. Continue Reading »

Tags: backwards compatibility, bugs, cms, diagnostics, livewhale, lwblog, performance

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?

Continue Reading »

Tags: code, livewhale, lwblog, php, Title Case

It’s tough to write copy or put together a design for something outside the realm of your knowledge. Though we pride ourselves on being elitist academic types, it does come up sometimes. (Jason once put a beautiful magnified photo of a virus in a sciences mockup. It turned out to be AIDS. Whoops! Lesson learned.)

Of course, internally, you would think that people would shout any questions across the room and notify each other of any mistakes. Tonya has gone from entirely non-geek to believably geeky in her time at White Whale, but when it comes to technical details in a proposal she always runs it by us developers to make sure her take on it is clear.

All this is to say I spotted this on the website of one of those razzmatazz web 2.0 startups:

(And no, Tonya won’t get this joke.)

Tags: audience, html, in-jokes

I had one of those hours-become-days airport delays coming back from visiting family a couple weeks ago and the experience keyed into something that we think about a lot in terms of customer service.

Every other airline had a screen like this. But at the Airtran counter they had something that had more in common with one of these. And over the course of our three hours in line it became clear that the board wasn’t being actively updated. So we stood there for a frustrating afternoon in an information vacuum, not knowing if we could make our connection or would have to be booked on a later flight. Only at the counter did we learn that our flight had been cancelled and we’d have to return the next day for a rerun of the same.

Aside from all the practical help that just a small bit of information would have been–giving us time to make other travel arrangments, sparing my parents extra round-trips to the airport, allowing us to skip dosing our dog up with the sedative he takes before flying–simply taking the step of updating the status board would have measurably decreased the stress level of the planeful of passengers in line.

Here’s a point of contrast: After our second go of it was unsuccessful, we ended up getting a refund and booking the next day on US Airways instead. And, as it turns out, that flight was pushed back quite a bit too. But we weren’t left guessing about it because I woke up to an automated call that told me the duration of–and even the reason for!–the delay and offered a path to follow in case I needed to make alternate arrangements. And at the airport, the first thing the representative told us was, “It looks right now like you’ll be able to make your connection. But keep your eye on the status and come back here if it changes.” So, though the flight was delayed an additional two hours, we made it home because when we saw that the status had changed they were able to help us fly standby.

Clients sometimes tell us that we’re the most responsive vendor they’ve worked with. And–though Tonya schedules our deadlines with something approaching clairvoyance and Alex is known for lightning-fast coding–it’s not that we have a superhuman ability to get work turned around. It’s just that we know how frustrating it is for our clients to be in the dark if their website is broken or the Dean needs something on the homepage as of yesterday. It only takes a few seconds to say, “Hey, that looks like some bad records in the faculty database. We’ll take a look at it first thing in the morning.” Or to slide the little plastic FLIGHT CANCELLED into its appropriate slot.

Tags: airline, customer service, flying

Even though I assess, evaluate, critique, and praise Web sites for our clients every day, I don’t really use that lens in my normal, everyday browsing of the Web. I mean, don’t get me wrong, badly designed, poorly organized sites annoy me. I might even yell to no one (I work at home most of the time) when I’m frustrated with a site or see something that’s particularly garish. I also note good ideas and generally keep up with best practices. But I don’t waste my time overthinking or reacting to random sites I like or don’t like.

So I surprised myself this morning when I came across the Oregon State Fair’s Web site and was so impressed with its design, functionality, IA, and writing that I actually wrote a glowing, completely unsolicited email to their marketing director. (By the way, I found her email quite easily.)

I know the team that developed this site left no rock unturned. I can tell immediately. There are no weak links: They spent just as much time making sure the writing was spot-on as they did refining the design.

It’s a complete package:

• The design - great, catchy, beautiful, perfect for a state fair
• The IA - clear, easy to navigate, with a touch of unique flair (Big Tomato) that does the double duty of reinforcing brand
• The writing - smart, clever, knowing, funny, succinct
• The functionality - I love My Can’t-Miss List (such a great use of shopping cart technology) and that the big Purchase Tickets graphic on the top of every page

Even when our involvement on a client project is limited to design or strategy, we always emphasize the equal importance of these four elements. But of the four, writing is often overlooked until well into the project. As a result energy and resources are in short supply when the time comes to focus on content. I look forward to the day when all the RFPs we receive include a section on writing; when Web committees allocate a line item in the budget to content development before the project even starts.

I don’t mean to overemphasize writing, but as the lead IA strategist and content developer at White Whale, it’s something I fret about all the time. I let the other guys worry about functionality and design. In the end, sites succeed when it all comes together.

I haven’t been to a state fair since I was in high school but I’m going to this one. Amazing what a great Web site can do.

Tags: design, IA, inspiration, state fairs, writing

Optimization is one of the most enjoyable parts of software design, but unfortunately it does not claim a high percentage of development time. Generally speaking, it is not a task to consider until the time spent is justified, which is often toward the end of the development cycle (but not always!) Still, it is an important step, especially with products like LiveWhale, which has to perform well under high traffic spikes. I’ve already talked about general page caching before, but fine-tuning a PHP application for speed when something is not cached is also important. Here are some thoughts on how to do just that.

At the code level, LiveWhale is a framework, which means the same codebase is hit for many different types of requests. The question is then: how to achieve high performance with a codebase that has to perform so many tasks and is therefore code heavy. It makes sense to divide code across a handful of files. The objective here is to only load libraries when you need them. A typical request will only use a tiny percentage of the entire codebase, so there’s no need to read a great deal of code from the filesystem and eat up RAM per PHP request. Also, with a modular system like LiveWhale, it is not explicitly known what modules exist that will need to be loaded. An important optimization is one where only the first request to the server has to perform logic to determine what to load. The results of this expensive operation are cached, and all subsequent LiveWhale requests enjoy dramatic savings in the module loader. Continue Reading »

Tags: application, cms, livewhale, optimization, performance, php, speed

I’ve called this post “Introducing LiveWhale News” because I’ll leave “Introducing LiveWhale” to Jason. It’s that big behind-the-scenes project we’ve been hinting about for a bit, and there’s quite a lot to say.

But at the risk of stealing some thunder from that announcement, I’d like to show off something that we’ve been spending a lot of time on:

This is the add-a-news-story page of LiveWhale, the CMS we’ve developed as an answer to problems posed in our infamous (among our clients, anyway) content management manifesto. In later posts I’ll go into some detail about specific interface choices we’ve made (a personal favorite is the flowchart behind attaching images to news stories), but for now I’ll talk about what we didn’t do. Continue Reading »

Tags: cms, interface, livewhale, lwblog, usability

It’s hard to imagine how this industry would operate without open source software. The PHP language that I use to write software for the web is itself free software. Unfortunately, the quality of open source code written with PHP is relatively poor and inflexible compared to the quality of open source libraries that can be compiled into PHP as extensions. Consequentially my personal relationship to open source software is a hybrid scenario of, on the one hand, being deeply invested in open source tools that expand the language I program in, as well as having a commitment to turning out open source projects of my own to the community, and on the other hand, a healthy skepticism toward the bulk of open source software written in PHP. Part of this is due to the fact that, being the chief server side programming language of the web, freely available PHP code could well have been written by your grandmother (apologies to my GM, who happens to be a very savvy user). Continue Reading »

Tags: open source, php

So having said all that, the way we’re handling CSS columns these days is actually pretty cool.  Here’s some sample CSS, from a site in development with a 720px wide content area:

/* Column layouts */
.column { float:left; overflow:hidden;}
.columns { margin-bottom:20px; padding-top:10px; }
.three.columns .first { width:200px; padding-right:20px; }
.three.columns .second { width:200px; padding:0 20px; }
.three.columns .third { width:200px; padding-left:20px; }
.two.columns .first { width:300px; padding-right:20px; }
.two.columns .second { width:300px; padding-left:20px; }

This lets us code the XHTML like this:

<div class="three columns">
     <div class="first column">
         Column 1
     </div>
     <div class="second column">
         Column 2
     </div>
     <div class="third column">
         Column 3
     </div>
<div style="clear:both;"></div>
</div>  

… which is pretty nice semantically.

Tags: CSS, free stuff, tables

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, ie6, internet explorer, png