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

1. Small. I don’t want a big mess for them to include on their sites. 10-15 lines, tops.
2. Stand-alone. The environment is unknown, so we can’t rely on any external dependencies, like javascript libraries.
3. Cross-browser. I have no idea what browsers me 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.
4. Asynchronous download. The download of my script should not block the download of any script on their sites.
5. Lazy Loading. If my site is temporarily slow, I don’t want to block the onload event from triggering until after our site responds.
6. Preserve events. Any events used should not override any events on the customer’s site. Minimal impact, like I said.
7. 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!

Since people who just spent over $500 for a toy, are very subjective in their judging (buying something bad would make you look stupid!), you have to take this review for what it is: Me trying to justify buying an expensive toy. To help my mind balance things a bit, I’m going to talk about two good things, and two bad things about the iPad.

• Good: Looks, UI and surfing the web
• Bad: A horrible Developer Platform
• Good: Games that use the touch interface
• Bad: Downloading apps through iTunes
• Summary

Good: Looks, UI and surfing the web

An iPad, here shown next to a old banana for comparison. Click for bigger image.

The area where the iPad really shines is when it comes to the look and feel. It’s simply gorgeous, feels good in your hand, and makes all your friends instantly drool (like you expect them to). The screen is as sharp (or sharper) than a computer monitor, and its brightness could light up a dark room.

Working with it is just as pleasant. You click, swipe, pinch and type, like you’ve done nothing nothing else in your life. As someone who haven’t used an iPhone before, I’m impressed. Those that have, say that the iPad is even snappier than the iPhone. Some application are of course better fit for a touch interface than others. Google Maps is one of them, when a large display combined with panning and zooming makes the old arrow and zoom buttons on the traditional Google Maps interface feel like stone-age.

They keyboard surprised me by being even better than I expected. In landscape mode it’s almost as large as a laptop keyboard, and in some cases even faster than a traditional keyboard since you don’t have to push, just touch the buttons. The biggest keyboard problem though is of course that you usually only have one hand available. When you have two hands, it’s great.

Another area where the iPad really works is as a window to the web. Safari comes pre-installed (Microsoft monopoly anyone?) but works like a charm. Pages load quickly, and swiping to scroll and pinch to zoom works just like it should.

Web standards are well supported, like you expect from Safari. But some new problems emerge when looking at HTML5 demos though:

• The Safari inside the iPad isn’t as performant as a desktop browser. So there’s lots of lagging when trying to rotate things in advanced ways.
• Even though Apple has decided to ban Flash and pick a fight with Adobe, many new apps are built to take advantage of the mouse moving around. On the iPad, there’s no mouse pointer, so you have to simulate one by touching the screen and moving the finger around.
• Keyboard navigation is strange, because most of the time, you don’t have a keyboard. The keyboard only shows up only when you focus a text field, at other times, you’re lost.

These things sound like annoyances, and they are, but they are also quite minor. For all the surfing you usually do, the iPad works just like it should.

Bad: A horrible Developer Platform

As you’ve probably heard during the last few weeks, Apple have no clue whatsoever about how to cultivate a vibrant developer community. Let’s look at the facts:

• To distribute your app you need to join the iPhone Developer Program, that costs you $99-$299 per year.
• To download the SDK you need to fill out a huge multi-step form (where almost all fields are required), and where you’re asked to give away lots of personal information.
• When you “publish” your app it has to go through a manual approval process, which could take months if you are unlucky.
• You need to approve to a ridiculous legal statement preventing you from using some programming languages, and making calls to some APIs.

To quote:

“3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”

Needless to say, I’m never going to be develop anything for the Apple Platform. Apple and its developers is much like one big company (with strict rules). The only difference is that instead of a salary the developers get to pay to work for them. Good for Apple, horrible for developers.

Good: Games that use the touch interface

There are lots of good games that have started to take advantage of the big touch surface to make fun interaction styles possible.

• Tap Tap Radiation builds on you tapping the screen in pace with the music playing. The place to hit move around, just like the markers that indicate where to tap.
• Asphalt 5 is a beautiful racing game where you use the iPad as a steering wheel and tilt it back and fourth to steel. Since the accelerometer is so sensitive it works remarkably well.
• N.O.V.A. – Near Orbit Vanguard Alliance is a first person shooter that uses gestures to control who you shoot and how. Advanced gestures makes it possible to throw grenades that fly around corners, and targeting multiple enemies at once.

