Subscribe

Archive for July, 2007

For many businesses, summer holidays are a period of slightly less stress and slightly more time to spare. Time to for example think about redesigning the old website. Traditionally, one would start with a good brainstorm, unleashing (hopefully) everybody’s wildest fantasies and ideas. But soon after, the difficult task of making these dreams reality will soon pop up and somebody will have to create a first sketch of the website.
This is where web mock-ups come into the picture. A web mock-up is basically a sketch or an early layout of a website. In theory, the difference with a prototype is that a prototype is ment to function, even if not fully so, whereas a mock-up is only ment to look like the finished product. But when speaking about a simple website, the two terms can be used interchangeably.

The aim is to quickly concretize ideas without too much hustle. This way, you can test and get feedback even in the early stage of conception. This feedback can than be incorporated back into the mock-up, until it reaches the point where everybody’s happy and designers and developers can take over to create the real thing.

In practice, a web mock-up will look like a number of boxes representing different elements on you pages such as banners, content blocks, navigation etc. No design, no functionality. The only ‘functionality’ that will be really there is the linking between the different pages so the flow of the website can be tested. As an example, I created a small mock-up for a part of the new EmailGarage website. Check it out here.

In prototyping terms, this way of working is also known as ‘rapid prototyping’ which stands for converting abstract ideas as soon as possible into real, concrete proposals which can be iterativaly enhanced using tester’s feedback. Rings a bell? Yep: this is indeed what you can also find in the web 2.0 ‘Getting Real‘ phylosophy.

So how do we do it? What tools are there to create such mock-ups?

Basically, you could catalogue the tools that are most commonly used for creating web mock-ups into 3 main categories:

1. tools for the real prototyper
2. tools for the designer
3. tools for the webbuilder

Category 2 and 3 require specific skills: in category 2 we can find tools such as Adobe Photoshop or Fireworks, which can be used to create grapically perfect-looking layouts. In category 3 we can find the real web-building tools like Adobe DreamWeaver which can be used to create fully functional and picture-perfect websites. Although both types clearly have their merits in the development process of web sites, they are not appropriate for creating web mock-ups.

Below you can find a comparison table of some commonly used (and abused) tools. I tested them on a number of different criteria:
– support for master pages: can you create e.g. a basic navigation frame that is automatically put on all pages without having to copy it to every page? If not you would have to make a correction to the navigation structure of your mock-up on each and every page, instead of just once on the master page.
– support for links on the master page: a number of tools offer support for master pages, but the links put on the master page are lost when you create the final HTML.
– support for page scrolling: does the tool support pages that are longer than one screen?
– support for page notes: the ability to add notes to a page
– support for element annotations: the ability to add extra information to page elements
– export formats: which formats are supported for exporting your web mock-up.
– support for navigation tree: can you create a navigation tree for your mock-up, or are all pages on the same level?
– users: what category of users does the tool address?
– platform: on what platforms can the tool be installed?
– pricing: what does it cost?

Although rather costly, I very much like Axure RP Pro 4. It’s simple user interface and enhanced functionalities allow you to create really quickly good web mock-ups (see also the example above).

Since a couple of months I’m systematically unsubscribing myself from email newsletters and subscribing to the RSS feed equivalent. I just couldn’t handle the massive amount of newsletters any more. It cluttered my inbox, drowned the important messages. My ideal scenario? Using e-mail for personal messages and RSS for all the rest.

However, being an email marketeer myself since quite some years, I was kind of shocked by my own actions. Could it be that RSS is replacing email after all? Is email marketing dead?

It’s in fact a very old discussion on the net. Back in 2004, at the dawn of RSS, RSS believers where quick to bury email alive, waving the spam-flag to prove their point. Email defenders answered with the email’s ease of use and personalization possibilities. It was an endless yes/no game stuck in the same arguments over and over again. Luckily the discussion faded and RSS and email believers alike came to believe that both technologies can peacefully co-exist and complement each-other in the marketing mix.

It took however till the wide-spread adoption of web 2.0 in 2006 for RSS to become a real mature medium of content delivery. Google launched its online RSS reader, blogs made the number of feeds sky-rocket and widgets offered all new possibilities.

So where are we now? Can RSS and email peacefully co-exist? Or is RSS becoming an email killer after-all?

Starting from the great comparison table between email and RSS Alex Barnett put together back in 2004, I created a new, up-to-date, version showing both mediums’ strengths and weaknesses from a marketeer’s and customer’s point of view, and added some remarks:

Remarks

(1) Email has proven a to be great tool for creating a personalized, 1-to-1 feel in mass communication, going from simple personalized salutation to Amazon-like delivery of personalized content. RSS on the other hand is currently mostly used for non-personalized content delivery. With RSS, you can choose the feeds you want to subscribe too, but that’s as far as it goes. The upside for the consumer is that because content isn’t personalized, and because RSS doesn’t require you to give any personal information to subscribe (as opposed to the email address for email marketing), the consumer can see the content without giving away any sensitive data. As soon as the content has to be personalized, the consumer would have to reveal himself. Strangely enough, this is an option that is almost never considered: You could offer the RSS feed subscriber the option to receive personalized content via RSS if he makes himself known. In that case the subscriber would receive a personal RSS feed URL with personalized content, and would he be able to get the best of both worlds.

