113. Hiring

Paul Boag

On show 113: Christian Heilmann on common Javascript mistakes. Marcus talks about hiring new staff and Paul shares his journey into screencasting.

Download this show.

Launch our podcast player

News and events | Hiring new staff | Christian Heilmann on common Javascript mistakes | Listener emails

A quick request. We are really in need of some more transcribers to help with the interviews we do every week. The team we have are doing an amazing job but it would be great to spread the load.

If you feel you could help once in a while please drop me an email and I will add you to the list.

News and events

Highly extensible CSS

A while back Cameron Moll released a tantalising screencast of a seminar he was running on Highly extensible CSS. Website today need to be ultra-flexible, dealing with changing content, multiple devices, and user customisation. Cameron’s presentation aimed to teach designers and developers how to build interfaces capable of adapting to the unforeseen.

Unfortunately, I didn’t get the opportunity to attend. I was therefore excited to discover that Cameron is about to cover the same subject in a series of four posts on his website, all for free!

So far he has only posted the introduction. However I am really looking forward to the whole series. For now just check out the screencast and see if it excites you as much as it did me…

Video tools

Talking of screen casts I have actually been working on several myself at the moment. We are in the process of redeveloping the Headscape website and have decided to include a couple of demonstrations and presentations.

This means I have been in research mode and I thought I would share what I have found. Firstly, I have discovered a great screencasting tool called Screen Flow. This Leopard only software stands head and shoulders above anything else I have tried on either Windows or the Mac. It is amazingly easy to record and edit your screencast and has some great built in effects. My favourite feature is that it will capture from both a web cam and the screen at the same time. This allows you to cut between video and the screen or even overlay a video feed on top of the cast.

Once I had recorded my video I started to look for somewhere to host it. Although I would be foolish not to put it on Youtube where it will get the most exposure, I didn’t want to use Youtube when embedding on my site. The quality on YouTube is poor and you are limited over length and size. With this in mind I looked at a number of competitors. The winner for me turned out to be Vimeo. The quality is superb, they are much more flexible over length and time, but most of all they provide links to the original file and allow you to customise the interface.

So, if you are looking to create a screencast I highly recommend Screen Flow and Vimeo. Also, if you are looking for tips on how to make an engaging video then check out Ryan Caron’s tips over at Carsonified.

Microformat boost

The last thing I want to mention in this week’s news segment is the growing interest we are seeing in Microformats recently.

For a start Firefox 3 is going to have built in support for Microformats, which will be hugely significant in itself. However the guys over at Yahoo! are doing some interesting stuff in the area too. Yahoo! Micro Search is a new way of viewing search results that include all kinds of metadata including microformats. According to David Peterson at Sitepoint this could allow Yahoo to really challenge Google.

I am not sure whether that is true or not, but I do know it is a great time to start using Microformats. If you want to get started then check out Microformats.org or for you more advanced users have a look at this interesting demo of compound Microformats.

Back to top

Feature: Hiring new staff

Marcus shares his thoughts about taking on web design staff for the first time.

Back to top

Expert interview: Christian Heilmann on common Javascript mistakes

Paul: As I said at the beginning of the show, joining me today is Christian Heilmann. Hello Christian, how are you?

Christian: Hello Paul. Why it’s quite fun cause it’s Valentines day & I’m stuck with you as a date.

Paul: Well I’m sorry that you had to ah to endure me on Valentines Day but I’m sure you’ll survive. And um yeah… so basically, the reason that we’ve got you on the show today is we want to talk a little bit, a little bit about javascript. Now we’ve talked a lot of times about javascript before and it’s not a new subject, but I kind-of um… felt it would be worth touching on the kind-of common mistakes that we’re seeing a lot in the world of javascript at the moment. I think um… you know obviously javascript is very in and there’s load of cool stuff being done with it but not always in the wisest ways. Um… and then on top of that, so there’s this kind-of group of people that are doing quite advanced stuff with javascript with maybe not considering all the ramifications of what they’re doing. And there’s another kind-of group of people which are people like myself that go ‘Ewww… look at that, that’s cool I want to start doing things like that.’ And so you know a little, a little knowledge is dangerous as they say, and you know we’ve picked up books like Jeremy Keith’s scripting book and read that and now we think that we can, we can build javascript applications and are kind-of hacking things together. So I thought lets spend a few minutes looking at those, those kinds of issues. So um um… maybe probably a good place to start off if you don’t mind Christian is what advice you’d give to somebody starting to learn javascript so that, so that they kind of avoid some of these mistakes you know from the get go. What good principals, good foundations should they be working on?

