David, Paul and I have just finished launching our latest product, Fingerprint!

From the Fingerprint home page:

There has been no way to get accurate, up-to-date statistics on email client usage. Until now.

Fingerprint shows you which email clients your readers are using.

Knowing which email clients are popular means you can be certain your messages are being displayed as you intended. Get actionable statistics within 24 hours of sending your next campaign.

Fingerprint is a clean, simple idea, and the data we've received so far (on our own mailing lists) is proving incredibly valuable; we had no idea 6% of our subscribers read our emails on an iPhone!

How does it work?
We give you a small 'bug' to put in your email, it's a small bit of HTML that we use to track which clients your subscribers are using. Every 30 minutes we update your analysis with the latest stats from your readers. The site offers percentages, and there's a spreadsheet you can download with a full breakdown of clients and quantities.

How much does it cost?
We're charging just $39 per analysis. An analysis is a two week snapshot of your subscribers' email client usage.

Why should I care?
Good question. It's very hard to know which clients to design your html email newsletter for, and with clients such as Lotus Notes 6-8 and Outlook 2007 out there, it's often unrealistic to design for all of them. Especially since there's a growing number of smaller, web-based clients. Do you know how many of your readers are using these?

Fingerprint gives you a single report answering all these questions, and allows you to make a firm, informed decision on which clients to design for and support.

From the data we've seen passing through so far, you'll be amazed at the results. During development, Paul, David and I had talked about what sort of results to expect, Outlook would be high, naturally, we also expected Gmail, Yahoo, AOL and Hotmail/Live mail to be up there. So far only Outlook has proved as popular as we expected, the iPhone was a notable surprise for our own list, with Lotus Notes making an unexpected appearance as well.

I can't wait to see the overall averages per industry!

Litmus makes compatibility testing easier by serving you screenshots of your web pages and email newsletters in a huge range of browsers and clients across all 3 major platforms.

We've recently launched another wave of updates for Litmus, including some brand new price plans, a totally free version and a brand new marketing site!

To mark the occasion, I've drawn up the last year of updates into a quick, '60 second' list.

Aug 2007 SiteVista becomes Litmus.
Sep 2007 Opera 9.5 and Yahoo! mail join the line-up.
Oct 2007 Automated validation added.
Nov 2007 Seeed.org, a community site, launched.
Jan 2008 Spam filter reporting for webmail clients added.
Feb 2008 Bulk-API announced, new partners begin integrating Litmus immediately.
Mar 2008 24-hour passes launched, they become our most popular product overnight.
Mar 2008 Internet Explorer 8 beta is announced by MS, it's available to all Litmus users within a few hours.
Mar 2008 New updates system announced, powered by Twitter.
Apr 2008 Lotus Notes 6.5, 7 and 8 are added to the testing suite.
Apr 2008 Safari 2, 3.1; Camino 1, 1.6 are added.
Apr 2008 Apple Mail 2.1 and 3.1 added.
Apr 2008 Konqueror and Firefox on Ubuntu added.
May 2008 Customer API released.
Jun 2008 Spam filter reporting for 17 spam clients/services begins beta testing.
Today So impressed with Litmus, you sign up and marvel at how easy compatibility testing has become.

As if all that wasn't enough, we've got another product up our sleeves - more about that shortly!

David Smalley, who I work with at Litmus, has recently released Shout, a merb web app.

It's a great idea; we've been using it internally at Litmus and I can't recommend it enough.

I've been at BarCampSheffield this weekend and it's been a lot of fun!

Within the first 2 hours I'd learnt more from casual conversations with people than I learnt during the whole 3 days at MIX07.

We saw demos from some great other applications - MeeCard and aFeeda in particular stood out.

I gave a ThinkFold demo as well, it went really well - I had 4 people from the audience come up and enter their email addresses to share the outline I'd used to build the presentation.
The feedback was fantastic, plenty of stuff we'd not thought of yet and some great tips on how to improve it further.

Thanks to everyone that participated in the demo, people had some very nice and constructive things to say about ThinkFold inside the outline:

"This is very clever, seriously impressed"

"Awesome."

We also had some great questions:

How long did it take to code this?

Around 15 weeks of development spread over a year.

Will you integrate this with any third party sites?

Yes and no - we want to create the platform for people to do that, primarily consuming other products' APIs within a ThinkFold document, but later sending data directly into 3rd party services.
I expect I'll get stuck in and build a few basic ThinkFold plugins myself, stuff like a google define plugin and an 'outline a page' plugin - but more importantly we want anyone to be able to create one that works with their service.

Thanks again to everyone that voted for ThinkFold in the 'Best Web App' competition as well! (We came 2nd - the MeeCard guys just beat us to it ;-)

I've released Flare under the GNU General Public License and hosted the project on GoogleCode, I've thrown together a landing page on this site for now:

