Yesterday I was in Barcelona, Spain and talked to a few dozen local developers about the things they can find on the Yahoo Developer Network to have an easier time building web sites and impress their bosses. Amongst other things I showed:

• How to do 4 web searches with one http request (also in pure JavaScript)
• How to build a web site with information about Barcelona without owning or hosting any of the data

Here is the presentation and my notes with the source of the code examples for you. You can “download the slides as a PDF (11mb) from S3”:http://chrisheilmann.s3.amazonaws.com/developer-evening-barcelona.pdf or watch them on slideshare:

Notes:

Five things for you

Today I am going to talk about five things Yahoo offers to developers. In case you wonder, Mortadello y Filemon is actually rather big in Germany – known as “Clever and Smart” hence I couldn’t resist using them.

English only

Sorry, but I don’t speak any Spanish, but there are colleagues of mine around for Q&A later who can translate if needed. Also, if I speak too fast, just shout and I will try to make it easier.

I am Chris

I’m Chris and I am a developer evangelist. As you can see I also speak with my hands a lot, but that is because I am passionate about what I do. I want to make the web an easier, more professional environment to work in and a media that people can enjoy regardless of ability or technical setup.

Get this talk and others later

This is my main web site where I publish all of the talks I give, videos and other goodies. So this presentation will end up here later on and you can re-mix it for own trainings or presentations. Creative Commons rocks.

The Yahoo Developer Network

I work for the Yahoo Developer Network which you might not have heard of before. In essence what the YDN does is offer almost everything you see on Yahoo – the data displayed and the interface elements used for you to use in your own products via APIs, SDKs and a great development framework. The YDN homepage is your first stop for all the information I am talking about today.

1) Research

Let me start by showing you some of the research we’ve done and the results we offer you to build your own solutions on. In addition to what I am showing here also make sure to chat to some of the colleagues here, as we have a research lab here in Barcelona and they are working on some really cool products.

Patterns

The Design Pattern Library is a collection of solutions to problems or tasks users of our web sites and applications had. We do a lot of user testing in labs and we ask the right questions to find out exactly what people consider the easiest way to for example pick a date in a web form. All of this research is documented in these use patterns with a description of the problem, an explanation of the solution and a cross-reference to where in Yahoo we use the solution. If you build an interface and you don’t have time or budget to do your own research, this is a great resource to use. The patterns are creative commons so please tell us if your experience differs and we can amend them.

Stencils

If you do visuals all of these patterns are also available as stencils for all major design tools. That way you can easily build and design an interface that your developers will be able to create in CSS, HTML and JavaScript.

Performance

The Exceptional Performance section of the Yahoo Developer Network is where we give you all the information how we made our web sites behave faster and more responsive. In our world every millisecond the page takes to load and display counts – we can relate every second wasted to money lost. While your sites might not be that dependent on great performance it does never hurt not to waste your visitors’ time. In this section you find tips and tricks how to tweak your server, how to write CSS and JavaScript and how to optimise images easily organised and explained in detail.

2) Flexible, professional development

As a large company we need to be professional in how we work with each other as developers. There are dozens of offices with hundreds of developers in Yahoo and we found that every developer and every office solves the same problems, makes the same mistakes and re-invents the wheel over and over again. Web development is a very undefined area and the biggest issue is that we spend 90% of our time fixing bugs rather than developing. We wanted to change that and make sure that we can concentrate on architecting our software solutions and develop and tweak them for the users’ benefit rather than fixing annoying and confusing browser bugs.

Graded Browser Support

The first thing we needed to make sure is that we define and describe the support we have for different browsers. This is a methodology and resource site we have called the Graded Browser Support and is something you can use for your product documentation and pitch, too. You cannot give every visitor of your web site the same experience regardless of browser and you actually should not even think that way as that kind of thinking is against the main principles the web was invented for. You have to make your products work for everybody, but you can give a different experience dependent on the sophistication of the visitors’ setups. This is what the GBS does. We define which browsers we support fully and test the high-end experience for. All other browsers don’t get this experience but something that works regardless.

The Yahoo User Interface library

The Yahoo User Interface library was the next big step to take towards professional development. This is a library ranging from CSS solutions, over JavaScript components up to plug and play widgets that are based on the support ideas we defined in the GBS and best practices we found in our pattern research. The YUI is where we work around all the annoying bugs and problems browsers and web technologies have to allow us to build solutions without wasting our time on wondering why they don’t work in setup xyz. By keeping all this in a base library we can fix and apply for any new technology or browser coming out. If we did all of the fixing in our sites we’d have to revisit each and every one of them when technologies change. This is not effective, hence we built ourselves a library.

The myth of the unstyled page