Simply put, there are lots of fun games for the iPad, and the reason is experimentation with the touch interface. Combine this with several days of battery power, and you have many hours of fun ahead of you.

Bad: Downloading apps through iTunes

A closer look at the iPad, still with the banana present. Click for bigger image.

Sadly, the only way to get apps legally into the iPad is through iTunes. Since my iPad was bought in the US, the App Store icon leads to a “Your request could not be completed” with no further info. So it seems that the App Store is only launched in the US. Silly me, that thought the web was an international thing.

Anyway, it is possible to get apps into the iPad without getting a fake american App Store account. You just use iTunes to download the apps to a desktop computer, and then sync your app to the iPad. It’s easy.

Well, strike that, using the iTunes store is not easy. Not being a previous iPhone using I had thought that downloading apps from iTunes was like shopping on Amazon. IT’S NOT EVEN CLOSE. This is how Apple built iTunes:

1. Take one  fully functional e-commerce web site.
2. Make it slow so that people like me that surf on a 100 Mbit/s fibre connection have to wait several seconds after each click.
3. Make sure you can only access the store through a special downloadable app, that requires you sign several legal agreements, and leave away personal information, before you even bought anything.
4. Remove the possibility to sort through listings, remove any information what the list is currently sorted by, and hide options to only show apps for the device they know you just connected (the iPad).
5. Tada! You’ve built iTunes!

Needless to say, each visit to the iTunes App Store is a bad experience, and no something you want to do often.

Summary

Situations where I see myself using my iPad:

• In bed, watching public television through Svtplay. They have a great app, that is mainly adapted for iPhone, but scales up when used on a bigger screen.
• Casually surfing the web from the couch. This includes checking my e-mail (which is IMAP over SSL, which works fine), checking my feeds through Google Reader, checking Facebook through the iPhone app (which can be pixel-doubled to fit the screen nicely), and twitter through twitterific.
• Surfing all kinds of maps, and wikipedia in some social context. If I ever get into an argument about where a country is exactly, I’m pull up my iPad instantly and check it.

And that concludes this iPad review.

iPad rests here, next to banana.

As usual I’m looking forward to your thoughts in the comments. Thanks for reading!

1. You type an URL into address bar in your preferred browser.
2. The browser parses the URL to find the protocol, host, port, and path.
3. It forms a HTTP request (that was most likely the protocol)
4. 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
5. Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
6. When a connection is open, the HTTP request is sent to the host
7. The host forwards the request to the server software (most often Apache) configured to listen on the specified port
8. 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?)
9. The plugin gets access to the full request, and starts to prepare a HTTP response.
10. 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
11. Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
12. The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
13. The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
14. A DOM tree is built out of the broken HTML
15. 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.
16. Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
17. Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
18. The browser renders the page on the screen according to the DOM tree and the style information for each node
19. You see the page on the screen
20. 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…)

So yesterday, when Brandon Cobb of Super Fighter Team asked about a design with a fixed header, fixed left column, and scrolling right column, I thought I’d renew my take on simulating frames with CSS (The original article is still good for background information, so I still recommend reading it).

Position: fixed CSS templates

The idea is this: Instead of specifying what parts of the page should scroll, we can specify what parts should stay fixed when scrolling. This makes it easier to deal with several fixed parts of the same layout, but also allows us do to things frames cannot do.

So what’s the trick? Well, position: fixed does exactly what we want. It works just like position: absolute, but it stays still when the page is scrolled. So it’s really just a matter of making sure things don’t overlap.

• Demo: Fixed top, fixed left, scrolling right
• Demo: Fixed top, scrolling bottom
• Demo: Fixed left, scrolling right

Try resizing the page, and see how the scrolling works. The templates have been tested in: Fx 3.5, IE8, IE7, IE6 (see note below), Opera 10, Safari 4; all on Windows. Let me know if you can test it on more browsers, or find bugs.

You’re of course free to use this templates as you see fit, with or without a link back, commercially or not. Consider it public domain.

Fixes for IE6

As I’ve said, these designs don’t act the same in IE6. Instead of some parts being fixed, the whole page scrolls in IE6. The good thing about this is that IE6 users won’t see that your site is “broken”, they will just get another design. And as the number of IE6 users goes towards zero, your design will be more and more consistent :). The fallback is very simple, IE6 gets position: absolute instead of fixed, using the !important hack (you should probably use conditional comments instead).

