Friendly Bit - Web development blog

Partial XMLHttpRequest responses?

2012-01-08T15:28:49+01:00

We all know how to make an AJAX request, and fetch some data. But as soon as you need to fetch data incrementally, have the server push data to you, you have to resort to all sorts of complicated stuff. Websockets; with all their different versions and shady support, different kinds of polling, hidden iframes, ActiveX for IE?

The simplest way, that almost workds is partial XMLHttpRequest responses. I first read about them as progressive xmlhttprequests on Kyle Schulz blog, but really think that method should get more recognition.

Note: I've only tested this with Webkit, against Twitter's Streaming API, with a XMLHttpRequest that allows cross-domain requests. I think it works with Firefox too, but it will definitely not work in IE. Sorry.

var xhr = new XMLHttpRequest();
var url = "<streaming-url-on-you-own-domain-or-CORS>";
xhr.open("GET", url, true);
xhr.send();
// Define a method to parse the partial response chunk by chunk
var last_index = 0;
function parse() {
    var curr_index = xhr.responseText.length;
    if (last_index == curr_index) return; // No new data
    var s = xhr.responseText.substring(last_index, curr_index);
    last_index = curr_index;
    console.log(s);
}
// Check for new content every 5 seconds
var interval = setInterval(parse, 5000);
// Abort after 25 seconds
setTimeout(function() {
    clearInterval(interval);
    parse();
    xhr.abort();
}, 25000);

The biggest problem with this method is that the responseText property keeps filling up with data. The longer you receive data, the bigger the data in memory will be. The only way I can see this fixed (today) is to simply kill the connection after a certain amount of data has been received, and open it up again.

I would love to see a better way to do this, from native javascript, without all the numerous hacks that are out there. If you know of a way that fills these requirements, please let me know:

Easy to implement on the client side. Ideally I would like to use XMLHttpRequest, and just get a callback each time the client sends data, with the NEW data specified as a callback parameter.
Easy to implement on the server-side. I can set some headers if you make me, but ideally I would like to use this against existing Streaming APIs (like Twitter's), without adding custom stuff.
As cross-browser, cross-platform as possible.

Is there a way to get this working? It's so annoying to see something that's a curl one-liner, be 100s of lines of code with web technologies…

curl https://stream.twitter.com/1/statuses/filter.json?track=<your-keyword> -u <your-twitter-nick>

Is the web really that far behind?

Geolocation and Google maps

2011-06-18T14:11:11+02:00

Image by heiwa4126 via Flickr

Google Maps has has geolocation support for a long time, but I still find people surprised of how it all works. So here's a short writeup, skip it if you already know all about geolocation.

Lets start at the Google Maps frontpage. Among the zoom controls, above the little old man, there's a button in the form of a small circle. It does not look like much, but what it's doing is incredibly cool. Click it and the map moves to where you are, with an accuracy of ~20 meters. Sci-fi crazy!

How does it work? In the newer browsers (all but IE6, IE7, or IE8) may ask you for your positioning information from the browser. It usually shows up as a bar at the top of the browser. The browser then gathers two specific forms of positioning information from your computer: your IP address and the signal strength of any wireless network near you. That information is then sent, if you approve it, to Google, which returns the coordinates you are at the moment.

Google can do this because they've been driving around with their street view cars all over the world, and measured signal strength of WiFi networks (public and private) at each specific location. Now they can use that information, combined with your local signal strength conditions, to triangulate their way to where you are. And it's both accurate and fast.

If your wireless reciever is turned off, or you're at a stationary computer, all calculations are based on the IP number. These kind of lookups are quite arbitrary and inaccurate, I just get to the nearest big city when trying to use it over a non-wireless line. But mobile connections are slowly taking over landlines, so I guess this problem will solve itself automatically.

The best kind of technology throws you forward in time, and make your realize that we're actually making progress. Geolocation has feel to it.

Looking for the techy explaination of geolocation? Have a look at Robert Nyman's writeup.

Animate from one element to another (jQuery plugin)

2011-05-05T22:52:14+02:00

Image via Wikipedia

Have you even tried clicking an "Add to cart"-button and not understood what happened? I have. An although I understand the idea of adding a product to the cart, and then letting the user continue browsing from where he is, I still get stumped when "nothing happens" when I click the button. So what to do?

Simple: Add a animation from the add button to the cart. That way you communicate what just happened. "The product moved in there, and by clicking the cart you'll find it again. Now continue buying stuff!".

Somebody must have done this before, so I started looking for a jQuery plugin to do this (jQuery was already on the page, so why not?). I found add2cart - A plugin that looks good, but that misses a few features I wanted:

The animation duration is set in seconds, meaning products further down the page will move faster than those further up. I wanted constant speed.
It didn't allow me to customize the look of the animated element.
The code rely on concatenating strings of CSS and generally could use lots of improvement.

So I did what anyone would do: rewrote the code from scratch, and posted it on GitHub.

Get the code: Animate From To 1.0

It's my first jQuery plugin ever, and my first public GitHub project, so let me know if I've done something wrong. Is this something that could be useful in one of your projects?

Lazy Loading Asyncronous Javascript

2010-05-08T00:15:06+02:00

Update: This is no longer the best way to load scripts. Use a script tag with async and defer set instead.

Like many of you might know, I'm working on a site called Kundo with a couple of friends. It's kinda like a Swedish version of Getsatisfaction, which means we have a javascript snippet that people add to their site to get feedback functionality. Cut-and-paste instead of writing the code yourself. Simple.

The problem is, how do you load an external javascript with minimal impact on your customer's sites? Here are my requirements:

Small. I don't want a big mess for them to include on their sites. 10-15 lines, tops.
Stand-alone. The environment is unknown, so we can't rely on any external dependencies, like javascript libraries.
Cross-browser. I have no idea what browsers my customer's customers have, so I can't do anything modern or fancy that isn't backwards compatible. I assume at least IE6 and up though.
Asynchronous download. The download of my script should not block the download of any script on their sites.
Lazy Loading. If my site is temporarily slow, I don't want to block the onload event from triggering until after our site responds.
Preserve events. Any events used should not override any events on the customer's site. Minimal impact, like I said.
Don't pollute namespace. Global variables should be avoided, since they could conflict with existing javascript.

Note: I did not make all of this up myself. Lots of people did, I'm just writing it down for you. Thanks: Jonatan, Steven, Peter, and Linus.

Script tag#

<script src="http://yourdomain.com/script.js"></script>

While being the stand-alone, cross-browser, and the shortest piece of code possible; it doesn't download asynchronously and doesn't lazy load. Fail.

Screenshot from Firebug's net console: The script (set to load in 2 seconds) blocks the download of the big image (added after the above script tag, and used throughout this article as a test). Onload event (the red line) triggers after 2.46 seconds.

Async pattern (A script tag written with javascript)#

Steve Souders, the web performance guru, has compiled a decision tree over different ways to achieve non-blocking downloads. Have a look at that graph.

Since we're on a different domain, and only have one script (order doesn't matter), the solution is given: We should create a script tag with inline javascript, and append it to the document. Voila! Non-blocking download!

(function() {
    var s = document.createElement('script');
    s.type = 'text/javascript';
    s.async = true;
    s.src = 'http://yourdomain.com/script.js';
    var x = document.getElementsByTagName('script')[0];
    x.parentNode.insertBefore(s, x);
})();

Note: async is a HTML5 attribute, doing exactly what we're trying to simulate with our hack, so it's added for good measure. Also, wrapping the code in an anonymous function prevents any variables to leak out to the rest of the document.

This is a pattern that is getting more and more popular nowadays, especially since Google Analytics uses it. But there's an important distinction here: The above snipped blocks onload from triggering until the referenced script is fully loaded. Fail.

Update 2010-09-01: Steve Souders adds that the above is only true for Firefox, Chrome, and Safari, but not IE and Opera. So for a IE-only site, this might be the best method.

Screenshot from Firebug's net console: The script (set to load in 2 seconds) downloads in parallell with the big image. Onload event (the red line) triggers after 2.02 seconds.

Lazy load pattern (Async pattern triggered onload)#

So, how to you make sure you don't block onload? Well, you wrap your code inside a function that's called on load. When the onload event triggers, you know you haven't blocked it.

window.onload = function() {
    var s = document.createElement('script');
    s.type = 'text/javascript';
    s.async = true;
    s.src = 'http://yourdomain.com/script.js';
    var x = document.getElementsByTagName('script')[0];
    x.parentNode.insertBefore(s, x);
}

