Today we got our spam comment number 500,000. Pretty scary to think how much energy, computer power, network traffic is wasted on a completely useless activity: To spoil the content with irrelevant comments.

Currently we get somewhere between 2000 and 3000 spam comments each day.

The thing is, that Thomas and I are discussing: We don’t know exactly how much work our spam filter does for us… Granted, 500,000 spam comments is a pretty high number. But we want to know how much pain this saves us for. How much blood and sweat do we.

I have one suggestion: How about declaring spam-filter free day one day a year. What about December 15th, which is available according to wikipedia?

The purpose of Spam Filter Free day is to

• put focus on how much energy, computer power, network traffic, and manual work is wasted by the completely irrelevant comments
• put focus on spam filters and their current effectiveness
• We remove the filter a saturday, where traffic is usually lower (so the annoyance for the end-users will be as little as possible)

For this to work we have to:

• Disable our secret server-validation (that we use before the comment hits wordpress)
• Disable the plugin that emails subscribers when a new comment arrives
• Disable Akismet
• Disable our blacklist that holds comments for moderation if certain words are in the comment
• Disable the function that holds a comment for moderation if it has a certain number of links
• Disable any plugin that makes spammers gain from the fact that we disable our spam filters. (For instance the “no nofollow” or “dofollow” plugin)

Join us if you like, and drop a comment about it here :) And if you do drop a comment here on December 15th, please forgive us if we accidentally mark a correct comment as spam. We will probably have a hard time cleaning up afterwards. If your comment dissappears, contact us as soon as possible.

Related articles:

• 100,000 Blog Spam Comments (Feb 26th)
• Blog Usability: Spam Comments Irritate Subscribers (April 2nd)
• Spam Commenters Are Wasting Brainpower (September 9th)

Technorati Tags: akismet, spam, comments, justaddwater, blogging, spam-filter-free, spam filter, wordpress

We would like to thank all our readers who keep coming to our site over and over again. By reading and commenting on our posts you guys show us great support. It is because of you that we love doing this.

So what happend since our last birthday? Well we have one thing that we thought we might share with you:

If you want to attract a lot of visitors to your blog, write about something funny. Of our top 5 posts for the last year, one of them was titled “Funny Signs” and the other “More Visual HTML Jokes“. And lets just remember that the “Funny Signs” post was actually not posted within the last year. It’s from May 2006 and still bringing in many visitors each month. This of cause might have something to do with the fact that if you perform an image search for funny signs on Google we are in the top 5. It’s a strange world.

Stats

12 months ago we started to use FeedBurner to manage our feeds. Within that year it has been so exiting to watch our reader stats grow and grow. A couple of weeks ago we pased the magical 1000 feed readers per day:

Put on top of that an average of 400 visitors per day coming to our site from other sources (referrels, web searches etc.) and lets just say that Jesper and I are quite proud to say the least.

Top posts

1. Funny Signs
2. Design for Browser Size — Not Screen Size
3. More visual HTML jokes
4. How to indicate required or optional form fields
5. Live search explained
6. Bad Usability Calendar
7. Ruby on Rails as rapid prototyping tool
8. Lenovo Problem: No Wireless Reconnect After Standby
9. The IE PNG fix vs. Accessibility
10. Replacement for Standard Windows Console

Technorati Tags: happy birthday, justaddwater.dk, humor, blogging, funny signs, top 10

If you have not yet seen it, it’s an

-tag on each side of the Tower of Pisa:

I decided to visualize a few HTML tags myself:

Modified from http://flickr.com/photos/mikemac29/340503313/

Modified from http://flickr.com/photos/jorgeorte/18550828/

Modified from http://flickr.com/photos/maddiedigital/311161230/

Modified from http://flickr.com/photos/anabananasplit/337567708/

Modified from http://flickr.com/photos/idua_japan/258758222/