There is no such thing as an unstyled page in browsers. If you don’t apply a style sheet, then browsers have an in-build default style that varies from browser to browser. This makes it impossible for you to design a predictable interface. That’s why we created a style sheet that un-does all the styling browsers apply to a page. This means you can start with a clean canvas.

Predictable typography

Typography was he next hurdle. Every designer will give you font definitions in pixels and when you set the font in pixels, Internet Explorer 6 will not allow visitors to resize the text on your page to their needs. This is why we created a style sheet that resets the font of your browser to a readable minimum (again based on user testing) and has a percentage scale for you to use that relates directly to pixel sizes.

CSS layouts

Layout in HTML should not be done with tables or presentational markup but with CSS. The problem there is that browsers support the techniques we need to use to make them display our layouts in different ways. A lot of hacking has to be done to create a layout that works across the board. This is why we defined a grid structure for our sites and a style sheet that works. All we need to do now is add the right IDs and classes to a few DIV elements and we have a working layout. If you are really lazy, we even have a CSS grids builder tool for you. The CSS is hosted by us on a distributed network of servers and gets delivered to your visitors from a server near them which is great for performance. You can however host the CSS yourself, too.

Specialised solutions

The JavaScript part of the YUI is not a catch-all solution for all development tasks you’ll ever have to tackle but instead is cut up into smaller components that all do one thing and do it very well. That way you can mix and match the library components to the need of your solution and keep the footprint low.

Widgets

On top of the YUI components we built widgets that relate to the design patterns. These are the things you see on Yahoo’s pages – sliders, tabs, menus, rich text editors and the like. We even have a showcase where we proved that you can rebuild the interface of Yahoo mail by using these free and open source building blocks.

Skinning

The look and feel of all of these widgets can be changed by changing a style sheet. This is very important. You should never have to alter JavaScript simply to make a tab a different colour.

Working widgets

This is an example of one of the widgets – the autocomplete control. As you can see the widget is built to solve a pattern we found in the pattern design library and using our logger control gives you full information about what is happening to it at every step of the process of using it.

Progressive enhancement

Our widgets are built to work and to give a smoother experience only when and if the browser supports it. This means an autocomplete control will be a text box when JavaScript is turned off. A data grid or complex sortable and styled table will be a simple, accessible data table when JavaScript is turned off. That way you build working solutions for every user and you don’t promise functionality that isn’t delivered. Users trust you, if you don’t hold your promises you will lose them.

Event driven architecture

All of the widgets are built with custom events and if you want to enhance their functionality or override it you can do that at any point of the interaction journey by subscribing to the custom events that get fired. This allows you to build solutions that need to do something extra for you without compromising the underlying code. You should never change the library code as that stops you from being able to upgrade the library to a never version.

The logger control

One of the most annoying things in web development is that not every browser gives you good debugging tools. The Logger control works around that issue by providing you with a debugging console that works across all the browsers we support.

The profiler

If you wonder why your JavaScript is using up a lot of memory and slows the computer down you can use the YUI profiler to analyze what is going on inside your JavaScript and fix bottlenecks that way.

3) Documentation

Both the YUI and all of our APIs come with extensive documentation written by a professional team of tech writers.

Online and offline docs

The APIs come with a quick “get started” guide and a full documentation – in many cases even available offline as a PDF version.

Step by step introduction and examples

The full documentation comes in easy to digest chunks guiding you where you need to go to find exactly the right kind of information.To get you a quick start there are copy and paste examples of demo code.

Code generated documentation

In addition to this the YUI also has a JavaDoc style documentation which is generated from comments in the source code. This means it will always be up-to-date even if there are quick fixes in the code. The tool to create the documentation from JavaScript code is also available.

Cheatsheets

Another nice service the YUI has is a zip of PDF cheatsheets for all the different widgets. These are A4 sheets with all the necessary information to get you started and find out how to quickly change an implementation of a certain widgets.

Forums, lists, blogs and videos

If you are still stuck or are just not a person receptive to code or text there’s the YDN theater with lots of videos of presentations, screencasts and demos. There are forums, mailings lists and other forms of communication with the teams available in the communities section

4) Things to impress your Boss with

One of the things I am always trying to make sure is that you can go to work tomorrow and tell your boss about some things you can use to save the company money and time or just impress him/her. So here are some ideas.

Build an own search engine with BOSS

Yahoo BOSS is an API that gives you access to the search index of Yahoo. You can display results from Yahoo, re-order and display like you want and mix the results with other data. That way you can easily build a vertical search engine. Furthermore the data includes information not displayed in the normal Yahoo search results like microformats, RDF information, delicious tags and keywords.

Research keywords for your market