This works, but it overrides the onload event of the site that uses the script. This could be OK in some cases, where you have control over the site referencing the script, but I need to cater for that. Fail.

Unobtrusive lazy load pattern#

The logical solution to the above problem is to use an incarnation of addEvent. addEvent is simply a common name for an cross browser way to take the current function tied to onload, add it to a queue, add your function to the queue, and tie the queue to the onload event. So which version of addEvent should we use?

There's been competitions for writing a short and compact version of addEvent, and the winner of that competition was John Resig, with this little beauty:

function addEvent(obj, type, fn)  {
  if (obj.attachEvent) {
    obj['e'+type+fn] = fn;
    obj[type+fn] = function(){obj['e'+type+fn](window.event);}
    obj.attachEvent('on'+type, obj[type+fn]);
  } else
    obj.addEventListener(type, fn, false);
}

Note: This is unsafe code, since it relies on serializing a function to a string, something that Opera mobile browsers have disabled.

Thing is, we don't need all that generic event stuff, we're only dealing with onload here. So if we first replace the type attribute with hardcoded 'load', replace obj with 'window', and remove the fix for making 'this' work in IE, we've got four lines of code left. Let's combine this with the above lazy load pattern:

(function() {
    function async_load(){
        var s = document.createElement('script');
        s.type = 'text/javascript';
        s.async = true;
        s.src = 'http://yourdomain.com/script.js';
        var x = document.getElementsByTagName('script')[0];
        x.parentNode.insertBefore(s, x);
    }
    if (window.attachEvent)
        window.attachEvent('onload', async_load);
    else
        window.addEventListener('load', async_load, false);
})();

This is exactly what we're looking for here. Finally!

Screenshot from Firebug's net console: The script (set to load in 2 seconds) downloads after the onload event has triggered. Onload event (the red line) triggers after 0.41 seconds.

And that wraps up this article: Different tactics works for different scenarios, and only understanding them all makes you capable of picking the right one for your problem. As always, I'm waiting for your feedback in the comments. Thanks for reading!

Rendering a web page – step by step

2010-01-11T01:04:33+01:00

Have you ever thought about what happens when you surf the web? It's not as simple as it seems:

You type an URL into address bar in your preferred browser.
The browser parses the URL to find the protocol, host, port, and path.
It forms a HTTP request (that was most likely the protocol)
To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host
Then a socket needs to be opened from the user's computer to that IP number, on the port specified (most often port 80)
When a connection is open, the HTTP request is sent to the host
The host forwards the request to the server software (most often Apache) configured to listen on the specified port
The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)
The plugin gets access to the full request, and starts to prepare a HTTP response.
To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request
Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
A DOM tree is built out of the broken HTML
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
The browser renders the page on the screen according to the DOM tree and the style information for each node
You see the page on the screen
You get annoyed the whole process was too slow.

I, too, get annoyed when the above steps take longer than one tenth of a second. But now at least I have some documentation to look at, while waiting the remaining fractions of a second before the page renders.

Spoiled we are, all of us.

(Feel free to add more steps, through the comments…)

Make a div clickable

2009-06-30T22:53:25+02:00

We all dislike that links are so small, and hard to click. So of course we want to make the clickable areas bigger. Some would think that doing this with some CSS on the a-tag would be a good way, but then you can't have block level elements inside it (you'll get a validation error if you try to put headings or paragraph tags inside of links). So what's a more general solution?

My take is to use a div instead, and use javascript, of course together with a good fallback. When clicking the div, find the first link inside it, and go to that URL. It's simple, and with a few additional quirks, it gets really useful.

Javascript code (requires jQuery):

$(document).ready(function(){
   var block = $(".teaser");
   block.click(function(){
      window.location = $(this).find("a:first").attr("href")
   });
   block.addClass("clickable");
   block.hover(function(){
      window.status = $(this).find("a:first").attr("href")
   }, function(){
      window.status = ""
   })
});

CSS for showing that the div actually is clickable:

.clickable {
   cursor: pointer;
}
.clickable:hover {
   background: #efefef;
}

A clickable div demo is of course available.

How it works#

When the div (or other tag, you choose) is clicked, find the first anchor tag, get it's href attribute, and go there. Relying on an actual link means you always have a fallback, so no cheating.
When javascript is disabled, it just falls back to a regular block, where only the links are clickable.
A class called "clickable" is set on the block to allow for javascript-specific styling, such as changing the cursor with cursor: pointer, something you don't want to happen when the block isn't clickable.
The changing background color on hover is done with CSS, which I think is fair, considering the small percentage of users using IE6. Changing background color isn't a must feature.
Lastly, since we're simulating a link here, it should show where the link is going. I've done this by setting the statusbar to the link location on hover, something that's useful when it works (users can disable this in some browsers).

Hope that little snippet is useful for someone out there, I think it's a good example of good use of javascript.

Interface developers and security

2009-01-24T00:30:44+01:00

You live in a new era, when demanding that people register on your site is no longer enough. There's far too many other sites out that that you're already a member of, you don't need another one. You need to trust people.

You also want people to contribute to your sites with content somehow. Text is not enough, you want all kinds of "rich" content, and you want people to be able to place them how they want on your page. I mean, we live in a new era after all.

Problem is, this new era thingie talk makes people forget the basics. Even though this is the future, and we're all bored with "just" hypertext, we can't allow random people to add HTML to our sites. Why? Ask myspace about the Samy worm from 2005, a little piece of clever front-end code that took their servers flying. What did they do wrong? They tried to let untrusted people embed HTML on their profile pages.

But they even had this clever filter, which cleaned the code first! Well, long story short, using a div with the style attribute set to a background image that points to a javascript url actually execute the javascript in IE6. Didn't think of that did you? So what about the fact that both IE6 and IE7 execute vbscripts in urls prefixed with "vbscript:", just like with javascript. Didn't know that? Ohhh. Perhaps then you shouldn't be trying to let unknown people embed HTML on your site?

Many of these security issues stem from the fact that ordinary well-educated computer scientists don't know enough about interface development, HTML, CSS and javascript, and discount them as being something that "anyone" could do. "Even my aunt made this puppy site in like 3 days, how hard can it be?!".

I've always thought that interface development have an undeserved reputation of being easier than "real programming"; something that you can let rookies work with, something that no "real" programmer would ever want. "No, I want to work with hard stuff, not that webby stuff".

If you are in a position where people actually think that, perhaps security could be the way to lift interface development to its proper status. So why not read up on Cross Site Scripting (XSS), look at examples of vulnerabilities, and pick a couple of examples of big sites that are vulnerable. While you're at it, why not read up on Cross-site request forgery (CSRF) too?

These are real issues that someone needs to take into account when building websites. My guess is that the fancy computer scientists will have a very long way to go before grasping this stuff. "Why does IE6 parse 'java script:' as if there where no space in the middle?". You know who's not surprised? Every damn interface developer out there.

So. Go out there, and teach them silly math people how it's done, and what your HTML, CSS and javscript-knowledge is worth. Show them that logic isn't the way we do things around here, that anything can happen when IE6 boots. And… whatever you do… think very hard before letting people embed HTML on your site.

Worth a look: DOMAssistant

2008-02-25T21:30:31+01:00

A couple of months ago Robert Nyman showed me a javascript library he had built, DOMAssistant, and proceeded to use it successfully in one of our projects. I wasn't amused. How could a tiny homebuilt little hack compete with my favorite, the almighty jQuery?

I whined, and said I really liked the CSS-selector syntax that jQuery has. So he added support for CSS1, CSS2, and CSS3. The bastard.

After a while he started getting doubts about if he really could compete with the big names, being supported by lots of people. But instead of giving up he got himself a team of his own. The famous Roger Johansson being one of them. There went that argument, damnit!

I pointed out the jQuery was very small, only 15 kb! He pointed out that DOMAssistant is half that size, 7 kb. That's smaller than most images. Aaaargghh!

I said that jQuery is much faster than anything I've seen. He showed me the slickspeed test, showing that his framework was indeed faster than all the others. How could he do that? Well, he explained, by using the browser optimized XPath and querySelectorAll support in browsers.

I had one card left to play, a somewhat ugly one. "Animations?" I almost wispered. "No…" came the reply back. But as he saw me straighten my back, getting ready to proclaim victory, he contiuned "… but it's being worked on, and coming in the next release". Damn you Robert, it seems I just have to give it a try…

Sharepoint 2007 from an interface developer’s view