(2) The viral effect of email has enormous potential. It is very easy for a recipient to add some comments and forward the email. The viral effect of RSS on the other hand was long time a problem. Web 2.0 did however solve this by embracing RSS as a means of content sharing between different social networks like digg.com or del.icio.us. People can comment on stories they received via RSS, add them to their online bookmarks which in their turn can be shared with other people and so on. Feedburner (Google-owned) is one of the big players in this field. It allows you to easily offer your feeds in RSS format and to have your stories submitted to a number of social networking sites. Interesting is that it also allows you to receive new content via email (e.g. the email subscribe link on the right)!

(3) Email marketeers can rely on a set of tools to track the behavior of the email recipients. Click-through, opened and bounce ratios, opt-ins and opt-outs, ROI, … they can all be measured because the consumer has had to make himself known in order to receive the content: he had to give his email address. And this allows the email sender to track all actions back to you, the recipient. Because with RSS the consumer doesn’t have to give any personal information, statistics are less detailed. Unless of course you could convince the consumer to subscribe to a personalized feed (see (1))…

(4) This is one of the major draw-backs of RSS content gathering. Email is much easier to search and archive. Most RSS readers only allow archiving of entire feeds, and for example Google (how strange sounds this?) doesn’t offer a search functionality to search all your subscriptions in its RSS reader (although there is a workaround available).

(5) This is however changing rapidly.

Conclusion

What was true in 2004 looks to be truer still. RSS and email have become two full-blown communication channels that can (and must) exist next to each other. It’s up to the marketeers to adapt to this reality and figure out how they can integrate both channels in their marketing mix.

Personally, I have a couple of rules I follow when I decide whether or not to keep an email newsletter subscription:

If the newsletter content and RSS feed content are identical, I go for the RSS feed

If the newsletter is highly personalized (and I don’t mean just the salutation), I keep my newsletter subscription. If one day however the personalized version of the newsletter would be available through RSS, I might still make the switch.

If the content of the newsletter is highly time-sensitive, I keep the newsletter subscription. RSS feeds have a lower priority than my email inbox.

If the email newsletter offers extras compared to the RSS feed, I keep the newsletter subscription.

If the email newsletter offers a clever aggregation of website content, I sometimes keep the newsletter subscription.

If the email newsletter offers content that is just sporadically interesting and there is no RSS feed, I unsubscribe. I would still rather subscribe to a RSS feed that delivers only once in while an interesting post between a bunch of uninteresting stuff, than to a newsletter offering the same content.

I guess it once again comes down to delivering the right content through the right channel. And RSS turned out to be a channel indeed.

In one of the first posts on this blog, I tried to unravel the web 2.0. Today I’d like to take this idea a couple of steps further by presenting you a mindmap of web 2.0 related terms, technologies and examples in an attempt to guide you through the maze that is web 2.0.

Don’t think of this as a complete, finished, never-to-be-changed sort of thing. This is merely a first draft which I’m hoping to improve and extend using your input.

This post is part of a series of things ‘everybody-assumes-you-know-but-actually-you-don’t-have-a-clue’.
I call them : the Bush Files.
Today : clients, servers and protocols

If you want to understand how the Internet works, why it is you sometimes have to wait for a webpage to appear or why almost every web address starts with ‘http://&#8217;, you must learn about the most important thing that makes the web happen: the client-server model.

The first player in the client-server model is the client. A client can be any program that can access the Internet and wants to retrieve information from it. For instance a web browser, who wants to retrieve web pages, or an e-mail client who wants to retrieve email messages. But in order to get the information they want, somebody has to provide it to them. And that’s where our second player enters the stage: the server. A server is any program that can access the Internet and is able to provide information to the clients. There are servers specialized in delivering web pages, other servers know how to deliver email messages and so on.

You could compare this to going shopping: You, the client, want to get e.g. the latest Radiohead cd (rumoured to be released fall 2007!), and the store (aka the server) can give it to you.

There is however one thing still missing in this story: we assume that the client and server can understand each other! What if you would walk into a record store in China asking for your cd in Dutch? It is very important that the client and the server know how to communicate! That’s why different protocols were invented that define how a request and a response have to be created in order for the server to understand what the client is asking for, and for the client to understand the server’s answer.

For the exchange of web-based information (web pages, RSS feeds etc.), the http protocol is used, which stands for HyperText Transfer Protocol. For the exchange of files, FTP (File Transfer Protocol) can be used, and for the exchange of emails SMTP (Simple Mail Transfer Protocol) can be used. Makes sense, doesn’t it? And maybe you recognize this acronyms? If you enter a URL in your web browser, the first thing you have to enter is which protocol your browser should use to get the information you’re looking for e.g. http://markiteer.wordpress.com.

So, let’s recap using some day-to-day examples:

1. I want to view a web page:
First I type in the web address, let’s say https://markiteer.wordpress.com, into the address location bar of my web browser. My web browser, being a typical client, will then connect to the server where this website resides asking for the web page using the http protocol. The server knows this protocol and can deliver the web page back to the client. The client (your web browser) will then render it for me to view it.

2. I want to read an email:
I open my email reader (e.g. Outlook). Being a client, it will contact a mail server asking it for new email messages using the smtp protocol. The mail server understands what the client is asking for and can deliver the new messages. My Outlook will than render the email messages so I can view them.

3. I want to upload a file:
I open my FTP program (eg. CuteFTP, LeechFTP, …). This client will connect to a server I specify to which I want to upload my file. Using the FTP protocol, the client will send the file to the server. The server will understand this and send back a message that it successfully received the file.

That’s all there is to it. And once you’ve got the hang of this easy principle, the working of most Internet-based applications suddenly will become a lot clearer.