Christian: Um… the main foundation is that javascript is a language in its own rights. It’s uh uh… you can not take any other knowledge and try to apply it on to javascript and this is where the two angles actually come where people that come from a higher programming language background trying to find the same principals that apply there inside javascript

Paul: Um hum…

Christian: Or people that come from CSS design background, basically think that it’s as easy as applying a CSS selector to an element that everything will be matched magically…

Paul: Yeah…

Christian: … and not realizing that there is an impact on speed and an impact on how the browser actually finds these things and what kind of mistakes the browser does. The main thing to remember about javascript is ah… there are many different ways of javascript, there are many different environments where it’s applied. So there is lots of really clever things being done right now with javascript, even on the service side and inside frameworks and inside API’s. But there’s also, in the end you would run it in a browser sooner or later. And if that’s where you are going to work the best advice is actually to not trust javascript ever and to actually um… enhance with it but not really rely on it.

Paul: Um hum…

Christian: So if there is a window print link, then this link should be generated with javascript and not just be an ‘href’ javascript window print because if somebody doesn’t have javascript or for some reason javascript’s broke, or the engine doesn’t work in your environment then you click the button and nothing happens. And there’s nothing worse than uh promising an end user something that you don’t deliver in the end.

Paul: Yeah.

Christian: The other thing is that uh… when you start from javascript, one of the first things to remember is that you should always learn the if statements and learn that they’re your best friend. Like never do: ‘apply something’ BUT IF ‘something’ THEN ‘apply something’. So if you…

Paul: Umm…

Christian: Try to access a heading with an ID for example, and then you don’t just do: HEADING ID ‘something’ = ‘something’… cause it might not be there.

Paul: Yeah.

Christian: So basically test for it, before you apply it. When you follow this principle through with all of your programming, this kind of defensive programming, then you will (we will) definitely write good javascript in any programming language really. Over the years when you get more and more experience you just learn more and more ways how the technology that you use fails…

Paul: Mmm…

Christian: …rather than actually succeeds. So you learn how to avoid the biggest pitfalls.

Paul: I mean, you always hear this thing don’t you about um… that not all browsers support javascript or that not all users have javascript turned on. I mean how real a problem is that? Is that being overly cautious to worry too much about that kind of thing or is it a real problem? Are there actually a lot of users out there that… that don’t have javascript for one reason or another?

Christian: It’s impossible to say. Its statistics and it’s a bit like flash. When you when you look at flash statistics and you hear like a 99% have it enabled on the Adobe side, then you’re like ‘Oh yeah really.’ because these are the only stats that you find…

Paul: Um hum…

Christian: …the company that delivers that is a bit like… yeah, I think that the Microsoft help pages with have a lot of hits from people with Windows.

Paul: Yeah.

Christian: So um… it’s not really a problem I don’t see the problem at all. I see the problem of people… uh, architecting and designing applications around the premise that javascript will be there, and everything will be happy and work.

Paul: Mmm hmm…

Christian: If you write your applications like javascript does not need to be there, but is nice when it’s there and actually makes it a lot smoother, then you don’t have a problem…

Paul: Mmm…

Christian: I don’t buy this whole argument of like… oh AJAX is so cool because we don’t’ have much traffic on our servers any longer. It’s like yeah, but you never know the environment that javascript is run in. It could…

Paul: Mmm…

Christian: …my mobile phone, it could be it could be an iPhone, it could be it could be an old browser. I just bought myself this eeePC that doesn’t have much memory. It’s uh… you can never expect the end user to actually cater their hardware to your needs…

Paul: Mmm…