2008-01-20T12:10:42+01:00

Like Cameron Moll (Skinning Sharepoint and Pointedly unskinnable), I've been working with Sharepoint 2007 (aka MOSS) recently, and I hope you don't mind me posting a few articles about my work here. I've found far too few blog posts that really go to the depth in explaining how things really work. I'll try to do that here, but I hope you can respect my wish that this does not turn into a helpdesk.

"Customization"#

Let's start. Sharepoint 2007 very, very hard to customize. If your job is to customize the interface in any major way, you have a lot of work ahead of you. You might think you're a much better interface developer than me, but you still have a lot of work ahead of you. You need to accept that.

When you read about Sharepoint 2007 on other sites you will find that people are really ecstatic about it. Just check the comments on how to customize the calendar. Reading carefully you will find that he's comparing it with Sharepoint 2003, not with other products, or even a standard ASP.NET site. That's a big difference. Sharepoint 2003 was much worse, but that does not mean things are good now. This is a common pattern, people that like Sharepoint compare it to the previous version, not with better ways of doing things.

As most CMS:es, Sharepoint gets sold to customers that don't know programming. They see a product that can handle all the features they want: blogs, wikis, forums, calendars, document libraries, workflows, and so on. All features you could ever want is included, from what is called "out of the box". The problem is that the system is built so that all of those "out of the box" features are hard to customize. Things like changing how the wiki renders, is really hard. Often it's easier to rebuild that feature from scratch, than customizing what Sharepoint ships.

This is the main reason, from my point of view, that you should pick another CMS.

Specifics#

I don't believe you trust me on my words, so I thought I'd be more specific now, and talk about the issues that make Sharepoint 2007 hard to work with (customize). Let me stress that these are not all the issues, just the major ones that an interface developer has to tackle.

Development#

From what I've read from larger projects, the recommended development environment for a Sharepoint site is a virtual machine. For us, we needed a 36 Gb image, a size that required me to get a new external hard drive, just to store it. Also, running in a virtual machine means that you only can use about half of your RAM, which means everything gets slow. As if that wasn't enough, a new virtual machine means you have to reinstall all your programs, browsers, plugins again. Web development shouldn't have to be like that.

Accessibility#

Sharepoint has gotten a lot of bashing for not being accessible, so they've added some features to account for that. Some of those are really good individually, but looking at the general mess that is the HTML that Sharepoint spits out, the pretty page above fades in importance. One major problem is that you still need javascript enabled for many of the accessibility features. Enabling "Accessibility mode", among other things, makes dropdown menus appear as new windows (popups) instead of dynamically writing HTML to the page. And this is after they "fixed" it.

Page size#

A standard Sharepoint site uses lots of default Javascript and CSS in two files called core.js and core.css. All in all they add up to over 250 kb. Yes, that's not a misspelling or extra zero, a default page in sharepoint takes at least 250 kb. This is not counting the HTML, a huge, table-ridden, inline-javascripted, mess of things.

If you go through lots of trouble, you can strip those files out, but that means you can't use any default components. Since much of Sharepoint depend on those, you don't really want to go that way. It's a mess, and Microsoft themselves recommend you try to remove some of it to boost performance. Preferably by using AJAX to load the js file later. Seriously.

Javascript and Browser dependencies#

Except from core.js, the javascript is spread out all over the place. As usual in many CMS:es, javascript is not treated as a real programming language, so there's no structuring whatsoever. Sometimes it's script tags, sometimes inline, sometimes external mini files, and most often automatically generated code. It's a real mess, and is a big reason for the HTML size being so large. Many of the scripts do not work in browsers other than IE, which means you really need IE to properly use the admin interface.

From the browser compatability info you can read that there are level 1 and level 2 browsers:

"Level 2 web browsers support all of our basic functionality so that users can both read and write in our content sites, perform site administration, etc. Some functionality may not be available, some functionality may be available in a more limited form, and some visual rendering may not be as optimized as our Level 1 browsers. We also will not support Level 2 web browsers on the Central Administration site."

These are the Level 2 browsers: Firefox, Netscape, Safari. Opera isn't even in the list. Is this the new, modern way, of handling cross browser compatibility?

Changing the CSS#

I previously said that most CSS is included in a file called core.css. The file in itself if huge, with thousands of class names, and no structuring whatsoever. Heather Solomon has made an attempt to make things workable by making images of what each class specifies. It's not even nearly a complete reference, and helps some, but using Firebug is a faster way. Another thing the CSS sheet above does, is show how completely unorganized the CSS is. Have a look at it.

As with core.js you can't really remove core.css, since lots of built-in functionality depends on it. So what you need to do is start deciding which of those rules you need to overwrite and which not. Have fun!