All photos are Creative Commons license that I found on Flickr via the creative commons search option. If you feel like contributing, we could start a complete HTML tag visualization encyclopedia. Dalager told me he will create a photo pool on Flickr.

Technorati Tags: html, tag, visualization, fun, humour, flickr, photo pool, creative commons

The format I usually use is:

1. Screenshot
2. Description
3. Preconditions
4. Postconditions

Explanation:

1. Screenshot of the entire page or content area
2. Description of the page purpose. Primary action and possible secondary actions on page.
3. Preconditions: What data must be available for the page to render. Where is data retrieved?
4. Postconditions: Data that the user enters. Where is data saved? (Could also be data behavioural data: Example measuring if user completes a purchase)

Then repeat for each screen. Sometimes I also need to document variations of each screen. In that way, each page is repeated with the appropriate screenshots.

One big advantage for me is that documentation tend to become fairly brief and concise. My focus is collaboration over documentation, where the shorter is the better.

What are your experiences with documentation of GUI in a format that is short and concise and easy to maintain?

Technorati Tags: UI, GUI, guide, user interface, documentation, screenshot, precondition, postcondition

It turns out that 88% never use it. Of 4,264 users, only 524 people have edited their links list. That’s 12% that uses (or at least have used it at some point).

I am no exception to the majority. Why should I add a link to my personalized list? The only fair reason is to bookmark an intranet page that’s hard to find.

In my opinion, I’ll prefer better navigation and search features over a personalized links list. And by the way, I’d also use my browser’s bookmark feature over adding favorite links to a personalized website.

That’s why features like personalized links don’t add value, and why such features in general fail.

My finding is similar to what Jacob Nielsen wrote about in his alertbox 8 years ago:

Web users are extremely impatient and want to get something useful out of a site immediately: they don’t want to spend time setting up complex personalization features. This is one of the main reasons Firefly failed.

Because of the paradox of the active user, even a website that relies on personalization needs a good default design to greet first-time users. Again, personalization is proven not to substitute for good basic design. Second, the personalization features have to be extremely easy to set up: no complex or long-winded interactions – or users won’t take the time.

Gerry McGovern wrote Why personalization hasn’t worked in 2003 backed up by a Jupiter research report:

Not surprisingly, the Jupiter report finds that personalized websites are four times more expensive to run. It also finds that personalized websites are twice as likely to attract visitors who will never pay for anything. Worse still, it finds that 25 percent of consumers actually avoid personalized websites because they fear that their personal information will be abused.

Any similar findings on this topic? Examples where personalization works?

You are welcome to share your thoughts, examples and numbers.

Technorati Tags: usability, personalization, jakob nielsen, gerry mcgovern, jupiter, user experience

At UI 11 last week I was fortunate to meet Eidar (photo) from Netlife Research. His usability firm made a Bad Usability Calendar, which is absolutely fantastic. I’m putting the link here directly, as their pages are in Norwegian.

• Bad Usability Calendar 2006 (Direct link, English version, 886 kb PDF), [link to page]

They also did a similar calender for 2005, but unfortunately only in Norwegian.

The calendar is an absolutely must-have asset for any future projects. I see several benefits:

• Good humour makes usability easy to understand
• Easy to understand for all project resources
• Visibility of usability in projects
• An actual calendar that can be used for simple scheduling (at least for some of the months that are not completely covered by popup-windows or similar!)

And I will also print a poster to decorate my manager’s wall next to “The importance of User Experience” poster by Frank Spillers. In my opinion the best visual explanation of user experience.

Update 2006-11-10: 2007 calendar is now open for suggestions.

Technorati Tags: usability, accessibility, calendar, anti-usability, user experience, ux, uxp

Now he posted an article that makes it dead simple to run multiple Internet Explorers. It’s a simple one-click installer that makes you choose any of the following versions of IE:

• IE 6
• IE 5.5
• IE 5.0
• IE4.01
• IE3

Here’s a screenshot of the installer:

