As I have just upgraded my blog from wordpress to habari, I am now faced with a really nice gray skin called 'charcoal'. If you know me, you must know that this out of the box style is not my thing. So I am going for a redesign and will build a new theme as I am at it. The redesign will NOT be visible on this page, but you can follow it on habari.wnas.nl.

This is a clone of this site, as it uses the same database and stuff. In doing this I can work with real data, no lorum ipsum for me please and I won't bother you, the reader, with unnecessary breakage and stuff.

Be warned that I will not try to make the site look the same in every browser, in the end a user with ie6 or below should be able to read everything. But the really nice things will be done with css3 selectors and so on.

I short I will be pulling an andy on you. I will not be slowed down by the lowest common denominator. So for now peek behind the vail and please comment if you see anything you like...

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