To add to the insult, if you just add your own CSS as an external file and try to link to that on your own pages, core.css is appended as the last stylesheet in the source code. This of course means that all your changes get overwritten, and you need to hack around things by using the tag directly (instead of sharepoint's own csslink-control), or add your custom files via the admin interface. Since core.css is just a list of simple class names, you can also use CSS Specificity to make your rules count, but that isn't mentioned in any of the troubleshooting blog posts. None the less, it's tedious do work around.

Most of Sharepoint is upgraded to use .NET 2.0, and its concept of Master pages and aspx pages. For those of you that don't develop in .NET the two can be explained as a templating mechanism, where each Master page has general placeholders where you can insert aspx pages. In each aspx page you specify one master page, and all of the placeholders you want to fill with content. It's a pretty good system.

Sharepoint taps into this system by making up two strings "~masterurl/custom.master", and "~masterurl/default.master", that you use instead of specifying your own masterpages. Users then specify masterpages in the admin interface, potentially breaking the entire site. Also, Sharepoint assumes there's just one masterpage per site, so if you thought you could use one masterpage for twocolumn layouts, and another for threecolumn layouts, you're wrong. The solution here is to break out of the Sharepoint way and hardcode real urls instead of doing things the Sharepoint way.

There's also things you can't change. The admin interface has a masterpage called application.master, which controls pretty much everything that has to do with built-in Sharepoint things. You don't ever change this file, since it's quite easy to seriously break things then. The problem is that this file also specify the look and feel of the admin interface, and if you're building a site where people are expected to add stuff, they will spend time in the admin interface. There isn't a good way around this, and you probably end up just changing some colors via CSS and let it be.

Default .NET controls#

The default master pages that ship with Sharepoint is horrendous and I'll post more details about them in a later post. But even if you roll your own master pages from scratch you still have the standard .NET-problem with controls. Using controls in .NET is a way to package functionality that you can easily add to your pages. A developer just needs to copy a DLL file, and call the control, optionally sending in some parameters. Easy.

The problem with this approach is that a control consists both of logic and HTML. So if you want some built-in logic that renders, say, the breadcrumb trail, you also get the HTML the author of the control deemed appropriate. In Sharepoint, a breadcrumb trail can be a doubly nested table, with display: none; controls to enable accessibility, and a doubly span nested link. It's just a terrible mess, but there's no other way to get to the breadcrumb logic, except from building a new control from scratch. Be prepared to work with terrible HTML.

In summary#

If you want to examine the points above by yourself, there's a MOSS example site up at wssdemo.com.

This article is a interface developer view at Sharepoint 2007. If you look at the system from other viewpoints, I'm sure there are good things there. That's not my point. What I'm trying to say is that Sharepoint 2007, is beyond repair when it comes to interface customization, and you should do everything in your power to avoid working with it. If I can give one interface developer the arguments to convince a customer to pick another system, this article was worth it. Thanks for reading.

Manipulating innerHTML removes events

2007-09-26T23:24:04+02:00

Others have written about this before, but I thought I'd mention it again, just so you don't miss it. Aleksandar Vaci? found it while playing with tables and their cells. I found it when Robert and I played with nested lists. It works the same across browers. Let me show a quick example:

You have a paragraph tag that contains a span that you want to make clickable.

<p id="para">
   <span id="clickspan">This is clickable.</span>
   But this is not.
</p>

To make it clickable you don't do any fancy stuff, you just add it with onclick:

var span = document.getElementsById("clickspan");
span.onclick = function() {
   alert("You clicked the span!");
}

All fine. You click the span and it just works. But then you remember something. You want to add some text to the end of the paragraph, and you decide to do this with javascript. You add the following line to the end of the script:

var p = document.getElementById("para");
p.innerHTML += " Some extra text";

You try clicking the span again, and it doesn work. You scratch your hair, you bite your nails, you scream of desperation and anger. It still doesn't work. It seems manipulating an element by using innerHTML removes all events from that element, and all children. Here's a live example. I thought you should know.

I’m an interface developer

2007-08-20T23:17:55+02:00

In his latest post Roger Johansson asks the question Are we designers or developers?. I have a simple answer for that. None of them. Let me explain:

First we have these people calling themselves developers. And boy do they know programming… and math… and… no that's all. Many have a masters degree in computer science, a degree that pretty much tells you that they once gave five years of their lives to programing, how cool is that!? It's not unusual to find people that think in those terms too. You can recognize them by their 10 year old, unmatched, clothes and you'll rarely talk more than 1 minute with them. Very efficient.

Then we have the designers. Either real females, or people very close to females, that just can't stop talking about this abstract thingie-thongie that just like, you know, exploded in a big burst of colors and like… "EHEM! Sorry!", you hear them say, regaining consciousness and flying back to earth. Their clothes, at least you think they are clothes, often look like they where meant for something else. Perhaps for building steel pumps, or killing animals… or both. Well, at least these clothes are matched… or very purposefully not at all matched (not at aaaall like the developers). You can talk with these people for hours, probably even days, and still only touch upon the delicate topic of "a glass of water". Oh, and they "create" things too. Very deep.

So where the heck does the interface developer come into all of this? Well, imagine you have a real project at hand. Real people that need some new website to do their work. Real deadlines, money that switches hands. Smiling business people that promises things and shake hands. Seems like something you know of?

Now, imagine bringing a developer and a designer together in a room, for like a month, working together with this new website. Concentrate hard and try to see the images before your very eyes. Will they accomplish anything?

Hell no! In 5 minutes they will have started arguing about who should be the first one to open the door, and in what way. One talking about the most efficient way to turn the handle, and the other one defending herself by talking about cosmic beams from Saturn. After the first day the developer will have sore cheeks, after being constantly bitch slapped while hiding under his desk. The third day the designer will sit shaking in a corner after the electric shock induced by the steel helmet the developer built. None of them will survive the fourth day, let alone the project.
Very yes! When you meet them after the month has passed you find two harmonic people that smiles to each other and really seem to have connected. They explain to you that the demonstration will be in two parts, first the designer and then the programmer. The designer shows you an app that really touches you, at least you think so, although you not fully understand it. The programmer shows you the other part of the app, one that instantly shows the number 369. They finish the presentation and look at you. You stand up, walk out, lock yourself into a nearby free conference room, and shout with all the power in your lungs: "HOW THE F*#CK AM I GOING TO DO MY TAXES WITH THIS SHIT?!#". When you come back you find them congratulating each other for making the deadline.

You see? There's something missing there. Some kind of link between the two. Someone that can walk into a room with two screaming people and calmly say: "Hey, you both kinda run linux (SuSE vs. Mac OS X), and have a "cold" desktop background (default plain blue vs. modern interpretation of Vasnetsov Snegurochka), what a coincidence!?". There needs to be someone that can walk into the same room the next day and explain that they are talking about two different kinds of "abstract methods". There needs to be a link.

But there's more: An interface developer is silly enough to learn languages that doesn't even have variables. Even though he know that his code will be sent as uncompressed plaintext and will be rendered by broken excuses for programs, he won't cry himself to bed every night.

He will also gladly adapt a design to something it wasn't really intended for, and he even will make it look somewhat good. He will skip adding those fabulous shadows, to make the deadline on time, and still think of himself a good person.

You see, even though "interface" reflect the visual graphic things, and "developer" relate to hard logic code, interface developers are real people, not a combination of two halves. I am one.

What is Web 2.0? Really.

2007-03-10T00:59:52+01:00

Web 2.0 is really hot right now. One of Sweden's biggest newspapers recently wrote a long article on their debate section. They had started linking back to blogs that linked to them, in a little box next to the article. The problem was that they had got into trouble with what blogs to link to. After all, you can't just link to anything, right?

Aside from starting to think about the implications of blog links, I got another interesting question in my head. What is Web 2.0 really? Most people working with interface development would say that Web 2.0 is everything that uses AJAX. But the newspaper didn't use AJAX at all, and still they claim links to blogs is Web 2.0. Time for some research!

The hunt for a definition#

The phrase "Web 2.0" was first put into widespread use at an O'Reilly conference in 2004. The organizers wanted to talk about a change that has happened on the web, and just bumping the version of the web seemed like a good idea. Paul Graham found this first try at defining Web 2.0 at the conference:

"While the first wave of the Web was closely tied to the browser, the second wave extends applications across the web and enables a new generation of services and business opportunities."

Note that there's no mention of AJAX there. Hell, there's no mention of users either! They must have meant something else, and the definition might have changed over the years since then. Let's keep looking for a good definition.

Tim O'Reilly comments on the issue two years later, in a clarification on his blog:

Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them.

Tim acknowledges the change in meaning and talks about "network effects" here, something that starts to look a little bit more like what my idea of Web 2.0 is. But isn't there still something missing? To me, that looks only like a small part of what I call Web 2.0. Let's keep looking…

Gartner has tried to convince companies of the merits of Web 2.0 for a rather long time. In one of their many (business oriented) PowerPoint presentations they attempt to define "three anchor points around Web 2.0":

Technology and Architecture — Consisting of Web-oriented architecture (WOA) and Web platforms.

Community — Looks at the dynamics around social networks and other personal content public/shared models, wiki and other collaborative content models.

Business Model — Web service-enabled business models, mashup/remix applications and so forth.

I believe we're getting closer. Gartner is making business models a separate point which I don't agree with. Many of the biggest Web 2.0 sites didn't have a business model when they started (and many still don't). Digg has troubles covering their hosting cost with the tiny bit of money they acquire from their ads. Del.icio.us still doesn't make any direct money (although they got sold to Yahoo, and they surely use the data…). My point is, a business plan isn't one third of Web 2.0, it's something sites add afterwards if things work out.

So let me state my own (slightly more general) definition of Web 2.0:

"A collection of ideas and techniques that can be used to make more interactive sites"

The thing is, just doing something in AJAX does not mean it gets the Web 2.0 stamp of approval. You need several of the ideas or techniques and you need to combine them in clever ways. So lets agree on the definition above and got look for ideas.

Ideas that are part of Web 2.0#

I'd like to gather a whole bunch of ideas under the Web 2.0 roof. My selection is of course not all there is. Googling could uncover more I'm sure, but I think this is a good start.

User generated Content#

Many companies still view the web as a one-way medium, an extension of a paper catalog, it's main advantage being that it can be distributed to more people. It's not like that any more! There are people that want to add content to your site, that want to contribute their ideas and thoughts. Why are you denying them to help you?

User generated content is content that your users are willing to give you. It can be everything from a simple "like it" or "don't like it", to fully featured articles written by users. The two most used ways of contributions are the simple ones: votes and comments. The author is still in full control of the content but users are given a chance to chip in with minor corrections. This is the least you can do. It's what I do on this blog; let you chip in by commenting.

But if you have users that are passionate about your subject, users that are willing to use your site to get their ideas out, you should really endorse that! Allow them to post articles on your site, allow them to regroup and re-prioritize according to their own wishes. It is technically possible, even rather easy to do; you just have to do it.

Six simple things your users can help you with:

Reviews of your products
Comments on your articles
Stories about how people use your product
Multimedia using your product
Questions about your products
Articles in an area you choose

Radical trust#

Another approach many sites have taken can be summarized as "radical trust". It builds on the simple idea that users know what they want better than you do. So let them order, categorize, sort, select your data as they like!

This is exactly what wikis do. They acknowledge that there are more users doing good than doing bad. If that's the case, why not let them in on your content directly, letting them edit and improve it like they want. They few people that do bad can be hunted away with a combination with versioning (saving old versions of content that's easy to restore), and some simple monitoring. Wikis trust users, do you?

Syndication of content and services#

Web 2.0 is not only about "user to website" interactivity. It's also about letting other sites and tools interact with your site directly. This is often summarized as "syndication".

It's a very fancy word for a simple concept. Let me try to explain.

Somewhere you have some kind of database with your content, be it products in your e-store or posts on your blog. Usually you take that content, add some structure (HTML) to it, and send it to the user.

Another website that wants to access the same information could parse the HTML and try to understand what it means, something called "screen scraping" (or microformats ;). The problem with that method is that it's very dependent on that the webmaster doesn't decide to change the HTML. The other problem is that computers and humans often want different types of information. A computer that is going to parse a list of your products doesn't need navigation like humans do. What you do is send your data directly to computers instead, without messing it up with HTML. Formats include: RDF, RSS, or perhaps custom XML through a Web Service.

