Ravenous Pixel

An informative slide show presentation with audio from the guys at marketingexperiments.com on what the real objective of a headline is supposed to convey. The goal of your headline is not to sell. Define your objective, make it clear, and focus on what elements will make it effective. Questions can work because they can be conversational, but it can just as easily backfire. If the goal of the email is to sell you, then sending a person to a landing page to sell the user again, is not necessary. Understand who you’re talking to and initiate a conversation in a more modest tone by connecting to the reader. Headlines interupt a frantic search or scan of the page, giving the user a glimpse of something promising, while the sub-header provides the key transition, doing the heavy lifting. The headline stops the conversation, and the sub-header re-initiates the conversation sufficiently, leading the reader to the first the paragraph. The first paragraph then begins to do the selling. Cut the copy as much as possible to effectively sell the product or concept.

Three key points that were emphasized:

• Clarity over persuasion or spin, is the reason to move on to the next line.
• Relevance to the audience, communicate it. Connect the value proposition between elements, from headline to sub-header to paragraph to the call to action.
• Credibility is key when a person is inundated with emails.

Watch the full presentation.

Here’s a common sense rant about interface design, which is worth checking out here. These are the main points:

• The application interface should be fast and non-blocking.
• The application interface should be consistent.
• Don’t interrupt users in the middle of common, nondestructive tasks.
• Avoid notifying users of success.
• Avoid giving users information that they cannot use.
• Rare, destructive actions should be harder to complete than nondestructive ones, but always possible.
• Give users the chance to ask for forgiveness rather than forcing them to confirm.
• Deal with application failure gracefully.
• Preserve state, mode, and user input for as long as it is relevant, until users save or discard it.
• Provide multiple, complete navigation paradigms.
• Design the interface before starting to code.
• If the application violates one of these rules because its design makes implementation of a better interface too complex or too difficult, then the application needs to be refactored until it supports a better interface.

Not that I was truly concerned about the demise of Netscape when they announced support for their browser was going to end on March 1st, it barely registered on my radar, I haven’t used NS since version 4. And honestly, since Firefox was released, I haven’t used anything else. That may change, considering what a memory hog Firefox has been lately. Anyways, the question came up about the dual rendering engine when a single customer was having formatting issues regarding one of our sites, which I have yet to identify, since the site looks exactly the same in NS9, as it does in IE and Firefox. Regarding the dual engine aspect of NetScape, I did manage to find out that in NS8, there was a site control option that allowed you to switch between engines, but with NS9, it looks like they dropped support for IE’s Trident rendering engine in favor of the Gecko engine.