We’ve added some frequently asked questions to the LiveWhale public site (www.livewhale.com), as well as a feed of articles about LiveWhale from this blog.
Sticking to the “use your own tools” mantra, we use LiveWhale to edit that site. I can tell you that it is a heck of a lot faster to add items from an externally generated RSS feed to a LiveWhale-powered page— two minutes, give or take a few seconds— than it is to add an external feed to this WordPress-powered blog.
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. Read more »
In the process of developing documentation for LiveWhale, our new CMS, we have begun to record screencasts to demo LW’s features. Often it’s easier to show than tell, when it comes to CMS features; a narrated demonstration lets us inject a little personality. And it’s also a lot faster than writing out a how-to page (although we’ll have to have written documentation as well, it does seem to be the case that nobody will actually read it).
Our first effort, a screencast of LiveWhale’s news system, leaves much to be desired; it’s clear that we’re new at this. It’s hard to figure out the right tone of voice (how much humor? how fast? etc.), and it took several takes to get through it without messing anything up. (And we still had to edit the final product a bit.) I’m sure it’s something we’ll continue to refine and improve as we continue developing LiveWhale’s documentation.
All of this is to say that I just watched the most effective screencast demo I’ve seen in a long time, if not ever.
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:
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?
From the archives of Tales from Redesignland, one of Tonya’s favorite blogs:
The fact is, we aren’t claiming that LiveWhale does everything— that’s part of the point. It does what its users need it to do.
But maybe its successor, EpicWhale™, will make all other communication obsolete.
UPDATE: I don’t use Twitter enough to get the Fail Whale when it’s overloaded. Now the comic makes much more sense!
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. Read more »
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. Read more »
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 »
About a month ago, we reached one of those crossroads in the development of our (coming very soon) content management solution. Our development process is typically to develop a perfect standards-compliant site and then reverse-engineer a working Internet Explorer copy out of that–usually through painstaking pixel-by-pixel corrections of obscure bugs in IE-specific stylesheets, but also in rare cases where we had to make compromises with the design or markup of the page.
But IE stylesheets can only get you so far. When working with a public-facing website design you just need to get it right once: we make sure the structure is flexible and adaptable and forward-looking, but mainly we build to the best standards of the current day. But because development of our backend solution will be continuous (that’s a hint about a major feature, by the way), continuing to tie ourselves to IE6’s sundry limitations would be crippling down the road. Read more »