Thing is, when you start syndicating your data you make it easier for others build services based on it. Now people get several entrances into your content instead of the one you produced. Again, your users are helping you reach more people.

Allowing full RSS feeds is another way of syndicating, I'm switching right now. Do you syndicate?

Long tail#

The theory of the long tail is one of the ideas that are usually associated with Web 2.0. It's a business model that many companies that are successful on the web use. As with most business models they are invented after the fact, and as such I'm not sure it really belongs on this list, but people always bring it up, so let’s go. I'll let you choose yourself.

Wikipedia describes the long tail like this:

"Products that are in low demand […] can collectively make up a market share that rivals or exceeds the relatively few current bestsellers and blockbusters, if the store or distribution channel is large enough"

Most physical stores need to aim for the bestsellers to sell anything. There's simply too few interested in odd products, to make it worth hiring store space and personnel to sell it.

Web based stores are in a different position. Selling another product usually means just adding another page to your site, no extra store space or personnel needed. In addition people are prepared to wait a couple of days before receiving their products. That time span means you can skip warehouses and not start producing your products until you have an order ready.

No more is there a need to estimate what people will be interested in and pre-order them. For the right kind of product the internet is a huge benefit. Amazon did it with books, iTunes did it with music, do you do it?

Collective intelligence#

You have let each user customize their experience and add content of their own. Now it's time to organize that content to better help the everyone benefit from it. There's hundreds of ways of doing it, but here's a couple of things that you can present to your users:

The most popular Swedish article right now… - Crawl all Swedish blogs and keep track of what they link to.
Others that bought this book also bought… - Query your shipment table. Pick a product, select the number of times each other product appeared together with said product, and recommend that product to your customers. Amazon does this and it's said that it has increased their profits considerably.
You probably think this movie is a four out of five - A Swedish movie site give its users personalized ratings of movies. They find users that have similar taste as you have (based on your previous grades) and then checks what those people have rated the movie as.
This is probably spam - Write a word filter that learns what is considered spam when users mark them. Share that filter with fellow users and let their markings stop your spam. A form of collective sieve filtering, Akismet does this.

None of them are technologically hard to do, you just Google and copy other people's samples. Why not?

Techniques involved in Web 2.0#

But there are techniques involved too. Let's go through a few of the important ones.

AJAX (and other javascript)#

Everyone talks about AJAX together with Web 2.0, but I think it's important they are kept separate.

AJAX is just a technology that helps prevent (full) page reloads. Instead you connect to the server silently in the background and receive your data that way. What's the revolutionary about this technique? Nothing. It has been in use for at least 5 years. They new thing about it is that people started using it to build better interfaces.

Javascript is language that enables AJAX, and playing with reloads is not all it can do. Through some nifty use you can change attributes on any HTML element on the page. Move things around, react to mouse movement, fade and animate, it's your choice. This means a lot of new controls become possible, ranging from simple sliders to interactive maps.

Why do most accessibility people hate it? Because most developers don't know enough about accessibility. And when those start to use AJAX they disregard accessibility completely. Javascript and AJAX have different goals and I think a good compromise is making sure the basic functions of the site (buy a product and pay for it) works without javascript, but enabling it adds additional features.

When was the last time you used javascript to enhance your site? What was the last control you invented?

Feeds (RSS, Atom)#

Feeds are great for syndication of content. There are many different feed formats to choose from but they all have one purpose: to communicate pure data, skipping all design.

A feed is simply a list of feed items, each with an unique identifier. A user adds the address to their "feed reader" and it starts polling you, asking for updates. I have my reader set to just a couple of minutes, making sure I quickly notice changes in people's feeds.

The good thing about feeds is that they make it easy to follow several at once. There's no annoying different designs in the way if you don't want to (you can always just visit the site if you want design). Feeds are getting more and more of a commodity; you should already be allowing your users the possibility to subscribe your content. Do you?

Tags#

Tags is another hip concept. It deals with the collective intelligence idea and how to categorize content efficiently. A tag consists of a phrase of some kind that describes a piece of content. This blog post could have the tag "javascript".

There's several ways you can use them. One is the just fix what tags are allowed and use them as regularly groups you can assign content to. But allowing more than one tag enable you to do more than just split things into groups, you can instead pick all contents bits that have the same tag. You can go further, allowing custom tags that the users can pick themselves. That gives you a wide array of descriptive words for your content, free to play around with. For example, if many users pick the same word, that one is probably a better descriptor.

Picking many bits of content and analyzing all tags tied to them can be easily done with a tag cloud. In that you simply print all tags used after each other, and make those used often bigger. Doing this on a whole site is an effective way of giving users a snapshot of what you write about, something I know I like.

Can tags help you solve a categorization problem you have?

Summary#

Now. To build a Web 2.0 site, pick from both of the lists above. You Google for more ideas and you work hard to interact with your users as much as possible. Web 2.0 is the combination that happens when your ideas and technology finally just works.

Your users want to help you, do you let them in?

Improving interactivity with Javascript

2007-02-21T22:13:21+01:00

Push buttons, radio buttons, check boxes, select boxes, and text inputs. That's the controls HTML allows us to use to interact with our users.

A small dedicated group of people at the office (I work at Valtech) sat down and listed all controls we could think of. The list below is basically that list, completed with examples where possible. Let me stress that the below controls are meant as inspiration. They are not all free, or even available for download. If you decide to use one of the ideas, google for them first and pick the best one. While selecting one, make sure it supports some kind of fallback for users without javascript enabled.

Slider#

Slider control meant to let users select values from a range of options.

Date picker#

What format should this date be? What weekday is the 15:th of august? A good date picker helps the user answer those questions and makes filling in dates much more delighful.

Smart text boxes#

It's easy to make some text boxes only allow certain kinds of characters. Why allow letters in the age field?

Mixing text inputs with select boxes#

Allow users to both input text and pick common options.

Drag and Drop#

Users are used to dragging and dropping things from their operating systems. Letting them do the same on the web makes for a great affect! Don't forget about a fallback though, not everyone uses a mouse (A buy-button is enough).

Collapse and expand control#

Makes it possible to quickly show less important information on demand. Just make sure everything is open by default (with no javascript).

Advanced tooltips#

When the title attribute is not enough. Use images, fine-tune the delay, make them sticky if you click them, it's all up to you!

Autosaving form fields#

If you write an email with Gmail and the browser crashes, you'll appreciate that Gmail automatically saves your text regularly. It's done with a simple piece of javascript that periodically sends all your text off to the server, and saves it away. Simple and very useful.

Auto validation#

While filling in some forms you'll notice a little green check on the side. I can't begin to praise how much faster this makes filling out forms. Directly after you've written enough letters in the password field you'll find that it's ok. No more trial and error against a slow server (unless you have javascript off, of course).

Controls affecting each other#

In complex forms it's not unusual to want the user to fill in either one set of fields or another. The showing and hiding of what fields are available is a another perfect case of where javascript really helps.

Image handling#

It's time to get easy handling of images in browsers. Javascript can help there too, by combining drag and drop with resizing and so on. Photoshop, here we come!

Sometimes new navigation schemes can be useful. Using search instead of navigation is an interesting idea. Another is letting the user pick categories and using them in search.

Better looking form fields#

Javascript also allows you to enhance existing form fields with prettier equivalents.

Sortable items#

Sometimes you want drag and drop in a more controllable manner. Why not use it to make it easier to sort your lists?

That's all! Hope I've given you some ideas of widgets/controls you can use to enhance user experience. Good luck!

Flash-only vs. AJAX sites

2007-01-16T00:02:35+01:00

Even though web developers like me have discouraged from building Flash-only sites for as long as I remember, they are popping up all over the place. For no reason! We are ready to make the leap to standards. And our weapon with be AJAX.

What kind of sites are built with only Flash?#

Let's start by having a look at a few big Flash sites. Because they exist, and keep popping up all over the place. Here's a couple of movie sites using it: Departed, Underworld Evolution, Matrix; Here's a couple of big brands: Coca-cola, Nike, Electrolux. These sites are more than just animated images, they have their own content and often need to get updated continuously.

What's the purpose of them?#

Before deciding on anything we need to examine what purpose these sites have. It's not OK to change the purpose of the site just because we dislike the technology behind it. I can't possibly know the reasons behind all of the campaigns going on today but I believe there's a core that most sites are after.