Using the keywords in the BOSS data I was able to quickly build Keywordfinder. What it does is searching Yahoo for a keyword you enter, return the 20 first results, get the keywords users entered to find these sites, rank them for you and give them back in order of relevance. You can use this to see what terms you should have in your titles, headings and copy to get more search engine love.

Create a performance report and recommendations for your site

YSlow is a Firefox extension that automatically tests web sites against the best practices Yahoo found in the exceptional performance section. You can easily find the issues and get inline tips how to fix them. One really impressive part is smushit, which optimizes all your images as a batch and allows you to download them as a zip to replace the original ones.

YQL to remix the web

YQL and especially the YQL console is a terribly easy way for you to access APIs of Yahoo and third parties without knowing much about their authentication, parameter structure or return data. By using YQL remixing the web is as easy as accessing a database. For more detail, check out this presentation on YQL

How about a YQL demo?

This web site about Barcelona does not contain any content on the server but pulls all of the data from third party locations – Wikipedia, Flickr, Upcoming.org and Yahoo weather. The layout was done using the YUI grids builder and the following is all the code that is needed for it to be what it is:

PHP:

<?php
$root = 'http://query.yahooapis.com/v1/public/yql?q=';
$city = 'Barcelona';
$loc = 'Barcelona';
$yql = 'select * from html where url = 'http://en.wikipedia.org/wiki/'.$city.'' and xpath=\"//div[@id='bodyContent']/p\" limit 3';
$url = $root . urlencode($yql) . '&format=xml';
$info = getstuff($url);
$info = preg_replace(\"/.*<results>|</results>.*/\",'',$info);
$info = preg_replace(\"/<?xml version=\"1.0\"\".
\" encoding=\"UTF-8\"?>/\",'',$info);
$info = preg_replace(\"//\",'',$info);
$info = preg_replace(\"/\"/wiki/\",'\"http://en.wikipedia.org/wiki',$info);

$yql = 'select * from upcoming.events.bestinplace(5) where woeid in '.
'(select woeid from geo.places where text=\"'.$loc.'\")'.
' | unique(field=\"description\")';
$url = $root . urlencode($yql) . '&format=json';
$events = getstuff($url);
$events = json_decode($events);
foreach($events->query->results->event as $e){
$evHTML.='<li><h3><a href=\"'.$e->ticket_url.'\">'.$e->name.'</a></h3><p>'.
substr($e->description,0,100).'…</p></li>';
}

$yql = 'select * from flickr.photos.info where photo_id in '.
'(select id from flickr.photos.search where woe_id in '.
'(select woeid from geo.places where text=\"'.$loc.'\")) limit 16';
$url = $root . urlencode($yql) . '&format=json';
$photos = getstuff($url);
$photos = json_decode($photos);
foreach($photos->query->results->photo as $s){
$src = \"http://farm{$s->farm}.static.flickr.com/{$s->server}/\".
\"{$s->id}_{$s->secret}_s.jpg\";
$phHTML.='<li><a href=\"'.$s->urls->url->content.'\"><img alt=\"'.
$s->title.'\" src=\"'.$src.'\"></a></li>';
}

$yql='select description from rss where '.
' url=\"http://weather.yahooapis.com/forecastrss?p=SPXX0015&u=c\"';
$url = $root . urlencode($yql) . '&format=json';
$weather = getstuff($url);
$weather = json_decode($weather);
$weHTML = $weather->query->results->item->description;

function getstuff($url){
$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $url);
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1);
$buffer = curl_exec($curl_handle);
curl_close($curl_handle);
if (empty($buffer)){
return 'Error retrieving data, please try later.';
} else {
return $buffer;
}
}?>

Doing multiple searches with a single HTTP request

Another powerful option YQL gives you is to collate multiple API calls into a single request. Say for example you want to search the web for “vicky, cristina, Barcelona” and also for each of the terms on their own. This can be easily done with YQL in a single statement:

select * from search.web where query in
('vicky','cristina','barcelona','vicky cristina barcelona')

The result can be seen here and this is the PHP code that creates this demo:

<?php
$root = 'http://query.yahooapis.com/v1/public/yql?q=';
$yql=\"select * from search.web where query in ('vicky','cristina','barcelona','vicky cristina barcelona')\";
$url = $root . urlencode($yql) . '&format=json';
$search = getstuff($url);
$search = json_decode($search);
$search = $search->query->results;
$vHTML = '';
$bHTML = '';
$vHTML = '';
$aHTML = '';
foreach($search->result as $i){
$tmpl = '<li><h3><a href=\"'.$i->clickurl.'\">'.
$i->title.'</a></h3><p>'.$i->abstract.
' (<a href=\"'.$i->clickurl.
'\">'.$i->dispurl.'</a>)</p></li>';
if(preg_match('/vicky/i',$i->abstract) &&
!preg_match('/cristina/i',$i->abstract) &&
!preg_match('/barcelona/i',$i->abstract)){
$v[]=$tmpl;
};
if(preg_match('/cristina/i',$i->abstract) &&
!preg_match('/vicky/i',$i->abstract) &&
!preg_match('/barcelona/i',$i->abstract)){
$c[]=$tmpl;
};
if(!preg_match('/vicky/i',$i->abstract) &&
!preg_match('/cristina/i',$i->abstract) &&
preg_match('/barcelona/i',$i->abstract)){
$b[]=$tmpl;
};
if(preg_match('/vicky/i',$i->abstract) &&
preg_match('/cristina/i',$i->abstract) &&
preg_match('/barcelona/i',$i->abstract)){
$aHTML.= $tmpl;
};
$vHTML = @join(' ',array_slice($v,0,3));
$bHTML = @join(' ',array_slice($b,0,3));
$cHTML = @join(' ',array_slice($c,0,3));

}
function getstuff($url){
$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $url);
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1);
$buffer = curl_exec($curl_handle);
curl_close($curl_handle);
if (empty($buffer)){
return 'Error retrieving data, please try later.';
} else {
return $buffer;
}
}?>

