As I am working on the questions for the written part of the 'fronteers certification', I had (and still have) a lot of difficulty in deciding the level of questions that would be appropriate. To easy is not good, but to hard would also be bad. So how does one figure out the correct level is on questions. One thing is certain, not by himself that is.

That is why we had a test exam a couple of weeks ago, we learned a lot from that. As that how you ask a question is as important as the question itself. If you have a question that can be interpreted a little bit different, people will. Test subject were every bit like clients in that respect, I can tell you that much. Thank god that we have one teacher in our midst, he will help a lot in that respect...

So for your amusement, I will present a couple of questions to you, some that made it to the exam, some that didn't. If you want to take those as a quick test I would recommend that you would take them without google assistance, as that would be the case in the real world...

CSS 2.1

1. Welke kleur wordt de paragraaf (p) met deze CSS.

   What color does the paragraph (p) become with this CSS.

   p { color : red; }
   body p { color: green; }
   .foo p { color: black; }

   red green black

2. Welk element wordt rood, met deze HTML,

   Which element(s) becomes red with this HTML,

   p ~ div + h2[title] { color: red; }

   En deze html

   <p>paragraaf</p>
   <div>division</div>
   <h2 id="a">heading A</h2>
   <div>
   	<h2 id="b">heading B</h2>
   </div>
   <h2 id="c" title="title">header C</h2>

   heading A heading C heading B

3. Hoe breed is deze div in totaal, met deze CSS?

   How wide is this div, with this CSS?

   div { width : 100px; padding: 10px; border: 1px; }

   100px 111px 122px

XHTML 1.0 strict

1. Welke tag geeft een geordende lijst?

   Which tag creates an ordered list?

   <ul> <ol>

2. Is de onderstaande code valide XHTML 1.0 strict ?

   Is this code valid XHTML 1.0 strict?

   <img src="foo.gif" title="title / description" >

   ja nee

3. Waar staat de dt tag voor?

   Where does the dt tag stand for?

   document type definition term

HTML 4.0 strict

1. Is de body tag verplicht?

   Is the body tag required ?

   ja nee

2. Is de afsluitende /p tag verplicht?

   Is the closing /p tag required ?

   ja nee

3. Is deze html valide HTML 4.0 strict?

   Is this HTML valid HTML 4.0 strict?

   <TR width=100 >

   ja nee

All of these questions are right out of the specifications of the W3C as those are easily testable and not open to discussion.

What do you think, are these questions too easy, too hard or something else. Please let me know, I will try and put a full exam online in working order before Fronteers 2008 but as things are going now, I probably won't have the time. This because I will leave for london and @media ajax only two days after fronteers and still have some clients to keep happy...

The past few weeks I had a lot of fun playing with jQuery UI for a client. They wanted to replace some elements in an application, sliders and such, with a more accessible solution. For that I turned to jQuery UI, as I had previously introduced jQuery as the standard javascript library for them.

As I started to play with the code I couldn't helped but be impressed by the great work that has been done by the UI team on this project. But as I looked at it more closely I found some things that could be improved.

So here are some of my grieves with it and a possible way to solve them. I am going to concentrate on the slider ( docs / demo ), as it was with that widget that I started to notice some things missing.

The way you use it is in a true jquery fashion nice and unobtrusive, once you have included the correct javascript files (for that see the documentation), you just do:

$("#slider").slider();

And shazaam, #slider has turned into a slider, nice... But, what happens to the input that people provide...

This solution is nothing without javascript, so in my book it is a nono. I can not imagine that I could use this widget on my sony erikkson k800 phone. So accessible it is not, at least not in the way the demo shows us. And as most people will just copy and paste from demo's, most sliders will not be accessible.

So what you say, a slider can never be accessible, rubbish I say. Stick with me and I will show you a very simple way to make this accessible. And in a few day I will put up some example sliders to accompany the code as suggested by Danny Lagrouw.

Improvement

First we will look at what a slider does, it provides a user the possibility to enter data. Whoa, a whole new concept... eh no.

Lets start with an simple < input type="text" /> that gives people a good opportunity to enter a value, no? But what about stepping you say, that we can solve with a few < input type="radio" />. All we have to do is write javascript that sends the value of the slider to the input and when the form is submitted, the server can sort it out.