Promote something new - Someone wants to to push some of their products/deals/ideas to the spotlight.
Specific target audience - Companies are well aware that what kind of people they reach initially will define if the product is successful or not. Many want the hip people.

Updating flash files is hard#

Many years ago it was ok just to throw up static information on a site and have a good site. Don't get me wrong, content is still king, what has changed is that content alone isn't enough. We demand much more from a good website. Coca Cola can't just publish a press release telling us that there is a new taste out. It's the Web 2.0 age and we want to be able to send our own tasting stories in, we want to be able to see live counters of the number of bottles sold, and we want forums to talk amongst ourselves about our experiences. We want tags! You get the point.

How does this affect the choice of flash or not? We need dynamics, ways for both editors and users to add content to the site, and Flash files are hard to update! Just the fact that I need a special program to edit them speaks for itself.

Another fact: As you probably know, it's rare (in the real world) to have the same person both writing code and publishing content. The coders need to cater for that, and make sure it's easy for editors to add new content. Now. Even if you've bought licenses and are able to edit flash files, you can't expect editors to understand all about how flash works. So you need to build a content management system (CMS) of some kind. If you buy one, you still need to integrate it with your current code.

"But", I hear you say, "…you have that same problem with non-Flash sites!". Yes, but the difference is that CMS tools that publish HTML have existed a lot longer. This affects both the quality, usability and ease of integration with current systems. A HTML-based site will therefore be easier to update, making for both more and fresher content that reaches more people. If it's easy enough to update the site, you can even let users do it, Web 2.0 style.

Flash is not hip any longer#

Publishing a site with Flash today is hardly going to get mentioned at all. AJAX has completely taken over the scene and anyone even whispering AJAX gets to the front page of digg.

Aside from the technology buzz we have had some real changes rather recently: Javascript can now deliver what was once only available with Flash. It can fade, move, round corners, drag-drop, auto-save, validate, the list could go on forever… There's several effect libraries available that makes using all those effects easity. All the good ones are even free.

Flash-only vs. AJAX - The showdown#

I've made a small list of things that matters when you build a website today, and evaluated each one of them for both Flash-only and AJAX.

	Flash	AJAX
Accessibility	Poor. There's problems with everything from how a flash app gets its initial focus from the browser window, to unusual interaction controls, to lack of text resize. In summary, zero points.	Moderate. AJAX has problems with requiring js for accessing data, but smart developers have started thinking in terms of accessibility and fixed many of AJAX initial flaws. Nyman's ASK is one way.
Search Engine Optimization (SEO)	Poor. Search engines don't read flash files (even though they probably could). Some people claim that you should duplicate all your content. I say that will be a mess to update.	Moderate. If you just use the javascript effects you are fine, if you fetch data with javascript you need to write a little script that reloads the content and gets it that way instead. It is possible, but not easy enough. Bonus: if you fix accessibility you often get this too.
Ease of content change	Poor. You need an expensive program to edit the files. ? Only available on PCs running Windows. Few CMS:es available (any?) that makes it easy for editors to update content.	Strong. All the big CMS:es can be used together with an AJAX app, it's just a matter of changing the templates on the front. Systems like Ruby on Rails (while not being a CMS) have built in support for AJAX stuff, but including a framework in older systems is no big deal.
Hipness	Poor. There used to be a big community of flash developers that got incredible respect in the webdev community with their flash-only sites. Many of these communities have been replaced by CSS Galleries of different kinds.	Strong. While Flash-only developers focused mainly on visuals the AJAX community have focused more on user experience, building applications that feels better to use. Together with the technology buzz behind it AJAX solutions have gotten (and still get) a great response from the start. The potential for marketing campaigns based on user experience in huge.
Graphic effects	Strong. This wouldn't be a fair comparison if we didn't acknowledge that Flash is far ahead of AJAX when it comes to graphic effects. Most of this is based in the fact that you are working in an application instead of a website, and things like anti-aliasing, drop shadows, transitions, and filters have existed for long.	Moderate. Websites was long lacking pretty interfaces but in the recent years we've seen an explosion of graphic effects even in the standards world, probably starting with the famous CSS Zengarden.
Integration with existing sites	Moderate. Few code libraries are written to work well together with flash, so often you have to do the integration yourself. In it's latest version Flash has gotten more integration points with the possibility to communicate with javascript, import HTML and so on. Better, but not perfect.	Strong. Most effect libraries are built to be as easy to include as possible. The usual way to make use of one is two lines long: link a javascript file and call the right function. The more advanced libraries that enable asynchronous loading require some more work, but unless you want advanced error handling it's no big deal.

Next time a customer ask for a Flash-only site, tell them about AJAX and it's advantages.

Web development blogs you should read

2006-11-19T04:40:48+01:00

The web is filled with blogs about web development. I'm always looking for good blogs to add to my feed reader and I thought some of you might do that too. So let me list the webdev blogs I subscribe to right now (in alphabetic order):

456 Berea St - Roger Johansson is one of the most well known web developers out there, and it's for a reason. He posts almost daily about things happening in the webdev field. Everything from short comments with links to things to full blown articles.
Creating passionate users - Simply one of the best blogs there is, all categories. Deals with usability and making users happy. The posts are everything from hilarious to spectacular and I often get the motivation to write from here. Read an article or just look at one of the wonderful graphs. You'll love it.
Future of the web - Jesse Skinner writes for all skill levels. Articles vary from basic markup to advanced javascript tutorials. Often with a twist of humour added in the middle of an article. Nice read.
Monday By Noon - Jon posts articles weekly (as reflected in the name) about all things related to web development. His friendly tone and ability to explain things makes this site ideal for people starting out. The good thing is that the same style works for more experienced people too. Try one of the articles, I'm sure you'll like it.
Pixel Acres - Jonathan Nicol combines webdev articles with thoughts on how to deal with clients and co-workers. Well written and qualitative, what else do you need?
Robert's talk - Robert Nyman's blog, mixing personal posts with those that have to do with all kinds of interfaces. Entertaining read that feels balanced and well thought-out.
Rund kvadrat - Blog in Swedish about making money on the web. While this isn't the primary concern for many interface developers we should certainly keep it in mind. Does moving a certain link upwards increase the client's sales?

Well, and then there's all the big ones, but they tend to post too much about the conferences they attended and the books they wrote. Also, all their good articles end up on the big webdev news sites, which I also subscribe to.

Do you have any other sites that should be on that list?

How web standards feels

2006-10-11T21:34:42+02:00

When talking about web standards many of us have started using marketing terms. Every day we hear about the bandwidth savings, the increased user base that are able to access your site, how well it affects SEO and so on. But none of that was what got me into all this. Let me tell you about the thing that convinced me: the feeling.

For me the web standards revolution started with a feeling that something was wrong. "There has got to be a better way", was a thought that buzzed in my ears when nesting my tables to create some padding.

I first saw CSS in other people's code, often embedded in style attributes with text-decoration: none; to remove underlines. I started experimenting, but the deeper aspects of how it could change the way websites were built didn't occur to me. It was just another tool to place things where I wanted them, and make things look like I wanted.

At that time I didn't know any server-side language so all my sites where frame based static HTML, often with a fancy javascript enabled select box for navigation. I did use some CSS just to remove the underlinings on my links, but that was it. Something still felt wrong, was this really the best way?

The "AHA!" feeling came much later; I'd love to say a certain moment when I understood but it wasn't a certain text or piece of advice, it grew on me. Suddenly everything felt like it had its place. It wasn't always obvious where that place was, but you could reason your way there. When the strength of CSS occurred to me, it was like finally understanding a tough mathematical formula. Yes!

So go ahead, show me your pretty charts of workday savings, CSS Zen garden remakes, or new techniques you can use. I like them, I really do, but I'm pretty convinced it's the "AHA!" feeling that finally wins people over to the web standards side.

What won you over? Can you convince someone else using that method?

(Inspiration from Motivating others)

Concept: Four layers of web development

2006-06-03T18:45:07+02:00

When thinking about web development on the client side, I tend to think of four different layers. Any (well built) framework will cater for all of these layers and all good developers will be aware of them. The layers I'm thinking about are: Data, Structure, Design, and Behavior. This article discusses all four of those and explains how they relate.

Data layer#

The data layer is the most important one and strangely the one most people get confused about. HTML is not the data layer, the content is. The data layer is the raw data that you are presenting, the text, the images, the sound, the video, whatever content you want to serve. For bigger sites the data is often stored in a database or perhaps XML files somewhere and then processed server side every time someone wants to access it.