You can also do the whole thing in JavaScript:

<script type=\"text/javascript\" charset=\"utf-8\">
function seed(o){
var res = o.query.results.result;
var vmatch = /vicky/gi;
var cmatch = /cristina/gi;
var bmatch = /barcelona/gi;
var out = {
vicky:[],
cristina:[],
barcelona:[],
all:[]
};
for(var i=0,j=res.length;i<j;i++){
var a = res[i].abstract;
var tmpl = '<li><h3><a href=\"'+res[i].clickurl+'\">'+
res[i].title+'</a></h3><p>'+res[i].abstract+
' (<a href=\"'+res[i].clickurl+
'\">'+res[i].dispurl+'</a>)</p></li>';
if(a.match(vmatch) && !a.match(bmatch) && !a.match(cmatch)){
out.vicky.push(tmpl);
}
if(a.match(cmatch) && !a.match(bmatch)  && !a.match(vmatch)){
out.cristina.push(tmpl);
}
if(a.match(bmatch) && !a.match(cmatch) && !a.match(vmatch)){
out.barcelona.push(tmpl);
}
if(a.match(bmatch) && a.match(cmatch) && a.match(vmatch)){
out.all.push(tmpl);
}
}
function $(elm){
return document.getElementById(elm);
}
var vi = out.vicky.slice(0,3).join('');
var cr = out.cristina.slice(0,3).join('');
var ba = out.barcelona.slice(0,3).join('');
$('vicky').innerHTML+='<ol>'+vi+'</ol>';
$('cristina').innerHTML+='<ol>'+cr+'</ol>';
$('barcelona').innerHTML+='<ol>'+ba+'</ol>';
$('allofthem').innerHTML+='<ol>'+out.all.join('')+'</ol>';
}
</script>
<script type=\"text/javascript\" src=\"http://query.yahooapis.com/v1/public/yql?q=select%20*from%20search.web%20where%20query%20in%20('Vicky'%2C'Cristina'%2C'Barcelona'%2C'vicky%20cristina%20barcelona')&format=json&env=http%3A%2F%2Fdatatables.org%2Falltables.env&callback=seed\"></script>

5) Partnering

The really interesting thing is that all of this is open for you to add your own data to. Using a simple XML document called an open table you can make your information available in YQL for other developers.

You can host this XML file yourself if you don’t want the whole world to know yet. For example this open table can be used in a statement like this:

use 'http://eatyourgreens.org.uk/yql/nmm-search.xml' as nmm;
select * from nmm where category = 'art' and
searchterm = '\"tower bridge\"'

This gives developers access to all the information about the objects in the National Maritime Museum in London!

If you want your open table to show up in the console via our team (we do review them for security and quality) all you need to do is add the table to github.

Last Friday I went to sunny Southwark to go to IPC media and gave a brown-bag presentation. The topic: IPC wanted to have a chat about using libraries and why YUI might be a good choice.

I covered the fact that almost every web site out there is broken, that the reason for that first and foremost is bad communication in development teams and that users, developers and clients are all unhappy about it.

I explained that we develop for an unknown environment and that the development tools we have are just not good enough (albeit getting better every year).

I lamented the lack of documentation and handover procedures and that as developers we are inclined to build small solutions for one problem over and over again rather than contributing to a larger framework of solutions.

I pointed out that we tend to go from visual display to functionality rather than the other way around which is why we produce inaccessible and overly complicated products.

As solutions to these problems I showed how YUI is built and maintained, how its development tools allow you to build in a predictable fashion and that it does very well what every library out there should do for you: making web development easier and less random.