Hope these templates are useful for some of you!

Just to name a few :)

Problem is, with many of the above, if something breaks you’re out of luck. Because it’s god damn impossible to get a hold of someone that you can talk to. Do you reach anyone at Google with your e-mails? Does anyone from Google read your forum posts? Highly unlikely.

Google is a great example of support gone wrong. I think the explanation is easy: Few of the programmers I know want to deal with support. They want to deal with coding! And since Google is a company of programmers, it doesn’t want to do support.

Let me tell two stories:

Feedburner

Feedburner once was a great company, with a simple but thought out service. They gave you subscriber statistics of your RSS feed. You just redirected your feed to them, and made all your subscribers sign up to their generated feed, and they did all the tricky calculations. Simple, efficient.

As a company Feedburner understood the value of being personal. Messages throughout the site stated “My feeds like a little namespace to call their own”, “Sometimes your feed just wants to look good. Spruce it up in the following ways”, “Oh dear, what kind of trouble?”. Nice personal touch :) Feedburner developers where easy to get in touch with, an e-mail and you had a friendly, knowledgeable person to talk to.

Then Google came along and bought the whole thing. Everything was rewritten to Google’s platform, domains where switched, and chaos ensued. Of course, during that time, Feedburner’s previous support people totally vanished, and everyone was directed to the Feedburner Status Blog, when you could confirm they where not working on your problem. Just great.

For three weeks now, my subscriber stats have jumped from 800 to 3000, back an forth, several times per week. Nice, isn’t it?

Feedburner is apparently broken, and the simple service of delivering feed statistics doesn’t work.

So I post to their Google Group, the place where you should ask questions about the service. Three months later, several other users have reported having the same problem, but no reply from a Feedburner developer.

Now I’m thinking of switching. Anyone have a good alternative ready?

Google Wave

Services that start at Google are even less likely, compared to acquired services like Feedburner, to have proper support. It’s just not a priority, and there’s far too many interesting programming challenges to deal with users.

So when Wave gives me an old picasa name as my username (<company name>.<place of one of our conferences>@googlewave.com), I know there’s very little chance that I’ll get help from anywhere. The official channel to ask for help is their support forum, but it doesn’t seem that they reply to issues there. My message there from two weeks ago stands on it’s own, with no replies.