This layer is also where all websites should start. What content do you have? If the content is bad no pretty design or fancy Web 2.0 technique is going to cater for that. In fact, content together with bad uses of the other layers, might still work!

One last point to make about data is that you should make sure to use the best possible media for representing your content. If it can be text, use text! Don't use images for text, narrate your podcasts (or at least provide a text-summary), put your videos online with descriptions to them. Having that text there helps you convey your point, search engines will find you, your users will be able to skim read while it loads and disabled users will get access to at least some of your content.

Structural layer#

The structural layer is where the much misunderstood HTML comes to play. HTML's job is to take the data it has received from the data layer and add some structure to it. Mark up what parts are headers, make sure lists get the HTML that best describes them, split the page up in the important parts and so on.

HTML also adds some semantics to the data but since it's quite a limited dictionary we have to work with I believe this is secondary. If you happened to have the kind of data that HTML happens to catch with its elements be sure to use them, if not make sure you at least capture the structure of it.

You know you have done this level right if your site works with nothing but data and structure.

Design layer#

The design layer is where you define the looks of your data. Design requires a good basic structure to be useful. On the web you should use CSS for this layer, a language that has been built upon the idea of a solid structure and is remarkably powerful. As you know CSS targets certain elements and then defines their look. Without a solid structure this is not possible.

Good designers often point out that only working with the looks of a site will not accomplish good design. They also work on the structural layer by making sure structurally important content gets the most exposure in the design. This is also strengthens the idea that structure is a layer upon which design works.

Behavioral layer#

Behavior is the last layer I'm going to talk about. It's the one that's least important; data, structure and design are all more effective in conveying your message. None the less, added behavioral functionality can be powerful if executed properly on top of the other layers.

Javascript is the most used language for adding new behavior to websites. With the whole Web 2.0 and AJAX wave we are experiencing many new sites that adds a behavioral layer without even thinking about it. We should be careful; becoming dependent on the new behavior (the site not working without it) means you will lose many potential visitors, the most important single one being search engines. Behavior should always be added separately and only enhance the experience for those that has it enabled. This is what's called unobtrusive javascript.

Putting it all together: four tier web development#

Putting all these four parts together we get the following:

Is this the same mental model you use? Let me know through comments.

Update: Threehouse has an image up showing the four layers in the context of javascript connection the layers together.

Challenge: What’s the worst you can do?

2006-03-11T16:09:26+01:00

After reading through the comments on my levels of CSS article I find that I few people seem to think that the article is a way to ridicule beginners. It's not. It's a way to document the steps that I think I have climbed. Some people also thought that this set of levels is a good indicator of how good sites you will make. That's also false. Being Level 5 or 6 in the list means that you are a good coder, nothing else. It does not mean that a site you make is any good, I've seen many sites that have great code but that still makes me want to kill someone. Don't confuse good web developers with good coders. "Don't be a rotten standardista" as Molly Holzschlag would put it.

The challenge#

To give you a perspective of how bad it really could be I'm challenging all the readers of Friendly Bit. It's kind of a competition (with no prize) about who can make the worst site. The rules are simple; you are to construct a page, using HTML and CSS (and Javascript if you think you need it) that has a design that is as hideous as possible. I want pages that make my eyes bleed, that make small children cry and makes Maddox write hate articles about you. Think of all the good things you've learnt and do the opposite.

Inspiration for a truly hideous design#

I won't be giving out any prize but what I can do is help you with some ideas of bad code.

Make use of the <marquee> tag. It makes any content inside it scroll in the speed and direction you choose. Did you know that you can wrap <body> in a marquee tag? That's right, your entire page will move automatically. You can also nest several marquee tags inside each other. Ohh yeah!

Another good tag you can use is the <blink> tag. Can it be applied to, say, a table? I hear you ask. But of course. You can have a full screen blinking table on your company homepage.

Continuing with the good ideas we have the oldschool frames we all have come to like. Did you know that there are no set upper limit on the number of frames you can load? You can have thousands of them! You can even mark up a whole tabular grid with frames alone.

This challange is about terrible code as much as it's about terrible design. So don't go with well-formed or the basic foundations of HTML. Did you even try putting tags inside other tags? <font <font size="2"> size="3"> is quite fantastic don't you think? Make your page upside down by adding the <head> below the <body>, but only after you have added your own <neck> tag to the mix. Surprise me!

How to accept the challenge#

To join all of this you just have to make the page, put it up on your server and link to it here. Post a link as a comment or simply trackback (link to this post) from your own blog and it will show up here.

Finally: Don't forget the lesson behind all this. When you see a site with bad code, know that there's a lot of much worse sites out there.

Extra fluid layouts with javascript

2006-02-13T01:00:31+01:00

I'm a big fan of vector graphics. Because of that I love Macromedia Fireworks and the way it handles all elements like vectors. The good thing about that is that they can be resized and zoomed without them losing their sharpness.

This got me thinking about how to add some vectorization to CSS layouts. My idea was that you should let the width of the screen decide the font-size of, for example, your headers. This could make for nice fluid layouts and might even add to usability in some cases. There are probably other uses for this but I leave that to you, please use the comments if you come up with something.

Start by having a look at the dynamic font-size example just so we're talking about the same thing. Try resizing the window and reloading and see that the headers really do adapt to the width of the browser window.

How it's done#

First we need a way to meassure the width of the text in the default font. For this I use my own little getTextWidth() that were constructed in my line-break script. It simply takes a piece of text, attaches it to the page, meassures it's width and removes it again.

function getTextWidth(text) {
   var ea = document.createElement("span");
   ea.innerHTML = text;
   document.body.appendChild(ea);
   var len = ea.offsetWidth;
   document.body.removeChild(ea);
   return len;
}

Ok, now we know the width of some text in it's non formated state. Next up is to scale it as much as needed.

function scaleUp(elem, targetWidth) {
   var blockWidth = getTextWidth(elem.innerHTML);
   var defaultSize = parseInt(elem.style.fontSize || '100%')
   var newSize = Math.floor(0.9*targetWidth/(blockWidth/defaultSize))
   elem.style.fontSize = newSize + "%";
}

As you see scaleUp() determines a percentage by looking at three things: it's unformated width, it's current width and the target width. Font-size and text width does not seem to follow eachother perfectly so an additional multiplication by 0.9 is needed.

This handy little function is then called with the element you want to scale and the width in pixels of how wide you want it. The calls look something like this:

var element = document.getElementsByTagName("h1")[0];
var width = document.body.offsetWidth;
scaleUp(element, width);

That's it, hope you find some fun use for it.

Update: After doing some research I see that Eric Meyer is already using something like this in his slideshow system S5. Well well, it was a funny exercise none the less.

Line Breaking With Javascript

2006-01-22T00:00:00+01:00

Over the years there have been numerous suggestions of different ways of doing line breaks on the web. Browser incompatibilities, lack of support for standardized features, and the creation of browser specific features all helps in making it incredibly difficult. Searching and reading for a while quickly brought me to think the best current solution is quirksmode's wbr. It seems quite well supported but has two major flaws:

<wbr> is not valid HTML
The suggested solution does not work in Safari

