During some research for a new product I just got a cool mashup site sent to me by a colleague. Random Day Out allows you to define a starting location and will add random locations around the area that can be visited in a day.

You get a map, photos, directions to and from each location and a weather forecast. The system is a bit rough around the edges now, but there is a lot of potential in this.

After spending about three weeks finishing a chapter of the upcoming book introducing JavaScript libraries to non-developers I was quite amazed how tough it is at times to use different libraries.

It was frustrating putting together a set of example scripts for several effects for the oddest reasons, which is why I am now publishing my wishlist for any JavaScript library developers or maintainers. Before you start a new library or expect people to be able to use yours immediately you might want to give these points some thought. For library users this list might be a good “heads up� to see how much work has to go into using a library or how to pick the right library for the job at hand.

Here’s what drove me nuts:

• Lack of offline documentation. I am writing a lot of code on public transport or in hotel rooms where they consider it still an option to charge me for every 10 minutes online. It is not hard to create a PDF or offer a ZIP of the library documentation even if it is Wiki based.
• Lack of step by step instructions and examples for effects and elements of the library. Most of the time you either get no examples at all or a single example that shows all the options you have in one script (or a very complex form to play with all of them – which is only marginally better).
• Lack of unobtrusive examples of code which are those that fall back to working and functioning HTML or HTML+server side script solutions. In the market you will have to develop applications in accordance with accessibility and SEO requirements and both of these require that the page does not rely on JavaScript. It is very easy to create fancy examples that work with JavaScript, but harder to enhance what is already there.
• There is no problem with trying to improve JavaScript or DOM methods in addition to just fixing bugs and browser inconsistencies. However there is a problem if your extensions break conventions like the event model. I have encountered a library that had addEvent() and removeEvent() methods, but no way to stop the default behaviour of the element. This is an oversight that shows me that this library was never meant to be used unobtrusively or to enhance a server side driven application.
• Lack of information about browser support and – even more importantly – fixes and updates for new browsers that might come along. This allows your users to update their library includes or subscribe to feeds that tell them about updates and fixes. As a lot of libraries advertise themselves as a helper to make sure you don’t need to know JavaScript this is the least you should do to gain the trust of users. It is easy to claim everything works, but when there are browser specific bugs you cannot expect library users to fix them inside your library.
• Inconsistency in naming of methods and properties. There is a lot of good documentation on the W3C sites about what an event is, and if you call it action I personally get very confused. If you don’t know JavaScript or the W3C specs that is less of an issue but personally I consider libraries are step towards improving JavaScript and the DOM and not a replacement of them.
• Trying to replace CSS with library methods. There is a reason why CSS is used for look and feel: CSS parsers are very fast and it is great for maintenance to centralise all look and feel in a spot using one technology. CSS is that technology as it was invented for it. Instead of battling CSS, scripting should piggyback on the CSS parser whenever possible (by adding CSS class names to parent elements) instead of changing a lot of style properties directly. CSS has a lot less options to access content and elements than the DOM has and we can use JavaScript to give CSS developers a helping hand to reach these. There is a reason why there are so many “CSS onlyâ€? solutions out there – people got sick of scanning JavaScripts to find the place to change a look and feel parameter.
• Don’t play the “mine is smaller than yoursâ€? card. It gives the wrong impression to new developers as they might be tempted to think that your short wrapper methods are all that has to get executed. We all know that they have to be converted to native JavaScript and DOM methods before execution.

I was lucky enough to get some good JavaScript trainings in the last months, one of which being Douglas Crockford explaining the DOM as an inconvenient API to work with.

While his slides have a splendid “Silent Movie” style to it (white text on black background), they tend to be a bit overwhelming when you don’t get his explanations alongside them. Well, <farnsworth>Good News, everyone!</farnsworth>: his sessions have now been made available as small half hour videos on the web.

• Theory of the DOM Part 1 (31 minutes)
• Theory of the DOM Part 2 (21 minutes)
• Theory of the DOM Part 3 (26 minutes)

Personally I learnt more in Douglas’ training sessions so far than in about 5 years of reading books and web content on the subject. This is really good material if you want to understand why working with the DOM can sometimes be a very tough job.

With the copious amount of free alcohol still in my body and this being somewhat of a celebration (the 350th post – yes, it is rather random, sue me), let me allow myself to talk of a night out in the West End (10 minutes from the office) with Opera playing host to bloggers and web developers showing off their new products and ideas.

Opera invited me to the backstage thing via onlinetools.org (of all places) and asked me to bring workmates along as they are interested in sharing their ideas and show what they are doing.

The crowd was the typical London mix and some unexpected faces: Yahoo peeps, BBC peeps, Clearleft from Brighton (Andy Budd, Richard Rutter, Jeremy Keith with his lovely wife), local bloggers and web developers and some less obvious people like Ian Lloyd and James Edwards.

Opera provided the good ingredients of any Webdev meeting:

• Schwag in form of free T-Shirts, squishy balls, badges (stating “I love Opera” and thereby being great to sell in Covent Garden at the end of a performance if you are ever really skint) and more things I cannot remember right now as I left the bag in the office when I picked up my laptop.
• Drinks and fingerfood of the free variety. Originally every visitor had 2 drink vouchers, but the later the evening got the more of those free papers appeared miraculously (I just found two in my pocket).

The presentations had all good information, but you could see that Opera build browsers and don’t sell other products for a living. A highlight was Jeremy Keith talking about the web and HTML as a brilliant idea without his presentation or notes as his laptop died on him right at the wrong moment. His talk was a proof that if you take the instructions away from an Irishman, he’ll turn into an instant poet. It was a joy to see.

Technically there were some interesting bits to see:

• As hinted on barcamp, Opera is working on a 3D SVG engine inside the browser, which would allow for OpenGL style apps. The 3D “Snake” adaptation they showed was a bit on the flickery and slow side, but that may be due to the presentation machine or the lack of buffering in the code.
• Opera finally has some very impressive debugging tools that allow you to see the code as it is rendered, change the DOM, show the dimensions of an object and even use a picker to choose a colour from the page to re-use in CSS. Finally we’ll be able to fix the odd rendering bugs Opera shows from time to time easily and without guesswork.
• One really impressive bit was to see a “labs” version of Opera that did not only do the dynamic resizing of the whole document to browser window size, but also allows you to zoom in on certain elements, effectively turning the browser into a screen magnifier.

More talks were about the History of Opera, how good it is on mobile phones, what might be in store for the mobile web and that widgets are a revolutionary great idea. Opera has been pushing their widgets into interesting environments (the Assembly demoscene event in Finland being one), but personally I used them to play some games but I fail to see the point. I don’t use the OSX Dashboard widgets, the Firefox, the Google or the Yahoo ones either. I don’t know the numbers of how many people use them but I get the impression that this novelty can wear off quickly.

In the following Q&A session I got to finally get an answer why Opera for years pretended to be MSIE - reason being that “servers” like IIS4 would not give them any HTML results if they hadn’t some recognizable ident in the navigator string (Mozilla or Explorer).

All in all I’d say it was a good meeting and made me aware of some of the things Opera is doing that I didn’t know about. It also showed me that they mean it when they say they want to support web standards and it gave me some good contacts to whinge at when some of my stuff will not work in Opera.

Yesterday I went to dconstruct in Brighton (thanks to Andy Budd who got me a last minute ticket) and all in all I can say it was a massive success (missing the last tube on the way home and having someone throw up next to me on the night bus was less of a success though). If you haven’t been to Brighton, go now, it is simply a beautiful quaint little town. Anyways, about dconstruct: (more…)