Standalone versions of Internet Explorers have been available for a long time. (i blogged about it before back in January and February). The new and best thing is that it’s now dead simple and really really easy to use.

IE7 standalone

Tredosoft also has an installer that installs the most recent version of IE 7 as a standalone program (without removing IE6). It actually works very well for me, and I love that I’m able to test websites with the upcoming IE7 browser (currently release candidate 1).

More info:

• Tredosoft: Install multiple versions of IE on your PC
• Tredosoft: IE7 in standalone mode

Technorati Tags: browser, internet explorer, multiple browsers, ie, ie7, ie6, ie55, ie5, ie50, ie4, ie3, windows, standalone

I generalized it for use with any language, and currently (with the help from contributors) it’s now available for download on rubyforge.

I gave a short plugin demo at our recent Copenhagen Rails Meetup. Olle and Jakob already wrote briefly about it. You can read more (and vote) on agilewebdevelopment page Localization Simplified.

Currently supported languages:

• Danish
• Dutch (thanks Jeroen Houben)
• German
• Spanish (thanks Luis Villa)
• Swedish (thanks Olle Jonsson)
• Swedish Chef
• Pirate Talk (thanks Tobias Michaelsen)

The main reason why I wanted to support Swedish chef and Pirate talk is that I want to remind myself to have fun while coding. And of course it’s a plus that International Talk like a Pirate day is coming up at Sept. 19, arrrh!

What it does

This plugin modifies the following most used helpers for Rails

• Localized errors and error headings
• Localized monthnames on date_select etc. (changing the order of Y-M-D, where Rails allows)
• Localized distance_of_time_in_words
• Localized to_currency (but not changing the order of unit/currency)
• Simple pluralization also available in the lang-file (but currently only used for pluralizing “error”=>”errors” in local language)
• Uses standard Rails methods. In this way, there is no tedious rewrite of localization functions in your view files

There are some FIXME’s in the code and any help on the plugin is appreciated.

As I’ve written in the Rails Core group, this plugin does some work that I hope will be worked into the Rails framework for easier future internationalization.

An example: distance_of_time_in_words() are hardcoded and translated into at least 4 different l10n plugins. If it changes in Rails Core, ALL the plugins must be fixed to ensure that the new code is copied to the plugins.

Seen from the perspective of a localized app, there should be as few dependencies as possible, so making hooks available for localization is preferred. In the example above, the texts should be available as a variable (like the error messages in ActiveRecord).

This would be an ideal solution to some of the most important i18n related issues, and I’d like to know the view of the community on this point.

From my post “i18n-friendly, plugable Rails core” in the Ruby on Rails Core list.

It’s my hope that the Rails Core team will acknowledge that it should be easier to localize your application. (Today, many text strings and date/time/currency formats are hard coded and difficult to overwrite).

Technorati Tags: ruby on rails, rails plugin, simple localization, l10n, i18n, internationalization, danish, swedish, dutch, spanish, german, swedish chef, pirate talk, pirate day, translation

Jakob Nielsen discusses screen resolution and page layout in a recent Alertbox article.

Optimize Web pages for 1024×768, but use a liquid layout that stretches well for any resolution, from 800×600 to 1280×1024.

As usual, Jakob offers some decent facts and clear guidelines on which screen resolution to design for. I have the deepest respect for Jakob Nielsen and the work he does to make usability easier to understand and use for everybody. There is just one problem: Findings should focus on browser window size and not screen size. (More precisely, browser content area, which we’ll get back to shortly)

Currently, about 60% of all monitors are set at 1024×768 pixels. In comparison, only about 17% use 800×600 so it’s obviously less important to aim at perfection for these small-display users. What’s equally obvious, however, is that you can’t simply ignore 17% of your customer segment by providing a frozen layout that requires more screen space than they have available.

People working professionally with web know the difference between screen size and browser content area, but to make it clear I wanted to illustrate that screen size is irrelevant in comparison to other more important metrics.

To illustrate the difference, look at these examples that show the difference between screen size and browser content area.