http://flarenow.com/

Since all of Flare's comments, bug reports and suggestions live in the comments of the post announcing Flare I'll keep using that until something more suitable is found.

If you'd like to contribute or help in any other way - let me know!

Recently, Dave, Paul and I were laughing about how, when very new to developing, we would place artificial delays in our loading 'splash' screens (this was a long time ago, if you're worried :). The very idea of making the user wait for no reason seems absurd now, but it got me thinking about why we did it (ultimately our goal was the same as it is now - that our product be useful and valuable to the end user).

I think we did it because we wanted the user to think our app was big, powerful and did so much important stuff it couldn't possibly load in under 3 seconds. It's interesting that we associated a long waiting time with a better, more powerful app.

Now, I'm not proposing we all start forcing our users to wait 3 seconds before every page load, but there's definitely something to associating longer waiting times with more 'power' - and therefore smaller waiting times with small, simple actions.

Of course, the first time we request an action be performed we have no idea how long we will have to wait. But after just a few requests of an action (such as clicking a button) we'll begin to associate that action with a degree of waiting. After a while, we begin to make decisions about how we use software based on the time we expect to wait for the requests we can make. There are often many alternatives to achieve similar results (for example, I will often Ctrl+click links in a browser to open them in a new tab in the background as I know that action will take a few seconds to complete and I wish to stay reading the current page while waiting for it.).

Armed with this knowledge base of actions and their associated delays, we then begin to weigh the expected delay with the expected result in every decision we make.

Take Adobe Acrobat Reader for example, I rarely click PDF results in a Google search because I associate the “[PDF]” tag with an action that doesn't yield a result that justifies the expected delay. Now I can't possibly know how valuable the content of that PDF will be to me before I open the PDF, so why does my mind decide the delay doesn't justify the result? Perhaps it is because my mind compares the opening of a PDF in my browser to the opening of a normal, html web page. The request for the action is similar and the result is identical (text, images, form elements) - so why wouldn't it be disappointed with the result after such a considerable delay when compared with opening a web page?

With this in mind, the use of AJAX becomes very important. Requests for actions in web applications can be associated with small, simple actions (a simple AJAX request) and longer, more powerful actions (a page postback).

Consider every request in your web application. Does the delay reflect the result of the action? This works both ways; it should not be possible to invoke more powerful actions with significant results via a small, quick request. Say I wish to delete a task item, such a small action should not have a delay, but if I want to delete a task list of 500 tasks? From a technical point of view this action will not take any longer (as far as the client-side view is concerned) but to the user, this action is huge. So what do we do? Artificially delay the action's result so the action's delay reflects the power of the action?
One idea is to bloat the delay by prompting the user to confirm their action. This is certainly worth considering, but falls down as it doesn't reflect the size of action. If I attempt to delete a task list with a single task, I would consider this a small, quick action. If I attempt to delete a task list with 500 tasks, I expect a longer, more delayed action. It's this delay that allows my brain to build a knowledge base of actions and their associated delay so I know in future which actions can be performed with little thought or attention and which actions I need to think through before requesting.

The time delay between requesting an action and getting results back is an ideal, Real variable that we can use to quantify an action's 'size' in a user's mind.

Sure, I don't know how long an action will take before I request it, but it doesn't take long before I've built up that knowledge base and I can switch off or focus on other things while using the application - until I'm about to request an action that I know is big, then I'll give it all my attention before clicking that 'delete all tasks' button.

We're getting very close to launching ThinkFold's private beta and I'd like to give readers of my blog the first chance to sign up.

Click here to access the future ThinkFold homepage.

To sign up, enter your email address in the sign up form on the right of the page. We'll let you know as soon as ThinkFold is ready for you.

At this early stage we're particularly interested in two types of people - those that have never outlined (to make sure that ThinkFold is the best possible introduction to outlining) and those that are experienced outliners (to make sure ThinkFold stands up to the competition).

Of course, everyone is welcome - but if you have never outlined before, or don't know what it is, I'd really recommend trying out the ThinkFold beta once it's ready. Outlining is a fantastic thinking tool that I only discovered myself just over a year ago.

We do ask that you give feedback via the web app as often as you can, it's very easy to use and doesn't take you away from your current, open outline.

ThinkFold?
Wikipedia on outlining:

An outliner is a special text editor that allows text to be structured as an outline.

Outliners are typically used for computer programming, collecting or organizing ideas, Getting Things Done, or project management.

ThinkFold is an online outliner that allows you to share outlines with other users and edit the document together, in real-time.

It's fast, reliable and I'm sure you'll find it an invaluable thinking and planning tool, both when alone and when collaborating.

As always, feel free to contact me: matt@mattbrindley.com if you have any questions.

I'll also be hanging around in my campfire room: http://mattbrindley.campfirenow.com/85df4.