Slides

Here are the slides of the talk:

• PDF without notes – 9.5MB.
• PDF with notes – 9.5MB.

Audio

I also recorded the talk audio and you can download the recording at archive.org. Listening to the audio it sounds a bit of a rant, however it is not, I am just very passionate about the subject of professional web development and making the internet the #1 media :).

Notes

Professional Web Development Tools

Almost every web site is broken.

If you look around the web you will find that almost every site is broken in one way or another. This starts with small display glitches and ends with the sites being inaccessible or not working for users out there.

This is bad.

This is really bad. It hurts the web as a media. We re-invent the web every year as we just cannot seem to get it to work for us.

Unhappy visitors.

Broken web sites lead to unhappy visitors. The real problem there is that unhappy visitors do not complain to the people who could fix the issues. Most visitors either think they’ve done something wrong or just try to find another site that offers the same content and works. Both of these visitors will never come back. Other visitors complain but get stuck in help desks and never get their problem fixed as it is highly unlikely to ever reach the developers who could fix them.

Unhappy developers.

It doesn’t reach the developers as they are too busy with building new functionality and other sites. If we don’t build new things all the time we are neither happy developers nor seen as efficient employers. Fixing things isn’t sexy.

Unhappy clients.

This leads to unhappy clients. If a client realizes something doesn’t work on the site they paid good money for they want it fixed, regardless of how fringe the problem is and if it only shows up on their machine with their (most of the time outdated) setup.

Reasons

There are many reasons for the broken web, and nearly all of them are our own fault or based on misconceptions.

Lack of communication

Probably the biggest problem of web development is that the different parties involved do not talk to each other or know each others tasks. Developers think they know more than designers, designers think developers are not creative enough in using the arsenal at their hands and product managers see the brand more than the media and are oblivious to the technical boundaries and freedoms the internet gives us. Furthermore we all have our deadlines, deliveries and reports to make and write which takes up too much of our time.

Development environment

Web development has the most terrible and undefined environment ever. There are thousands of browser configurations and versions, each of them failing in different ways. There is a lack of good error reporting, difference in server configurations, connection issues… you name it. Our development is hit and miss and we fix more bugs than we write code.

Piecemeal development

As web developers we always try to build small solutions that solve a problem we have right now. We don’t really consider that all things on a site and across sites should work smoothly together. We’ve been disappointed so many times that we don’t really believe in that.

Lack of handover and documentation

The piecemeal development also means we don’t really document or hand something over. As the next developer is most likely as inclined as we are to build something new (as it surely will be much better than the crud we are asked to maintain) there is no point in that.

Interface to functionality

The biggest issue is that we start with the interface and the cool effect and then work our way down to what the user needs to achieve. We tend to forget very fast that not everybody has the same experience or could benefit from the great shiny interface we want to build. There is a skeleton under every web application and if that skeleton is weak it will break no matter how pretty and shiny we make it.

Solutions

There are solutions for all these issues.

Back to Basics

The first thing to think about is going back to basics when it comes to development. How does the web work, what is the most basic way of reaching a certain goal.

http://uk.tv.yahoo.com/#yeug-search – is a search box with several options. It used JavaScript to change the form’s action when any of the links were clicked.

Task: Define type of search, enter search term,submit form.

There was no need for JavaScript – all we needed was a radio button group and doing the forking on the backend. Notice that the fieldset, the options and the search button form a logical sentence. This is very important for accessibility.

TV channel programme

http://uk.tv.yahoo.com/#ytv-listings – the hardest interface to build as a web developer. Looks like a data table but could have shows that are one minute long! This would mean the table has to have 180 columns and use colspan on every table cell.

Analyse what data you display, and find the easiest way to show it.
Then make it look the way you want it to.

The information the data displays is much easier shown as headlines and ordered lists. CSS does the rest.

Build things people want and know how to use.

Here is where Yahoo offers their findings of user testing with real end users – http://developer.yahoo.com/ypatterns. There is nothing that can replace this knowledge and it is normally very expensive to come by. Before you even think about building an own interface to solve a problem users have to solve, give this a whirl.

Using technology for good

Flash video players are to date the best way to show video – http://uk.video.yahoo.com/. However, they have no reliable keyboard control. By providing buttons that work in HTML and control the video via an API you can make it accessible to all.

Aiming for excellence.

This is the new Yahoo currency converter. It is an amazing piece of web development. It works for all users (including screen reader users) and makes it easy to convert currencies.

Here we explained in detail how it works and the approach we took in developing it.

Removing browsers

The biggest step to professional development and keeping our sanity is to get the random element of browsers out of the equation. You cannot support all the browsers in the world and neither should you.

