Posts tagged with ‘lwblog’:

Coding Ahead of Yourself

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 »

Screencast Demo of the Week

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.

Read more »

Converting to Title Case

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 »

Introducing LiveWhale News

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:LiveWhale: Edit Story

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 »

Resizing images to fit

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 »

Internet Explorer 6 in web applications

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 »