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…)

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.

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.

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…

“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 <link> 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.

Share point and Master pages

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.

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.

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?

1. 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.
2. 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.

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 organisers 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 clairification 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
• Radical trust
• Syndication of content and services
• Long tail
• Collective intelligence

User generated Content

Many companies still view the web as a one-way medium, an extension of a paper catalogue, 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 reprioritize 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 organise 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)
• Feeds (RSS, Atom)
• Tags

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 analysing 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?

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!

Search-based or structured navigation

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!

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.

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

• 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?

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)

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.]

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.

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.]