If a user has no javascript a viable alternative is provided. So not only advantages on the user level, but did you notice that we just solved the data to server problem, in a way that requires us to write zero I admit it is boring but if you want your fancy interface to do something, it has to interface with the back-end as well.

So we start with the html, as that is the base for accessible solutions, we set up a free form slider. As we do this, we make sure that we create a fully functional option for everybody. That is, the purpose of the slider is to set a value.

<div class="slider free" id="slider">
  <label for="text">
    label
  </label>
  <input type="text" id="text" />
</div>

As you see a nice and clean solution where data can be entered and processed. What we miss is the fancy slider, which we will create with javascript like this:

// add a slider container div
// add a slider handle to slider container
// place a span to recieve the value
// and add a class to the container
// find and set the input to readonly
jQuery('.slider')
  .append('<div class="slideContainer"> // br
      <div class="ui-slider-handle""> // br
      </div> // br
    </div> // br
    <span class="value"></span>') //br
  .addClass('sliding') // br
  .find('input').attr("readonly","readonly");
// linebreaks (br) added for readability

There you have it, an accessible solution for a slider, simple as that.

But wait, what if I have 5 steps that I want people to choose from. That I cannot do, so your solution sucks and I still am stuck with a pure javascript solution says the sceptic (I know who you are...). Oke, the second one is a slider with steps for you.

First let us see what that is, it is simply a option you choose from a limited number of options isn't it. The html solution for this is really easy, radio buttons. So of we go with html

<div class="slider steps" id="slider2">
 <fieldset class="radios">
   <legend>legend</legend>
   <input type="radio" name="radio" value="0" id="v0" />
   <label for="v0">zero</label>
   <input type="radio" name="radio" value="1" id="v1" />
   <label for="v1">one</label>
   <input type="radio" name="radio" value="2" id="v2" />
   <label for="v2">two</label>
   <input type="radio" name="radio" value="3" id="v3" />
   <label for="v3">three</label>
   <input type="radio" name="radio" value="4" id="v4" />
   <label for="v4">four</label>
 </fieldset>
</div>

Just like that we have a viable and accessible solution in plain old semantic html, now for the javascript.

var sliderSteps = {
 radiobuttons : ((jQuery(this) //br
   .find('input[type="radio"]') //br
   .length)-1) //br
   .toFixed(0),
   init : function(targ){
     sliderSteps.createSlider(targ);
     sliderSteps.set(targ)
   },
   set : function(targ){
     var w = (100/((sliderSteps.radiobuttons*1)+1));
     jQuery(targ) //br
       .find('label, .ui-slider-handle') //br
       .width(w+'%');
     },
     createSlider : function(targ){
     jQuery(targ).slider({
       // zoveel stappen als er radio button zijn...
       steps : sliderSteps.radiobuttons,
       change:function(e,ui){
         var x = jQuery(this).slider('value');
         var a = (x/100*((jQuery(this). //br
          find('input[type="radio"]').//br
          length)-1)).toFixed(0);
         // set the value somewhere...
         jQuery(this).find('.value').text(a);
         // check the radiobutton.
         var t = jQuery(this). //br
          find('input[@type="radio"]')[a];
         jQuery(t).attr('checked','true');
       }}
     );
   }
 }
 sliderSteps.init('#slider2.steps');
// linebreaks (br) added for readability

So there you have it, a nice clean and accessible slider solution for the folks at jquery ui to include in their demos. And for everybody else to look at and maybe even use. So have fun with it and let me know if you like it.

If you see any faults in the code please let me know, but as I am on holiday now, don't except me to rush...

Here is all the demo code zip file wn.slider.zip for you to play with.

Technorati Tags:ajax, javascript, jquery, userinterfacedesign

Chris Mills of opera has just published great resource for web developers. In this he talks about best practices and tries to get people to unlearn stuff like:

In the old days, people used to do things like laying out their web sites inside giant tables, using the different table cells to position their graphics, text etc (not what tables were intended for, adds superflous markup to the page). They used to use invisible images called spacer GIFs to fine tune positioning of page elements (not what images are intended for, add superfluous markup and images to the page).

So go and check it out, it sure is a great resource and will get better.

Introduction

The past 9 months I have had the pleasure and the privilege to work on one of holland's biggest websites, ANWB.nl. I had a lot of fun and learned a lot. I also had the pleasure to work with a great team and I thank you guys, you know how you are.

As this was the biggest jobs I have ever done, I will take the time to share my experience with you.

History ( or why )

ANWB had been working with a custom built cms and it began to show the wear and tear of being used and added to in too many years so they decided to go for a complete rebuild. What it lacked was a plan during the development phase was a master plan, so all of these nice features worked against each other. The worst thing was that is was slow ( and to me, that it produced really horrible front end code ).

First we researched on what kind of cms they needed. After some time we decided on Hippo, a dutch open source cms. This had some implications: as hippo does not come with a front end right out of the box, so we had to build one ourselves. The reason for that is obvious, once you look at it. Hippo manages content and does that really well. They let others serve that content so that they can focus on their job.

They asked me to do the front end, - css, html and javascript - and to help others in that field by coaching and teaching

Techniques ( or what and how )

Cocoon

We built the front-end using apache cocoon, which turned the xml from hippo into decent (or so I think) xhtml. The XHTML is only about the structure, not about presentation or behavior. This helped us to built some really versatile and robust templates. There are only 7 templates that serve several thousand pages, so versatile they had to be. Quit a few had some overhead in them that made it even more important that they were robust.

We also used cocoon and the yui compressor to concatenate and minify the js and css files, something that greatly reduced the number of http requests. It also gave us the freedom to write well documented code and seperate the code into a large number of small files. Each of those files is for something different : we got js files for small functions with half the filesize being comments. When we serve it to the customers, they only get one file instead of 50, without any comments in it which would only increase the file size.

HTML

The html was one of the most important bits of the site, as all of the other stuff (css and js) can't work well with it. The XHTML is one of the most important parts of the front end design, as it is the base upon the other two (CSS and js) work upon. It was refined during several revisions as requirements got clearer. It is one of the >aspects of this project that I am proudest of.

It is valid xhtml 1.0 transitional and as semantically correct as possible. So : no .redborder2px classes in the css or superfluous div's (thinking of a large dutch bank...). Not everything is perfect, but most of these things come from third parties, so they are out of our control. The bad thing is that some of these (banners and iframes) multiply our loading time by an x-factor, but alas, that is the real world for you.

Everything should work in all major browsers (we did a variation of the yahoo browser support). In fact the development started on firefox and safari on a mac and IE testing started only after 4 months of building.

Now if we only could educate the editors how to write proper markup, but alas. That is one of the disadvantages of a real world job: you never know how people will use it.

CSS

The CSS is also as valid as possible, though it is not completely valid, as we used various CSS versions, as well as some IE specific stuff. The IE declarations are all nicely tucked away in its own conditional stylesheet and no more than the absolute minimum of declarations were used. quite a feat for such a large site...

Javascript

The javascript was done with jQuery but some older applications still used some prototype that we had to rewrite.

Prototype extends some of the native javascript functions in the global namespace, so this collided on some occasions. We rewrote some of the prototype code like prototype.extend to prototype.prototypeextend so it would play nice with the rest of the javascript code.

We made sure that the javascript was as unobtrusive as possible, something that worked out well in pages we had control over but not so good in the older applications... We also used event delegation which helped us to increase the performance.

Overhead

The real challenge lay in incorporating the more than 40 different applications into the new templates, css and javascript. Some of those were written in the middle ages and the average origin of these was about 1873. What they produced in html is not quite what we wanted and we had a lot of fun tweaking stuff until everything was working.

We also learned a lot from this, stuff like rewriting parts of prototype and jquery for instanceneeds rephrasing, not clear. We also had to check the javascript that wrote parts of the page and correct the invalid html with even more javascript. Some had js to close unclosed div's which provided a challenge...

As an idealist I wanted to rewrite those so called applications, but as a pragmatist I didn't (at some urging from the project manager). The cost would have outweighted the benefits but hopefully some will be rewritten in a proper fashion soon.

Conclusion

At the end of the project we can look at some nice results, the total amount of http requests has gone dramatically down. We started with as much as 15 external css files and 10 external js files, which we reduced to one. We also managed to get rid of all of the inline styles and scripts as well as tables for layout. With that we reduced to average filesize of a html page from 170kb to 25kb, something that speeds things up for our customers.

As we took all of the presentation and behavior out of the structure, the resulting pages are more flexible : so maintenance should benefit from this.

Thanks ( or whom )

During this project I had the pleasure to work with some of the best in their fields. I also could use the work of the builders of jQuery and the knowledge of yahoo!, without which I would have been lost. The project was lead by some great project and program managers, without whom our work would not have been as stress free.With javascript issues I could turn to the expertise of a co-worker and for cross browser stuff I had a master to help me.

Last but not least thanks to Gilles Ruppert for editing my post.

Technorati Tags:ajax, css, Firefox, html, Internet Explorer, javascript, jquery, Opera, Safari, w3c, web, hippo

the site was complaining about the cold, it being april but still freezing at night here in the netherlands, I decided to clothe it again. So naked day is over...

What happened to the design?

To know more about why styles are disabled on this website visit theAnnual CSS Naked Day website for more information.

Deploying and Updating AIR Applications (Serge Jespers)

Packaging, deploying and updating your application are probably the most important basics you'll need to know about. Serge will show you how to use Flex Builder 3 and the command line tools to sign and package your application, how to use the install badge, create custom install badges and how to keep your application up to date.

serge demostrates the world smallest video player, it plays hd in 16 by 16 pixels.

He then goes on with the presentation.

1. step 1, get a certificate

   From thawte.com for 299 $ for one year with firefox. This to get a green (thrustworthy) icon in your installer.

2. step 2 deploying your app

   using the standard install badge is one way.

   Another way is to use the beta install badge, looks nicer and has extra features. You can get it here

   The third way is to use a custom install badge, something you can build your self, so looks and functionality is up to you.

3. step 3 Update your application

   He gives us 5 steps to do this, these I will hope to link to later, he will post them on his site. He explains how this is easy with flex in contrast with flash. As it already has a lot of stuff in it, to make development easier.

Adobe AIR API Overview (Daniel Dura)

Receive an overview of the new APIs that Adobe makes available to applications. Both and JavaScript examples will be shown.

Daniel Dura gives an overview of the most used api's, like window a subject you could spend a full day on covering it. He just covers the basics, normal window, lightweight window and utility window. Startmove() function is one of the reasons that I see myself writing air applications, it gives you so much extra functions...

After the html api, he goes to the File I/O api. This is the one that gives air so much extra over web applications. With this you have the possibility to read or write stuff to you computer. Make sure to close your filestream though, otherwise you will lock your computer..

Drag and drop / clipboard is another powerfull api to enhance the users experience. It enables the user to interact with your application in a normal manner, something that cost so much more trouble with just javascript.

For more info look at his site, which has the slides.

Data Intensive Enterprise AIR Applications (Enrique Duvos)

The need to optimize data handling and transfers in RIAs has become increasingly important in Enterprise applications. During this session Enrique will take a look at how the combination of Adobe AIR's offline local caches via SQLite, and its native connectivity to Adobe Livecycle Data Services data management services, gives developers a powerful framework to deliver data intensive RIAs outside the browser.

The first one which tell anything about preformance. Heard nothing about air's memory leak though. Explains the way that you can build flex and air apps with the same code base that talk to a java backend, very nice...

He shows a way to synchronize the data between client and server, in a nice way. You can check the connection and see if it's up or down, furthermore it can see if data is the same on or offline. Not sure if you have to use adobe's lifecycle though...

Maybe you can read about it on his site

Introduction to SQLite in Adobe AIR (Peter Elst)

Learn all about local database support with SQLite in Adobe AIR, how the use the available API's and build a complete data driven application from scratch. This session will help you get started with several tips and tricks on how to work with data in your desktop RIA's.

This is the one I hope to learn a lot from, if only pointers to where to start. It looks really easy, minimum amounts of code to do cool stuff. Paging is build in in a nice (not new) way, almost equal to mySql. Transactions look like a nice way to do lots of stuff in a fast and secure way.

I still don't know how the html is rendered in the air client, which is webkit and how it can or will affect performance... This will not be a problem with flex, which creates flash (imho).

Drag and drop is a part of flex/air that they are proud of showing, it is super easy and being shown now for the third time. Peter is using a trial version of flex builder, apparently all the money went to our lunch. Still this is by far the most interesting presentation so far, very good. The level is right for me, a bit over my head so I learn something but not too much.

He has a site, which has the slides on it.

this is a quick write up of the first part of the onair tour, I will clean this up later...

keynote Ryan stewart

Ryan Stewart, a Platform Evangelist at Adobe, provides an introduction to Adobe AIR and how it fits into the Adobe technology platform, and the larger RIA landscape.

marketing talk, adobe rules and stuff

focuses on the cross platform strength of air
talks about 'cocomo' and 'pacifica' server side stuff. nice, but still closed source...
air wants to bring the web developers to the desktop, by bringing the good parts of the web there.

shows a air app called uvlayer. Looks nice but still too much eye candy to me.
google analytics app is cool, adds animation in a nice unobtrusive way...
uses flash with html on one screen. pdf is used well, to render a print view.
mapcache is a cool app

why ria on the desktop?
branding, extended functionality. data access. you can use the flash player to access the same information on different platforms (web mobile desktop wii).

how
using existing tools like textmate or aptana.

new
1.1 more languages
post 1.1 three platforms the same...
max 2008 dec 1-4 2008 milan italy

Building your first Adobe AIR application with Adobe Flex (Mike Chambers)

Learn how to setup your development environment and build your first AIR application using Flex 3 and Flex Builder 3.

flexbuilder based on eclipse

configuration in xml looks easy.

flex looks nasty, absolute positioning and stuff

good warning on certification, get a good one if you go commercial

Building your first AIR application with HTML and JavaScript (Kevin Hoyt)

After this session you will know how to setup the Adobe AIR SDK to allow you to develop and package AIR applications from the command line. You will also be able to leverage the Adobe AIR command line tools to enable development of HTML and JavaScript based applications. Finally, the session will demonstrate built in support for AIR development from Adobe Dreamweaver and the Eclipse based Aptana.

shows how to build air apps with textmate and terminal. explains how app development is different than web development. app development has many things in common with java development

application sandbox? javascript is more insecure on the desktop, there is where the sandbox comes in. script injection and eval should be in the non-application sandbox and the application sandbox has the more advanced air js stuff.
html rules

Leveraging HTML and JavaScript within Adobe AIR (Kevin Hoyt)

Gain a better understanding of the HTML and JavaScript environments within Adobe AIR, and explore how these technologies can be leveraged in both Flash / Flex and HTML / JavaScript-based applications. JavaScript and ActionScript script bridging will be covered, as well as how to use AIR, Flash Player and ActionScript Library APIs directly from JavaScript.

even flex developers have the java bug, putting presentation in the structure, boe..
maybe it is for demo purposes, but the stupid thing is that tons of people will copy/paste this. so that is why it is important to build your demo's as clean as possible.

Kevin's site

As I am to busy to concentrate on some real writing on stuff that I am working on, such as jQeury plugins, adobe air and stuff.

• a good float article, as it can't be explained enough
• a nice and long list on microformats, as a reference.
• jQuery plugin developement by snook, he is the man.
• jQuery plugin patterns, usefull.
• More jQuery plugins, also.
• Air for ajax developers, that is for me.
• Air by snook, a nice demo app with source code.
• Air by google, search results..
• Air in Amsterdam, I will be there, will you?

I will try to make some time to write some good stuff, as the things I am working on are quite nice (oo javascript anyone?), but first I have two real world deadlines this month. Both on the same day, so I will have to do with less sleep the coming three weeks.

On the other hand, I will be going to adobe onair in amsterdam this friday and a nice short vacation beginning of may sure looks possible. So all things considered, stuff are looking good, deadlines and all considered. After all, if I didn't like deadlines I should not be working on the web, right?

Technorati Tags:browsers, css, html, microformats, web, adobe air

in progress and this time it's live. Check every few hours to see the design form slowly...

1. step 1 setting up reset.css and looking at how to customize the php...
2. step 2 setting up css after sleeping on a design..
3. Tweaking the css for almost a day now, got it asides from some usability issues. The logo (which is the a inside the h1) is clickable, but I got a h2 with the blog name not a link. In order to solve that I gotta throw a lot around in the php. Not used to dabbling in php anymore, so step lively now...
4. Now for a break, will look at the icons and javascript after this, in no particular order... Site is now build using only two images (besides the ones in the articles), no javascript so just POSH..