1024×768 screen resolution gives 1004×598 usable content
area (maximized Internet Explorer window, Windows XP)

800×600 screen resolution gives only 778×430 usable content
area (maximized Internet Explorer window, Windows XP)

The figures show that the “browser real estate” available for actual content is smaller. This is what I call “content area”.

You might notice that browser window height in the screenshots above is smaller than screen size. This is because of the Windows XP task bar that is 30 pixels high in the standard configuration.

Likewise, the standard browser toolbar, statusbar, scrollbar subtracts an additional 22×140 pixels. (That’s what sometimes is referred to as “browser chrome”. So, in general operating system and browser window consumes 22×170 pixels.

Does this mean that we’re safe if we optimize for 1004×598? Well, not entirely. Jakob mentions that

screen sizes vary among users. Window size variability is even greater, since users don’t always maximize their browsers (especially if they have large screens).

I wanted to take this quote and the other facts from the article and show it in a tabular format:

Screen real-estate available for browser. Source: Jacob Nielsen’s article “Screen resolution
and page layout“. The blank fields show what is not mentioned explicitly in the article.

• Percentage is the users that have the given screen size.
• Maximized window is how likely users are to run browser maximized (no other programs visible)
• Max available content area is the absolute largest area for content visible (when reserved pixels for operating system and browser is subtracted).

My problem is that often people are not using a maximized browser, but a browser window that’s actually smaller than the entire screen. An that’s why speaking of screen size is irrelevant to other metrics, such as browser content area.

Browser rarely maximized

18% of all web users who use big screens (above 1200×1024), including me (and most of my web developer colleagues). I also fit perfect on the other finding: I never surf with my browser maximized. Here is what my laptop screen looks like:

Notice that even though I have a wider screen, the actual browser window is smaller than a maximized browser on 1024×768.

So to sum this up and fill in the missing data from Jakob’s article:

Screen real-estate available for browser, based on findings by
Jakob Nielsen with added data by me.

No stats on browser window size

Unfortunately, I know of no statistics on browser window size. Every major stat company and analytics tool measure screen size.

My own experience (by watching people’s browsing behavior) follow what Jakob has found. On smaller screens, people tend to maximize browser window.

Jakob, I really hope that you update your findings with this adjustment, because it only adds to comfusion especially when working with clients that have not spent their entire working life on the web.

Proposed update of text

Therefore I decided to update all figures in the article so that it reflects browser content area in stead of window size.

• Optimize for 1004×598, which is currently the most widely used browser window size. Of course, the general guideline is to optimize for your target audience’s most common resolution, so the size will change in the future. It might even be a different size now, if, say, you’re designing an intranet for a company that gives all employees big monitors.
• Do not design solely for a specific monitor size because screen sizes vary among users. Browser window size variability is even greater, since users don’t always maximize their browsers (especially if they have large screens).
• Use a liquid layout that stretches to the current user’s browser window size (that is, avoid frozen layouts that are always the same size).

My modified version of Jakob Nielsen’s Alertbox “Screen resolution and page layout“, July 31, 2006. My modifications: browser window size instead of screen size.

I really wanted to put in a smaller number than 1004×598 in order to take the big-screen users into account. However, I really don’t know any enough metrics to make a well-argumented decision.

Conclusion

Web designs should optimize for a maximum available browser window of 1000×600 pixels. As screens get better and bigger, users rarely maximize browser windows, which is why we’re probably better off optimizing for a smaller window, such as 900×600.

Still, the layout should be liquid so that content fill the users current browser content area, regardless of the size. Also, do not design for a specific browser window size, as it varies between users, especially users with large screens.

I’d like to hear your comments on this. Do you know of any metrics or study on browser window size? Any stat tools that actually measure the browser window size? What are your own experience with regards to browser window size that’s used?

For the user test I have been involved in, every test leader started by maximizing the browser window. That off course would bias any findings with regards to browser window size, so any observations from field studies and similar are welcome.

Technorati Tags: usability, screen size, screen resolution, browser, web design, liquid layout, window size, jakob nielsen, web statistics

Also, I attended Jesse James Garrett’s seminar (“defining the user experience” – my notes) last month, and got a better understanding of how Jesse’s original thoughts on user experience were defined.

Thomas Baekdal on The Battle Between Usability and User-Experience:

User-experience is not like usability – it is about feelings. The aim here is to create happiness. You want people to feel happy before, during and after they have used your product. To do that you need to take all kinds of things into consideration. Things like: Environment,Colors moods, Smell, Touch, [...], Show-off effect, Usefulness, etc.
This is much much much harder to achieve. None of these things can be accurately analyzed. It is a touchy feeling kind of thing.

Why, for instance, does a Audi S6 give you a much better user-experience than a Ford Focus? I mean, in terms of usability they are pretty much the same.

UXP for the development team

Jesse’s conference was about “defining the user experience”. User experience, the way he defined it that day, was focused on how teams organize to provide web applications with high user experience.

He went though the five planes of user experience (simplified below):

1. user needs/objectives
2. Functional
3. interaction design
4. interface/information design
5. visual design

Focus was on how to do it – not from the end-users perspective, but from the perspective of the web development team.

UXP for the philosopher

Mike Kuniavsky from his profile page on Amazon:

No single accepted definition of the user experience exists (Jesper Rønn-Jensen does a good job of describing the problem in his blog).

[...]

Usability does not equate to user experience. The specific boundaries vary with each product, audience and situation. I have found the following to be a decent working guideline: The user experience consists of all of the factors that influence the relationship between the end user and an organization, especially when a product mediates that relationship.

The key part of this definition, for me, is the relationship of the organization to the product. To me, the user experience is incomplete without a consideration of the organization that created the experience. The end result is the intersection of an organization’s goals and that organization’s understanding of users’ goals, and it’s the designer and researcher’s role to mediate a compromise between these.

I’ve always been an admiror of Mikes work (ever since I heard the Wired/Webmonkey interview mp3 with him around 1998-2000). His book, Observing the user experience, was also pointed to by Jesse James Garrett. I have the book, but only got through a few chapters. (Note to self: Should definately pick up the book again — especially now he’s linking to the stuff I wrote)

Mike’s got a point: I like the tight coupling between user experience and the organization (the sender, the product). But then, it’s not really a tangible, easy-to-use definition. I want something that everybody can understand. Users, web developers, designers, business analysts, clients must all be able to agree on the same definition and understand the definition in the same way. In my opinion this tends toward being too philosophical.

UXP for the pragmatic

That’s why I really like Thomas Baekdal’s ending notes in his discussion: “Make it easy to be happy”:

Make it easy to be happy

It is far from easy to create a great product on demand, but it is possible.

First of all, do not focus on usability or user-experience. Do not directly try to achieve to create synergies. Do not try to create a great product. None of these things will get you any closer.

Focus on making it easy to be happy, and usability, user-experience and greatness will come all by itself.

• Instead of making a product management web application, make it easy to finish great projects.
• Instead of making usable instant messaging, make it easy to have interesting conversations.
• Instead of making a powerful web writer, make it easy to write exciting stories.

The result is that you use usability to take away all the things that distracts you from happiness, and you use the elements of user-experience to empower what people can do… and now you got a great product.

I really like this approach to user experience. Not specific for web development teams and experts. Very pragmatic and very easy-to-understand.

Finally, revisiting the diagram by Bryce Glass (soldierant) and Frank Spillers.

Your web application should hopefully help users get “a positive experience” as stated on the diagram. Compare this to Baekdal’s philosophy, which is much more focused on how to get there:

Focus on making it easy to be happy, and usability, user-experience and greatness will come all by itself

It fits well, and can help web teams to focus on user experience, still having a usable website. It does it well in a way, that end-users can also understand.