Christian: So it’s pretty… it’s pretty unsafe to actually rely on it. So even if the statistics are ridiculously low, it doesn’t really matter because you don’t want to deliver a bad practice and deliver a bad experience to users.

Paul: Mmm…

Christian: And then there’s, of course, the SEO problems as well. If you have a navigation that’s dependent on javascript and doesn’t show anything – or you make elements clickable that shouldn’t be clickable, then you won’t have search engine spiders following these links and your sites won’t be indexed.

Paul: Mmm…

Christian: Same with accessibility. When you make something clickable that is not clickable by default, like a ‘span’ or a ‘div’ or whatever, then you can not expect a user agent actually to allow people with assistive technology or people that use a keyboard to use the same application because browsers are just not clever enough for that.

Paul: Mmm. So what about people, um… starting out as absolute beginners – what are the most common mistakes you’re seeing them make when they start out doing javascript?

Christian: A lot is copy and pasting and hoping that nothing breaks…

Paul: (Laughs)

Christian: …and ah… also um… a lot of it is skimming tutorials. A good tutorial writer will tell you a lot in the paragraphs between the code examples.

Paul: Mmm.

Christian: And um… just going through the code examples and trying to figure out what’s going there yourself and copy and pasting it does not really make you a good developer. This information was put there for a reason and actually explains you the smaller bits that you need to know about the language. ‘Cause most of the javascript errors that actually happen in the real world is not because you did a coding mistake, but because you made an application mistake that you expected a browser to do something. Or you expected an application to give you the right information back, where as you didn’t test for it. So um… I think trusting tutorials and uh… just copy and pasting code without actually knowing what it does is a very dangerous thing.

Paul: Mmm… Would you apply that same principal to frameworks? You know and not under… if you don’t understand what a framework is doing then it is probably best to avoid it.

Christian: Well it’s a matter of what it does. I mean uh… the last few years in web development have become a lot more transparent than before and that’s… Firebug is actually to blame for that.

Paul: Mmm…

Christian: It’s great because you can look at code that is generated by javascript or a backend application and you always know, you can always analyze the whole document ñ what’s doing on there if you know your Firebug. That’s another thing that I would actually tell any developer that would start with javascript to get his head around it’s like java… uh… Firebug is a great great way to learn from other people’s mistakes and also to monitor what’s going on in your scripts all the time. When it comes to library’s, that’s a bit of a different story because um… I had a bit of foot in mouth moment there when I proclaimed in the past that most library’s are bloated and unnecessary and um… now I am part of a library…

Paul: (Laughs)

Christian: …and uh I’m also I also talked to media AJAX to a lot of library developers and I realized that all the libraries do the same thing. All of them actually make the pain and the uncertainty that is browsers out there bearable for you.

Paul: Mmm.

Christian: So um… if you don’t understand what the source code of jQuery is, or the source code of the YUI is that does not mean that you shouldn’t use it.

Paul: Okay.

Christian: Other people have had that problem before you and loads and loads of people find bugs and submit bugs and help these libraries get better. So now a days if you are a new javascript developer I would basically say that you have learn the syntax, you have to learn the standards like what does DOM scripting mean, how does event handling work – but by all means if you go into a production please please use a library.

Paul: Oh okay.

Christian: Because that one take the cruft of all the fixing and uh… hacking that you have to do to make something work away from you.

Paul: Mmm.

Christian: It’s a matter of what you do. I mean if you’re doing a high traffic Twitter clone, or whatever, that runs an error application then you might have to these fixes – but you’re not necessarily going to do that as a new beginner.

Paul: Okay yeah… that that’s a very different opinion than I’ve heard in the past and it’s quite interesting to hear the other side of the argument. It’s good. So what about… what about dangerous people like me? So you know… where I knew nothing about javascript but I decided: ‘Yeah, I really need to learn this’. So I got a couple of books, I’ve read a couple of books and I’m kind of up and running but I’m not… you know I’m not a developer. I’m not somebody that’s an expert. You know… what other kind of common screwups you’ve seen people like me make?

Christian: Um… It’s tricky to say. It’s like most of the time, what these kind of people do is also try to solve problems that other technologies have with javascript.

Paul: Mmm…