It’s the proposed revolution that will replace e-mail, and I can’t use it :(

Bad trend

This trend of Google not offering even basic support from dedicated people is a unfortunate development, that should be taken seriously by executives at Google, and dealt with at a very high level.

Launching new web services is easy, improving a services based on feedback is much harder. Google has not yet managed to crack that nut.

What? Load a browser as a plugin inside another one? I guess this is a real war after all? Who will build the first browser to load Firefox into Chrome? Internet Explorer inside Firefox?

Why? Well, now they don’t have to care about Internet Explorer support at all. Felt that heavy weight lift from your shoulders? Suddenly large parts of HTML5, CSS3, and modern javascript, is available to them, with no backporting and performance tuning needed. Must be fabulous.

Now. Combine that with the possibility for the developer to choose when to trigger the different browsers. We’re up for a whole new ride. You’re invited.

Now, this makes to tricky to combine images. Something that repeats horizontally can’t be combined with something that repeats vertically (unless there’s transparency involved), and wide images can’t be combined with narrow ones. So combining is usually tedious, manual work, both to combine the images and then calculate the new background-positions required.

Lucky for us then, that there is a tool called SpriteMe, available as a bookmarklet (a bookmark containing javascript), and as an excellent online demo that walks you through how it works. SpriteMe does all the hard work for you, you just have to copy and paste both the combined images, and the new background rules, to your site.

Decreasing the number of HTTP requests have never been simpler. Well done Steve Souders!

Anyway.

Two years ago, I got to test Spotify, a music streaming that will soon launch in the US and is heavily anticipated. It completely changed how I listened to music, I deleted all my mp3:s and is now streaming all my music. Voddler is a similar streaming service, but for movies.

So, what do I think of it?

First of all, Voddler is in a very early phase of testing. It’s what I would call a “real beta“, where the client crashes frequently, subtitles sometimes lag behind, the interface is tricky to use, and several features just don’t work.

Thing is, I’m quite certain Voddler will revolutionize how I watch movies, anyway. Because at the core of Voddler is HD-quality streaming, that just works. Believe me, I normally don’t watch that many movies, but have seen four, in the last 48 hours. They are just a couple of clicks away, and start in 10 seconds (during which you’ll watch a commercial). Here’s some screenshots.

Now. I’m saying that the client is a beta, and that there are serious bugs left, what kind of bugs do I mean?

• About half of the menu options don’t work. “Tv series” lead nowhere, I can’t browse movies by actor, director, studio, and several genres are empty. In my opinion, they would gain a lot by just removing those options until they lead somewhere! This is a no-brainer.
• The client freezes and crashes regularly, and I have never been able to watch two movies in a row without restarting in between. This of course requires squashing bugs that are left in the code, and improve the testing procedure, so that such bugs never reach production code. Using mozilla-style reporting that allow people to send in crash reports is probably a good idea at this stage. The code is based on XBMC, and people say stuff like “how could they add that many bugs to a product that good?!”. Voddler, don’t make it that easy to dismiss your hard work!
• Sometimes the subtitles skip some lines. I watched Antikiller, a russian action movie, five times important lines were shown only half a second on the screen, making me miss important pieces of the story. I’m not sure if this had something to do with the subtitles for that exact movie, or lag because of Voddler, but I know that it was a crappy first impression of the client. It just has to be fixed.
• The support forum is so slow it’s unusable. My guess is that it’s on the same network as the movie streaming service, and therefore goes down together with that one. Those two just have to be independent, as you need the forum most when the other is down.
• The UI doesn’t work usability-wise. First of all, it’s built for television sets, which means that only the keyboard works (arrow keys, space and esc), no mouse support. Several of the menues cycle (when you’re on the end the first item appears again), so you’ll easily loose track of where you are. There are small errors all over the place, things that makes finding and starting movies difficult.

So, in summary, the core of Voddler is good, but the interface needs quite a lot of work before it can be released to the public. No matter what, I’ll keep following the development of this product!

In general, it seems that when you Americans stop us from using your servies (ie. Hulu), we Swedes build our own services. First Spotify, now Voddler.

As web developers, we should be the ones complaining the loudest. We have so much to win on IE6:s death it’s silly. Just look at the below list of things IE6 can’t do, but IE7 can (the next worst browser):

• Native PNG alpha transparency without silly hacks.
• Several selectors: Child selector (“>”), Adjacent sibling selector (“+”), Attribute selectors ([attr=value]), and General sibling selector (“~”, CSS3)
• Min-height, Max-height, Min-width, Max-width
• Multiple class/id selectors in the same ruleset (ie. .class1.class2 { … })
• :hover on all elements, not just links
• position: fixed
• Native XMLHTTP (Without ActiveX)
• International Domain Names (IDN), the ability to use UTF-8 chars in domains
• Page zoom that zooms the whole page (don’t worry about zoom)

This is a huge step forward for us web developers. Huge! Bigger then when CSS3 comes out, because we won’t be able to use that one for years. Someone is pushing the front of what’s possible, I’m pushing for the front of what’s usable.

What can you do to help me get everything in the above list? And, did I forget something?

Sources:

• CSS Compatibility charts
• IE6 vs IE7 – New features in Internet Explorer 7

Many of Tapestry’s problems comes from their design decision to parse the HTML you’re trying to output. Yes, Tapestry parses your HTML, and adds stuff to it dynamically. This is nothing new, anyone that has played with ASP.NET knows how hidden form elements get stuffed in here and there. This is a nightmare for an interface developer, we need exact control over HTML to do our jobs well.

Tapestry does horrible things to HTML:

• Several extra javascripts and CSS files are referenced in the head tag. There is no simple way to get rid of these.
• A meta tag which states that the tapestry did generate this page, is added.
• The two above are added to the head, and if a head tag doesn’t exist, it gets added. Never mind that your current little HTML snippet was just a little part of a page, that was being fetched with AJAX, Tapestry will add a head tag for you.
• More javascript, and a hidden div with a firebug-like console, is appended to the end of the body element.
• Self-closing tags are expanded to a start tag and an end tag (<input /> gets transformed to <input></input>), which means you can’t use XHTML together with Tapestry.
• All whitespace is removed by default, and you have to disable the “feature” on a tag-by-tag basis (“Please don’t strip whitespace inside this list, IE6 goes crazy then”). This is a mess for interface developers, who know that whitespace matters for rendering. It was even pointed out to Tapestry developers early on, but was ignored.
• There are ways to do loops, if:s, reference variables and generate URL:s, but all of these are based on the HTML parsing. And as a good parser, it skips all comments. This means using tapestry template code inside a HTML comment will not work. When do you need that? Conditional comments! So what if you want an URL generated to your IE6 stylesheet? No go. You’ll have to write a custom component that does that for you.
• Changes the id of all your forms to “form” and adds name=”form” (which is invalid HTML).
• Adds a hidden “t:formdata” field to forms, much like the dreaded ASP.NET viewstate.
• One of the javascript files added is prototype, a javascript framework which isn’t compatible with jQuery. So you have to rewrite your javascript code to work in “No conflicts mode” if you want it to work with Tapestry.

No. Tapestry was clearly not built with an interface developer in mind. Why is it so hard for many web framework developers to just talk with people that work with HTML, CSS, and Javascript? Please ask us before implementing stuff like the above. We’ll gladly give you our viewpoint.

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.

Internet is really a commodity nowadays. People process loads of  information on the web every day, and this of course affects how they expect newspapers to behave. Every time I hold a big newspaper in my hands I’m surprised at how inferior it is compared to reading news on the web.

Newspapers have problems with references

If I find an interesting news story on the front page, it’s a mess finding the full article in there. The references are done with page numbers, but with page numbers that are local to a certain part of the paper. “Culture, page 7″. And the culture part is stacked inside the part I’m reading, so I first have to find that one, then find the page numbers (which are removed from pages with ads), and then finally find the article I wanted.

The same is true for related articles. If I read an article I like, it’s quite likely that I want to read other articles on the same subject. Newspapers solve this today by placing similar articles close to each other, and hope that you see them. This is of course limited, and gets harder when pages sizes shrink.

Compare this with clicking a link on the web. If I find an interesting article teaser, I click it, and am instantly taken to the full article. If that article was indeed as interesting as the teaser suggested, I’m often presented with similar articles, from similar categories, and can click them to move there.

Newspapers are slow

Even the most frequently published papers are only distributed once per day. This simply means that papers can’t compete on speed, being first with a certain story. Even if you happen to get your hands on a story at the perfect time, a paper still have to be both printed, and distributed to people. This takes hours.

What’s worse, morning newspapers brand themselves as dealing with  “today’s news”, when in fact it’s the news from yesterday. This hasn’t been a problem before, since there was no faster way to get news. Now there is.

If speed is important to you, you can easily subscribe to news via e-mail, Twitter or RSS, and be instantly updated.

Newspapers are static

Articles in a newspaper are, once published, not possible to update and improve. They are left for the wind, even though there are inaccuracies or important clarifications to be made. Any conversation sparked won’t be there.

This is of course the strongest argument for internet news. A big article will be different if you look at it later the same day. Comments and updates based on feedback are able to improve articles considerably.

Newspapers don’t have enough unique content

Big parts of daily newspapers contain poor rewrites, or plain copies, of articles from elsewhere. The reasoning is probably that they are trying to be exhaustive, give a broad view of what has happened. Problem is, they are hiding their own unique content behind loads of reposts of other’s content.

The same happens on the web, but instead of copying the article you link to it. Then you get to read the news from the real source, and dig in deeper if you want to. Additionally, there’s safegards that stop people from copying other people’s content. For instance, Google have special filters for filtering out duplicate content.

Newspapers are not relevant enough

The biggest reason why I don’t subscribe to any newspapers is that they are not relevant enough. I’m not one bit interested in sports, and still, during big sporting events newspapers push them to the front page, over interesting internet-related news; things I find interesting.

The key here is of course to realize that relevancy is in the eye of the beholder. Only I know what I find interesting, and relevant. Why trust someone else’s relevancy ranking when I can easily get my own ranking online? Even if I don’t want to tailor-pick RSS feeds and build my own custom news feed, there’s someone out there that has more similar taste than the four major newspapers here.

So, what should newspapers do?

Well, they have two options: One, they could keep writing articles, hoping that the quality will be high enough to turn the trend, or Two, they could start thinking of how they deliver news. The expectation of how news should be served is changing. It now needs to be delivered…

1. … filled with references for digging deeper
2. … faster than once a day
3. … in a manner where people’s contributions enhance it
4. … with a quality stamp that ensures that you’re reading something you couldn’t get anywhere else
5. … personalized to my own specific taste. No sports.

Is there any other way to do this than focusing aggressively on the web, and less on dead trees?

Presentationen håller jag tillsammans med Visar, och Marwin, två av våra extremt duktiga Art Directors, och ni ser mig sist i presentationen.

You could think it’s strange that in 2009, we can’t use any fonts we want on the web, and I would fully agree. You could ask whose fault that is, and I would reply with a quote from a meeting between browser makers in august 2008:

“My understanding, from Chris, is that supporting direct linking of the fonts would be a great disservice to the independent font industry. A high-level decision within MS says we won’t implement that in IE. So what is done other than EOT is [probably] not going to interop with IE. “

“MS” is of course Microsoft, and “Chris”, is referring to Chris Wilson, Platform Architect of the Internet Explorer Platform team. The same Chris has also written a longer text about font linking on his blog. I first thought that this was something the font foundries had pushed through, but on the above post it seems that this is also a personal opinion. Browsers (but only IE) need to protect fonts from getting pirated.

And that’s the whole reason why we don’t have cross-browser fonts on the web today. (Although direct linking to fonts work in all the latest versions of Firefox, Opera, and Safari). Nice isn’t it?

Embedding fonts anyway

Of course, there’s still a need to embed custom fonts on webpages. That means clever developers will develop techniques will work around a broken internet explorer. No matter what the font founderies and Internet Explorer team thinks.

My reasoning for why this is a good thing is because that’s how everything else works in the browser. Even though anyone can copy an image, we have a big market for stock images. Even though anyone can copy the HTML, CSS, and Javascript of a whole site, we still have people building websites for money. Fonts are no different, and the exact same business model that works for stock images can work for fonts.

One popular technique is sIFR, a way to use javascript to replace regular html with flash. Inside the flash you embed the font you want, and voilá, you can use any font you want. sIFR misses one crucial point though: It’s far too annoying to embed a font inside a flash movie. You need a commercial program, and you need to know what you’re doing. And you’re dependent on flash support. It’s not that bad, but a bit annoying to work with.

So for a recent project I’ve been playing with Cufón, which uses javascript, but draws on canvas, or in VML for browsers that don’t support canvas (IE). They have an extremely friendly website, which walks you through the process of getting things to work, and the font conversion needed is available directly on the website. I’ve only used it for simple cases, but it works really well.

All in all, Cufón is a great alternative until IE gets its shit together.

PS. Famous people that don’t agree with me:

• Richard Rutter, author of the clagnut blog suggests that font founderies server-side generate our fonts on demand, much like Google Maps only sends a part of the map, and not all of it.
• Joe Clark: “Quite simply, there is no broad clamour among Web designers to use any font they want.”
• Jason Santa Maria: “embedding normal typefaces without any sort of precautions is putting it on a silver platter for anyone to take freely. That’s like saying people steal from stores anyway, so let’s just leave the doors unlocked at night :)”
• And of course, the IE team…
• …and all the typeface makers in the world.