The graded browser support is a framework to define which browsers you test for and get the full experience. Unknown browsers only get what works in them – no JavaScript and even more obscure browsers get no CSS either.

Making browsers behave.

Libraries have one job: make browsers work. Support is the most random thing in our world as web developers therefore it makes a lot of sense to put all the dirty hacking and fixing of wrong browser behaviour into libraries. YUI is what Yahoo built and uses exactly for that purpose.

First issue is that every browser has an internal style sheet that renders HTML. All of them are different which makes it impossible to develop a reliable look and feel across browsers. YUI Reset works around that.

The same applies to typography. By using the YUI fonts CSS you reset the browser typography to allow you to define pixel sizes as percentages, thus having control and allowing users to resize the fonts.

The CSS grids allow you to create multi column layouts that work across all the A-level browsers easily and reliably. Source order independence comes free, too.

If you are lazy, you can also use the grids builder, define your layout, hit the show code button and get a copy + paste HTML document. The CSS will come from our CDN, which means it gets delivered to your customers from a computer near them geographically.

Doing one job at a time.

YUI does what we as developers would love to be able to do: concentrating on one task at a time. Other than “catch-all” libraries, YUI is cut up into several components, each doing one thing. You can mix and match them to your needs.

DOM access.

One of these components is YAHOO.util.Dom which gives you access to everything that happens in the DOM and convenience methods around the more annoying things the W3C DOM API has.

Using this I can write a script that shows the perfect YUI grid for every size of browser.

Predicting issues and fixing them.

One thing you should do as a developer is being paranoid about things breaking. You should be able to see what can go wrong and set traps for it not to happen.

position:fixed is sexy!

Positioning elements fixed can be very cool. Say for example you have a long document but you want to show the navigation next to regardless of how far down the page you scrolled. Another cool use would be a comments field that allows you to copy and paste quotes from the document.

Positioning the navigation as fixed makes it always visible on the page.

However if the browser window is too small there is no way to reach the elements below.

This small script fixes this problem. Using getRegion I can get the size of any element on the page and getViewportHeight() gives me the available space. If there is more space than needed, fixed can be applied.

Once fixed, let’s re-use.

Using the YUI components we build all kind of widgets based on the design patterns.

Using these free widgets you can re-build yahoo mail yourself.

Re-use means the ability to style differently.

All the widgets are style-able using CSS. You don’t need to know JavaScript or change their code to make them look completely different.

Document your work.

The YUI comes with extensive documentation, both created from comments in the code (JavaDoc style) and step-by-step tutorials. The system that generates the docs from the source code is also available as open source.

Learn by example.

YUI comes with over 300 copy and paste examples of how to use the different components and widgets. As this is how most developers work, we realized that this is a very important part of our success.

Allow for extension.

YUI uses custom events for all of this. This allows you to completely separate your own code from the library. Instead of having to call library methods or call your functions from the library all you need to do is to fire or subscribe to events.

Know what is happening.

Not every browser comes with a great debugging suite like FireBug or Opera’s Dragonfly. This is why Yahoo comes with a logging control.

The logger allows you to debug in any browser that the YUI works in. In addition to this all the YUI widgets and components are shipped as debug versions which report everything they do to the logger. This gives you full control over what is happening and when.

Monitor performance.

The YUI profiler allows you to monitor JavaScript performance – even of non-YUI scripts.

Test before you write.

The same applies to the YUI Test suite. Using this you can apply test-driven development methodologies to JavaScript development.

YUI 3

YUI3 is the new version of YUI, there are many speed and size improvements and we changed the way YUI works significantly to make it more secure, performant and allows you to write much less code to achieve your goal.

Performance

JavaScript performance is one thing, but in order to deliver really successful web sites there are many tricks to apply to create happy end users. The exceptional performance section of the Yahoo Developer Network has them all listed.

YSlow – a Firefox extension allows you to test any web site against these tips and rules and you get immediate, relevant information how to improve the performance of your site.

Disclaimer: Dearie me, some of this is very subjective and may completely disagree with what worked for you. This is great and please leave a comment about what worked and what tips you can give rather than shooting one of the points here down in flames. I simply listed what I was looking for and what worked well for me in the past.

We just came back from the University hack day in Sunderland, England where students pitched hacks they built in a few weeks to judges that were meant as mock clients. As students asked us for feedback on what went well in the presentations and what didn’t here are some tips and tricks.

Pitches are not sex – you don’t need foreplay

The first mistake almost every group made was to introduce who they are and what they used to make the hack. This was partly a requirement of the assessment but it is also a sure-fire way to bore judges or VCs. There are two ways you can go:

• Show your hack and what it does and then go into the details or
• Explain the one problem that your hack solves and show the hack immediately afterwards as the solution.