Christian: Which is sometimes cool, but sometimes it’s also thinking about there’s a reason why that doesn’t work. So um… I mean the classic is… the classic is like rounded corners and things like that. There are loads of javascript rounded corner solutions which on the outskirt look like they are really clean solutions. This is also might be to put a class on a ‘div’ and to put a bit of javascript in and then everything has rounded corners and there’s no harm done.

Paul: Mmm.

Christian: That the javascript needs to inject a lot of HTML and probably is slow doing so. It’s the other side of the story it’s uh… I think people like you, that are just enthusiastic about it and basically want do it are not necessarily savvy of the implications that it has.

Paul: Yeah.

Christian: So the uh… the information that we need there is that we need a lot more tutorials on um… how javascript impacts performance. And we are starting with that already in the development network and other people are doing that as well, but there are lots of mistakes being done as well there. The other problem that I see with people that have just started with javascript, is they apply… they find one solution, they find one library then they become the biggest fan of that library then everything else is rubbish.

Paul: (Laughs)

Christian: And uh… that is a very dangerous attitude as well because you will not be, you will in your career work for different clients that will use different libraries as well. So you shouldn’t make yourself dependent on only one but understand what the benefits of each of them are and where you should apply them.

Paul: Um huh.

Christian: And how they actually make your life easier, or how they make your life less easy, than another competing product. So the implications there is that a lot of people use these newer libraries, or newer ways of using javascript, to actually make javascript behave like their favorite language or their favorite technology. That’s why people went nuts with every javascript library came up with the CSS selectors.

Paul: Yeah.

Christian: And that’s great because now I can go fifty levels deep in my CSS selector and the javascript finds what’s in there. While this is already an indicator that your HTML is not necessarily good structure

Paul: (Laughs)

Christian: …and it also means that if you change your HTML in the future you also have to change that path, or if you don’t change that path then your javascript will break.

Paul: Yeah.

Christian: And a lot of libraries break silently as well. So instead of just getting the error in your face that you’ve basically screwed up, you will not know what’s going on and will wonder what’s going on.

Paul: Mmm.

Christian: And when that happens that’s normally when people, like you, fire up emails to the library developers and tell them that their product is rubbish.

Paul: (Laughs) Yeah… I can’t disagree with that. That’s the kind of thing that I’d do probably. Um… what about, I’ll tell you the one thing that I’ve come across is that… I’m kind of competent enough to write functions to do a lot of the things that I need to do. Nothing really complicated, I couldn’t build anything too sophisticated, but you know enough to get me by. But then as I’m kind of looking at other people and what they’re doing um… a lot of them are using object orientated type techniques in the code that they are writing. There’s me hacking away with little functions and there seems to be some transition across object orientated approach when you kinda hit a certain level… you know why, what’s the benefits of that? Why do people take that kind of approach?

Christian: (Laughs) Um… It’s been very beneficial in other languages, and other environments, especially when the environment is rather sophisticated.

Paul: Mmm.

Christian: Then ah… you seen for example action script. Action script has been as much as a hacky javascript. Yeah, look what I can do if I do it this way language and now with the Flex frameworks, and Adobe opening up more and more to the java world, um… it’s getting more and more into structured ways. And the structured ways are hard to understand for somebody who is not from that background.

Paul: Mmm.

Christian: And I can safely say that, I’m not myself. So I um… I have a lot of problems with like properly, or massive structures, and frameworks. But when you see people do proper action script, for example, or do Rhino applications for the server in javascript, or some of the things that are happening with javascript 2… that there is a reason for that and the reason for that is the scalability is just so much bigger.

Paul: Right.

Christian: It’s uh… basically you can extend an object and I can reuse a class and I don’t have to worry about that. It’s like I start building these little small components, all of them in themselves tested and unit tested, and I know they work. And then I can build a bigger application from them.

Paul: Mmm.

Christian: Basically without really needing to know to test these things ever again.

Paul: Yeah.

Christian: That’s how things like PEAR and PHP and Perl libraries work as well. It’s people extending these kind of already existing bits, and bobs, rather than starting from scratch every time.

Paul: Mmm hum.