So the presenter fires up the projector, connects it to his Mac, and looks at the projection. Half the site is outside of the screen. Turns out the maximum resolution is 800×600, and we’ve designed the site for 1024! People started looking at each other.

“We have to be able to show the site with a projector!”, one from the audience proclaimed.

Awkward silence.

I’ve rarely heard people working with accessibility mention projectors as arguments for accessibility, but it turns out they are great for that purpose. Just look at it like this:

• Resolution is often at the very low end, and they get upgraded much slower than regular computers.
• Brightness is much lower than on a computer screen, especially at daytime, in a room with bad curtains.
• Many presenters move their mouse by looking at the projection, which makes clicking things harder.

Interesting isn’t it? Those three just happens to be exactly the same things that we try to optimize when working with accessibility:

• We try to avoid having people to scroll sideways, because unexperienced users find that hard to do. A flexible design, that can adapt to different screen widths (within reason), is a great way to accomplish that.
• We work hard to make sure that the contrast between page elements is big enough. That way, the large part of the population with low vision (don’t forget those that left their glasses at home…), can use the page without problems.
• We expand clickable areas of links and buttons, to make sure people with motor disabilities can still use our site.

So, we could just as well have been optimizing the “projector experience” all along.

How did the presentation go? Well, we simply zoomed the site out one step, and continued as usual. You are making sure your site zooms properly are you?