Either approach has to answer some questions right off the bat:

• What does the hack do?
• Why should I use it?
• Who is it for?
• What does it do better/different than other solutions?

On being a team

The hack teams were 6-7 people each. Introducing each and every one of them costs a lot of precious time that you cannot use to make the audience interested in your product. Introduce only the needed people – those who will give the pitch and tell after the presentation who else did what in case there are specialist questions that need answering.

Anybody who is not part of the immediate pitch should not be standing around – all they do is distract from the presentation. Absolute suicide is to have people standing on the side scratching various body parts or looking at the ceiling or out of the window. If you pitch as a team, everybody should be awake and damn excited about the product – else you’re doing a better job sitting on the bench.

Your main spokesperson should be the most excited about the product. There were a few presentation wheres the first pitcher was amazing and had us going and when handing over to the tech guy to explain the product snoozing kicked in. If you hand over from presenter to presenter keep the energy flowing, otherwise don’t hand over.

If you have different experts delivering different parts of the pitch have them introduce each other and have their expertise be a natural part of the flow of the presentation. Some teams did a great job at that, with simple sentences like “in the future this will be extended to become important for more audiences and my colleague XY will show you what we have planned on the business side of things.”

On running your presentation

You are the presenter which means that you define the pace of the presentation and which slides are shown. You cannot have somebody else as your slide-jockey – it is terribly unprofessional to have to tell somebody to change the slide or even worse go back some slides. Presenter remotes are not expensive and most places will have some for installed equipment so use these instead. Your focus as the presenter is on the audience or jury and eye-contact is terribly important.

This applies to longer presentations, too. You can find out a lot from the audience reactions. When I present to a big crowd, one trick is to pick out a new single person in the audience I talk directly to every few slides. This is especially good to do if you pick people that seem to drift away and ask yourself what is the “what is in it for me” for that person.

Slides are an aid – not your pitch

One of the rookie mistakes is to have slides that tell and spell out everything you want to say. Less is more – much more. One word could be enough if it is backed up by your presentation. You can and should have a handout that explains details but this should not be your slide deck. Screenshots are good in case the wireless forsakes you – which it always does. Random clipart is bad as the 80ies are definitely over. Humour works – I loved for example typical English self-deprecation when one of the presentations introduced students as a target audience with a student wearing a traffic-cone hat as the example photo.

See your slides as the table of contents of your presentation – not the transcript and definitely not a different story. When your talk deviates from what is written on the wall you’ve lost us.

Bullet points are effective but also have become almost a cliche for presentations. If you feel comfortable with them, by all means use them but never have more than 3-5 on a slide with one short sentence for each.

You learn presentation writing by looking at successful presentation decks. A great resource is SlideShare where people upload their decks and the comments and views show you which ones are successful. My own slides there are all licensed with Creative Commons, which means that I am happy for you to re-use them.

Basic, really very basic typography

This applies to both the slides and the product itself. Legibility and professional type layout is very important. This is not because we are anal about this (and believe me there are a lot of people on the web that are) but there is a subconscious unease when we read things as humans and get lost because there is something not right with it.

Comic Sans Serif was lately added to the Geneva convention as a forbidden weapon when dealing with audiences that are above 3 years of age or don’t suffer from learning disabilities (this is not an evil jib – Comic Sans really proved to be very effective for these groups). Other than that pick a friendly, easy to read font that shows you mean business.

Bullet points should never be center aligned on the screen, unless they are a centered block.

Use a large enough font size and good contrast of background and foreground to keep your slides and products readable even on a terrible projector. Don’t rely on colours to be shown the way you expect them to be.

On web applications, nothing spells “we are unprofessional” more than not defining a font for your text. Out of the box browsers render in Times New Roman, so you just look sloppy if you don’t change that.

If you have no clue about HTML and CSS and you don’t want to bother with it but show something that is readable and works across all browsers, use the YUI grids in your document:

<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"
\"http://www.w3.org/TR/html4/strict.dtd\">
<html>
<head>
<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">
<title>My awesome App</title>
<link rel=\"stylesheet\" href=\"http://yui.yahooapis.com/2.7.0/build/reset-fonts-grids/reset-fonts-grids.css\" type=\"text/css\">
<link rel=\"stylesheet\" href=\"http://yui.yahooapis.com/2.7.0/build/base/base.css\" type=\"text/css\">
</head>
<body>
<div id=\"doc\" class=\"yui-t7\">
<div id=\"hd\" role=\"banner\"><h1>My awesome App</h1></div>
<div id=\"bd\" role=\"main\">
<p>I rock! I really do</p>
</div>
<div id=\"ft\" role=\"contentinfo\"><p>© by me, thievses!</p></div>
</div>
</body>
</html>