So off I went to find a better one. I started trying some different combinations of spaces marked up with <span> tags and I tried some nifty CSS tricks before it hit me - this should be done with javascript. Javascript has wide browser support and after some research (and help from the people in EFNet #javascript) I actually got a working example up. I have been able to test it in FF 1.5/Win, IE 5.5/Win, IE 6/Win, Opera 8.51/Win+Mac, and Safari 2.0.3/Mac and everything seems to work fine in all of them.

How it works#

The idea here is to add ordinary <br>s and using javascript to measure the length of the text. The user gives a piece of text and a width in pixels and the script returns the text with breaks inserted.

The hard part is to find at which letter we should break. My first idea was to just loop over the text and keep track of the width in pixels. When we get over the given width, back one step and add a break at that position. But this will be slow for small font-sizes and wide columns so let's do something faster. Instead of looping through all letters we can use Binary Search (check the link if you're not familiar with it, it's good to know). This makes for a lot less calls.

We need a small change to the algorithm since we won't be able to find the exact width we're looking for (a letter is wider than 1px). Instead we break when we're down to knowing that it's between two letters. We then return the first letter's position. Here is code:

function binSearch(text, searchLen) {
   var left = 0, right = text.length;
   var breakPos = left, lastBreakPos = right;
   while (Math.abs(lastBreakPos - breakPos) > 1) {
      lastBreakPos = breakPos;
      breakPos = Math.floor((left+right)/2);
      if (searchLen  getTextWidth(text.substring(0, breakPos)))
         right = breakPos - 1;
      else
         left = breakPos + 1;
   }
   return Math.min(breakPos, lastBreakPos);
}

The code above uses getTextWidth() to get the width of a piece of text. getTextWidth() makes use of the offsetWidth property to get the width of a piece of text. Problem is that only elements that are rendered have the property set. This means we need to add it to the page, measure it, and then remove it. This code does just that:

function getTextWidth(text) {
   var ea = document.createElement("span");
   ea.innerHTML = text;
   document.body.appendChild(ea);
   var len = ea.offsetWidth;
   document.body.removeChild(ea);
   return len;
}

Good. We now have two nice helper functions to handle all the hard work. Now we only need some code to actually split the text and add the breaks. We do this by using binSearch() to fetch where the next break should be. binSearch() returns an index and we split the line and add the first part (including a break) to a buffer. We then repeat the same procedure on the last part of the string. We keep splitting until getTextWidth() tells us we're done.

function linebreak(text, maxLen) {
   var breakPos = 0;
   var out = "";
   var part1 = text, part2 = "";
   if (getTextWidth(part1) > maxLen) {
      while (getTextWidth(part1) > maxLen) {
         var breakPos = binSearch(part1, maxLen);
         part2 = part1.substring(breakPos, part1.length);
         part1 = part1.substring(0, breakPos);
         out += part1 + "";
         part1 = part2;
      }
      return out + part2;
   }
   else
      return text;
}

It's now time to use the function we have. The first line selects what elements we want to wrap. You can replace this with a loop if you want if you need to go over all the paragraphs in your document. The second line just fetches everything inside the paragraph and sends it to linebreak() for wrapping. The two lines are then made to trigger when the document is ready loading.

window.onload = function () {
   var e = document.getElementsByTagName("p")[0];
   e.innerHTML = linebreak(e.innerHTML, 200);
}

A working example is available that shows what it can do. So, what do you think? Could this be the best solution so far to handling line breaks?

Make a tooltip out of some columns in a table

2006-01-06T01:16:59+01:00

A worried user joins the #CSS channel on EFNet. He has a big problem with the site he's currently working on and wonders if there might be a problem with his markup. Let's see what he wants.

The site sells some kind of houses and each house has a few "options" (let's pretend a bigger door is one option) that the user should be able to select among. Each of these options has a name and costs a certain amount of money. When you move your mouse over one of the options, he wants more info to pop up in a small box. In the box there should be an image, a store name and strange number. What HTML should he use to mark that up?

We talked for a while and thought about definition lists containing a div with the extra info in, perhaps a two-column table with a div in the second column? After looking again it became pretty clear, if we just look at his data and not think about the design, all that was left was one big table. Everything that he wants in the tooltip are things that could as well be shown in a big table. So why not use exactly that markup and then use javascript to make some cells only pop up when the row was hovered?

This is the markup I propose:

<table summary="Options for your house">
  <thead>
    <tr>
      <th>Option</th>
      <th>Price</th>
      <th class="tooltip">Image</th>
      <th class="tooltip">Store</th>
      <th class="tooltip">SKU#</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
  </tbody>
</table>

What you see there is a plain five column table with some classes spread out to make it easier to fetch what we want with the javascript later on. The whole table is given the id "info", this makes us able to separate it from other tables on the same page. Each cell that are going to be in the tooltip get the class "tooltip" and an aditional a1-a3 class that simply is used to position the specific cell later on.

Next we need to do two of things:

Loop over the table and hide everything with the class "tooltip"
Loop over all table rows and add a mouseover function to each of them that makes them show all hidden cells in that particular row

To fetch all elements that has a certain className we will use Jonathan Snook's fabulous getElementsByClassName. It takes two arguments, the element whose children it should loop through and the className it should look for. The function looks like this:

function getElementsByClassName(node, classname) {
   var a = [];
   var re = new RegExp('\\b' + classname + '\\b');
   var els = node.getElementsByTagName("*");
   for(var i=0,j=els.length; ij; i++)
      if(re.test(els[i].className))a.push(els[i]);
   return a;
}

Next we need to write the code that fulfils the list we wrote previously:

// Hide all classes with the className "tooltip"
var tooltips = getElementsByClassName(
   document.getElementsByTagName("body")[0], "tooltip");
for (var i = 0; i  tooltips.length; i++) {
   tooltips[i].className += " hide";
}

var tbodies = document.getElementsByTagName("tbody");
for (var i = 0; i < tbodies.length; i++) {
   var trows = tbodies[i].getElementsByTagName("tr");
   // Add a function to each tr that makes it show it's cells on mouseover
   for (var j = 0; j < trows.length; j++) {
      trows[j].onmouseover=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className+=" hooover";
         }
      }
      // And hides all child cells on mouseout
      trows[j].onmouseout=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className =
               childtooltips[k].className.replace(new RegExp(" hooover\\b"), "");
         }
      }
   }
}

A note here is that we don't loop over the first table row. That one contains the table headers and shouldn't react to us hovering it.

Last but not least we need a few lines of CSS to make the page behave like we want it to. Without either Javascript or CSS enabled a plain table should be shown with all cells visible. If you have both enabled you don't want the cells that contain the tooltip to take up space in the table. Here's the code:

.hide {
   left: -10000px;
   position: absolute;
}
.hooover { left: 80px; }
tr { position: relative; }
.a1 {
   border: 1px solid Black;
   width: 300px;
}
.a2 { padding: 20px 0 0 120px; }
.a3 { padding: 20px 0 0 200px; }

The "hide" class is added to any element with the class "tooltip". Why not make the tooltip class hide the cells right away you ask? The answer is that then a non js user would not see those cells at all. This way we get the best of both worlds. To remove the hidden cells from taking up space we remove them from the flow with position: absolute; and to hide them we use left: -10000px.

The "hooover" class get enabled when we mouseover one of the table rows. It just sets the left value to a far more visible 100px. Lastly we set some styles on the a1-a3 classes that makes the tooltip look a little better. We use a1 as a background and place the other two classes on top of it to make it look like they are in the same box.

And that's it, a table turned into a tooltip, another user is a little bit happier and all would be fine... Unless of course the user had left the channel before I could show him my solution. Damn.

Friendly Bit - Web development blog

Partial XMLHttpRequest responses?

Geolocation and Google maps

Animate from one element to another (jQuery plugin)

Lazy Loading Asyncronous Javascript

Script tag#

Async pattern (A script tag written with javascript)#

Lazy load pattern (Async pattern triggered onload)#

Unobtrusive lazy load pattern#

Rendering a web page – step by step

Make a div clickable

How it works#

Interface developers and security

Worth a look: DOMAssistant

Sharepoint 2007 from an interface developer’s view

"Customization"#

Specifics#

Development#

Accessibility#

Page size#

Javascript and Browser dependencies#

Changing the CSS#

Share point and Master pages#

Default .NET controls#

In summary#

Manipulating innerHTML removes events

I’m an interface developer

What is Web 2.0? Really.

The hunt for a definition#

Ideas that are part of Web 2.0#

User generated Content#

Radical trust#

Syndication of content and services#

Long tail#

Collective intelligence#

Techniques involved in Web 2.0#

AJAX (and other javascript)#

Feeds (RSS, Atom)#

Tags#

Summary#

Improving interactivity with Javascript

Slider#

Date picker#

Smart text boxes#

Mixing text inputs with select boxes#

Drag and Drop#

Collapse and expand control#

Advanced tooltips#

Autosaving form fields#

Auto validation#

Controls affecting each other#

Image handling#

Search-based or structured navigation#

Better looking form fields#

Sortable items#

Flash-only vs. AJAX sites

What kind of sites are built with only Flash?#

What's the purpose of them?#

Updating flash files is hard#

Flash is not hip any longer#

Flash-only vs. AJAX - The showdown#

Web development blogs you should read

How web standards feels

Concept: Four layers of web development

Data layer#

Structural layer#

Design layer#

Behavioral layer#

Putting it all together: four tier web development#

Challenge: What’s the worst you can do?

The challenge#

Inspiration for a truly hideous design#

How to accept the challenge#

Extra fluid layouts with javascript

How it's done#

Line Breaking With Javascript

How it works#

Make a tooltip out of some columns in a table