Christian: Most of the time for the little web development things that we do like the AJAX form or the Constentina navigation that’s not necessarily needed, but when you write a library for example, and it grows, like YUI is growing or like jQuery is growing as well… then you need to adhere to these standards ’cause otherwise everyone will just submit their own code in forms that are just terrible.

Paul: Yeah.

Christian: And there’s not much magic to it. I mean I get annoyed when I see javascript guys going on stage and saying like: ‘Well guys, this is a function and when it’s an object it’s a method and…’ and why should I know this? Well you should know this because you need to communicate with other developers as well sooner or later.

Paul: Umm hmm.

Christian: And these people speak that lingo and rather than you having to explain yourself for 15 minutes you could communicate in 3 minutes.

Paul: Mmm.

Christian: And that gives you more time for lunch break.

Paul: (Laughs) …or drinking…

Christian: So the worlds of hard core programming and javascript are actually getting closer and closer and seeing some of the things that browser vendors come out with and some of the other software that builds on web technologies that is being built at the moment, I don’t think that we can actually rely on our being the cool cookie web developer anymore.

Paul: Mmm.

Christian: It’s a bit like we have to have broaden our horizons the same way that backend people have to broaden their horizons when it comes to using javascript, but you can only make someone understand your problems when you understand how they tick.

Paul: Mmm.

Christian: Otherwise you start preaching to the choir.

Paul: Yeah. Okay here’s the last question to wrap up with. I’m going to open it up and let you rant uncontrollably. What are the worst mistakes that you’re seeing at the moment made with javascript, just generally.

Christian: Uh. The worst mistakes that I see are that people write little scripts for tasks over and over again.

Paul: Okay.

Christian: The same task and I see them actually tying the interface a lot to the javascript. So…

Paul: What do you mean by that?

Christian: Instead of making a javascript that actually creates the things it needs, there will be HTML that is just not necessary where the is not javascript available.

Paul: Okay yeah.

Christian: So instead of starting with the proper HTML and CSS structure, you basically have this whole gumph of HTML because there’s the javascript to clean it up anyways.

Paul: Yeah.

Christian: So um… basically the main tip is you will never ever be able to replace a proper HTML structure. It doesn’t matter where technology is going because technology will go away from that sooner or later, but at least a human could actually go there and see that there is a structure.

Paul: Mmm hum.

Christian: And that there’s a way to convert this to something better in a second step. If you’ve created a lot of spaghetti code with like HTML and javascript mixed in and lots of little scripts in there, then you will never be able to convert that to something better in the future and this is what we’ve been running in circles for years and years. We’ve never been improving things, we’ve just been fixing things and adding little bits, and bobs, to it.

Paul: (Laughs)

Christian: The other thing that I keeps seeing is well the fan boy thing, about javascript libraries and of the academic way of some people measuring javascript. You have all these like, I mean there’s people that spend like weeks finding different javascript includes and script libraries and measuring how fast they are on their computer…

Paul: (Laughs)

Christian: …generating twelve thousand objects and trying to put them on dominoes. Show me the application that needs that done, then your comparison actually makes sense.

Paul: Yeah.

Christian: It’s the same as CSS. You have like ’10 Most CSS Tricks That You Never Knew’ or ’10 Most Beautiful Naviagations’. It’s like list blog posts digging their way through the internet.

Paul: (Laughs)

Christian: And it’s the same way there right now, like I can appear immensely cleaver if I just put loads and loads of effort comparing things to each other. Instead of saying ‘this’ means use ‘that one for this one’ and ‘use that one for this one’ cause the benefits of that one library is ‘this’ and the benefits of the other library are ‘that’.

Paul: Yeah.

Christian: It normally is like, ‘Oh yeah… that library won.’ or ‘All of the others are bad’.

Paul: Yeah.

Christian: And that’s never the case.

Paul: Hmmm.

Christian: We have to get away from this putting things together randomly and making up an application, to a proper web application design and I’m going to be in New York at the end of the month, no actually beginning of next month at AJAX Worlds and my talk there will be about how to do javascript design and javascript architecture of big applications.

Paul: Mmm hmm.