This adds a very basic level of typography for free and with the CSS hosted (and, if needed, fixed) by Yahoo for you.

Explain the unique – not the very obvious

What you want to achieve with a pitch is to get us excited and interested about what you did. The only real way to do that is to tell us what your system does differently than others – “what is it that makes it unique?” is the question you need to answer.

Get the one thing that makes your product great and shine the world’s biggest light on it.

Do not tell us that you have a delete, update and edit button. Do under no circumstances show us what happens when you click the delete button and – oh wonder of wonders – it deletes something. Then please do not continue to tell and show us the other – as predictable – functionality. Do tell us when one of these functionalities deviate from the normal patterns and do a better job though.

Do not tell us what colours you used in the background, we can see that and the colour is a means to an end, not the main reason to build the hack. Time is precious, do not waste it on things that we can find out for ourselves.

Cover the big concerns

Two things drive people nuts on the web: lacking security and hard to use products. If you ask for data show that you protect that data (some teams did a great job doing that, thanks). If you claim your interface is easy to use, don’t get lost trying to show it and under no circumstance tell other people who show the product for you what to do. “No, click the other button, no the other above this one” does not spell “millions of users will have a great time using this”.

People get annoyed very quickly if things take too long on the web. We use computers and online systems to make our lives easier, not to wait for your system or go through a five step process that could be one. Some teams did a great job with this. Sentences like “you don’t need to sign up, only when you want extra functionality explained here” are a real winner!

Tell the human story

What you build is there for humans. It is great if it makes their lives easier, it is good when it allows them to learn something and it is even OK when it just amuses them for a short while. Don’t get stuck with the technology but find the human aspect of your product instead.

Tell the story of the mother who hasn’t got enough time to juggle the day to day caring for her kids and the hard to use school enrollment and booking system. Tell the story that you got lost and tried hard to find the nearest bus stop and would have loved to get your mobile out and find it. Tell the story that you were not able to enjoy a party as you had no clue when the last train ran so you couldn’t relax as you didn’t want to get marooned there.

Computers are bastards

Things will go wrong in your presentation and you should swiftly deal with that and move on. Most presenters did that. Immediately say what happens normally and move on to the next integral part that works. Even better is when your product shows a great, well worded and easy to understand error message. Failure is as normal as success in software – both cases need a good user interface and not leave the user puzzled what is going on.

Do not try to gloss over

If you get caught out not having thought of something – own up and thank people for the great suggestions. Do not try to skirt around the issue and say that this is in there but you can’t show it now or something like that. Do not make something look as if it is more than it is – with web products it is far too easy to catch you out. Explain why things got omitted and there is no problem with that.

Don’t pad, build one thing well and sell this one

One thing that goes down terribly bad is adding gadgets gizmos and features to make a product look cooler. If a map display does not really aid the main task you try to make people achieve – don’t add it. News show that the site is up to date but can also distract from the real reason the site is there. Photos are fun but are they really needed for a time table application? Don’t think about what can be added but what can be removed. If you can’t remove any more and still make it easy to do what people come for to do you have a winner.

In summary

These are the main problems we found. Overall we had a great time and we were very impressed with both the presentations and the products. I remembered my own school time and I know how scared the presenters must have been. In that regard I have to say great job, guys.

I just came back from giving my first talk in Taiwan and I have to say it seemed to have worked out well. The room was packed and people asked very good questions afterwards.

• Download the slides The road to professional web development – PDF 11MB

In the slides I covered the history of web development, what we did wrong and what we should avoid in the future. I also covered the YUI and how it embodies some of the priniciples great web development is based on.

Update: Liang-Bin Hsueh posted an audio recording of the talk missing only the first five minutes.

Last September I was very happy to be able to pull off Scripting Enabled, an accessibility hacking event in London, England. Over two days the speakers, around 150 attendees and 40 hackers educated and learnt about accessibility barriers on the web and – in the case of the hackers – removed some of them.

The event was only possible by partnering with the right people, in this case the Metropolitan University in London, BBC backstage, the Opera Developer Network, JustGiving.com, Channel4 and last but so not the least the Yahoo Developer Network.

The presentation slides of the conference have been available and on SlideShare for quite a while now, and I am proud to announce that the Yahoo Developer Network now hosts all the videos of the talks. Opera provided the full transcriptions of the videos and I will now start publishing them one by one on Scripting Enabled.

The first video is Denise Stephens on Multiple Sclerosis and inclusive Design. Denise talks about the he effects of MS and what it means for web design. She also explains her own project, Enabled By Design which tries to bridge the gap between the design and accessibility world much like Scripting Enabled tries to bridge the gap between the developer and the accessibility world.