Christian: That’s going to be quite interesting feedback from the audience I’m quite sure about this, but it’s a matter that we grow up, we actually have to grow up as web developers and take our stuff serious and actually make sure that we don’t build for ourselves – but we build for the guy that comes after us cause that will always happen as well.

Paul: Yeah… and that’s really good advice.

Christian: If you think like that, then you will never write bad code and sometimes people just have to suffer that themselves before they start doing it.

Paul: Mmm.

Christian: It’s always clever to think of yourself as the javascript god that can do things better anyways, but some times it’s good to leave your superhero skills in the corner and just do something that works and that’s understandable and spend some time documenting for the next guy that has to take it over from you.

Paul: And I think that applies to everybody you know people, even people doing HTML or CSS or server side stuff thinking about the next person is, yeah, hugely important.

Christian: Yeah.

Paul: Thank you so much Christian. That was very useful and I really appreciate you taking the time to come on the show on Valentine’s of all days. Good to talk to you Christian and we’ll speak soon.

Christian: See you soon. Bye.

Back to top

Listeners email:

Rolling out new features

Our first listener comment is from Alex who has come up with a clever little approach for educating existing users about new features…

I just listened to show 112, where you mentioned Christian Heilmann’s javascript walkthroughs. These walkthroughs reminded me that I wanted to do something similar for our website, except I wasn’t able to squeeze it in before the deadline.

My workplace decided on a total revamp of their website, and the final design had some substantial visual and navigational changes. Among other changes, disparate logins had been consolidated into one login button. Of course, now we had the problem of habitual users; because the website hadn’t changed for several years, how do we now try to avoid several hundred support calls asking where the logins have gone?

Well, the obvious solution is to not make such drastic changes. Going for evolution, not revolution and whatnot. Failing that, is something like Christian’s walkthrough popups. However, these would still show up for new users, for whom this information would prove totally useless.

Here’s the solution I had planned:

A couple weeks before the new site or feature launch, we use javascript to set a cookie. This accomplishes two things: 1) we target people who have javascript, so we know the popups will work for them, and 2) we’ll know they were at this page *before* we changed the design or added a feature. Now, once we launch, we check for that cookie using PHP (or other server-side scripting). Why do this on the server side? Well, it lets us avoid even inserting the popup code for people who don’t have the cookie. If the cookie exists, we can then delete the cookie (so they don’t see the walkthrough again), and then insert the walkthrough divs and javascript.

Even though I didn’t get a chance to implement it, maybe this will help other people prepare for site overhauls.

What a great idea Alex. Existing users rarely like sudden changes to the sites they use regularly and often need a lot of help making the transition. This is an excellent way of doing that without confusing new users with unnecessary information.

Content management and CSS

Our second listener contribution is a question from Adrian…

Thank you very much for the show – it has been so helpful!

I have been given the job of creating an Intranet site for a small business. After listening to your shows I would love to create this website using webstandards and have been learning CSS. As well as this it is important that the users of the site can modify the content via a CMS.

So my questions are; can both of these things be satisfied? Also is it possible to design the website using webstandards and then “plug” a CMS into the already created website?

It is definitely possible for content providers to update content built using CSS. In fact it is easier, and allows the designer to maintain more control over the design. Traditionally content providers had to make all kinds of design decisions when adding content. If they needed to add a heading they had to decide what that heading looked like. If they wanted to make a piece of content stand out, they would pick a colour and font size to make that happen.

However, when a site has been built with standards the content provider doesn’t need to worry about what content will look like. They simply say this is a heading by defining it as an H1 and the CSS will decide how to style this. Equally to make something stand out they mark it as strong and the style sheet does the rest. Simple.

The only problem is that some content management systems do not have WYSIWYG editors capable of supporting this approach. They are still focused on giving the content provider design control. Fortunately there are editors out there that do think in this way. A good example is xstandard although there are others. These can just be dropped into your CMS.

Finally, it is certainly possible to plug standards based code into a CMS. Infact, it is actually easier because the style and content have been separated. A content management system is (as it name suggests) primarily concerned with content. It doesn’t care about how that content is styled. Nothing makes integration easier than nice clean meaningful markup, unencumbered by formatting.