122. Screencasting

Paul Boag

In this weeks show we have Ian Lloyd discussing Sitepoints HTML reference and we take a look at creating screencasts.

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Typography everywhere

This week has seen a plethora of posts about typography. There is an article about changes being made to typography in Firefox 3, a post dedicated to working with paragraphs and some future developments in CSS 3 fonts. Combined with the growing support for embeddable fonts, it would appear that web typography has a rosy future.

Although all of these posts are interesting, I feel we are not making use of the typographic tools we have already. I have learnt a huge amount by reading what people like Richard Rutter and Jon Hicks have to say on the subject. For example how many of you…

  • Ever change the default kerning
  • Really get specific in your cascade of fonts
  • Consider vertical alignment
  • Think about the relative sizing of our various typographic elements

The list could go on.

Many web designers choose to ignore web typography because it is so restricted. However, this will soon change. We need to learn to walk with the basic tools currently available before we run with what is to come.

Accessibility cheat sheet

Our next story follows on nicely from last week’s feature in which we addressed accessibility quick fixes.

Aaron Baker has written an accessibility checklist aimed at designers and developers who know little about web accessibility. The idea is that by simply referring to the list during development they will be able to avoid the major accessibility issues.

Aaron is the first to admit this isn’t an ideal solution. He also accepts the checklist fails to cover everything. However, in my opinion he has done a damn good job at making the accessibility guidelines… accessible!

What I like most is that he also provides a PDF version that prints out as a single page. Instead of having to wade through pages of W3C guidelines you can print out a single page and pin it to the wall. Ideal for those starting down the road of accessibility.

Does this mean we can ignore WCAG? Absolutely not. However, this is certainly an easier starting point for those who are intimidated by the subject of web accessibility.

Advice on wireframes

We are having an interesting discussion within Headscape at the moment. Where does the job of an information architect (IA) end and that of a designer begin? When it comes to wireframing in particular, the line is blurred. A wireframe is often produced by the IA but can strongly define the layout and design. This reduces the designer to skinning a site, which is a real waste of their skills.

I was therefore excited to read the first in what will be a series of posts on wireframing. The author identifies exactly the problem we have been struggling with and talks about page description documents. These documents differ from traditional wireframes because they do not endeavour to establish a layout. Instead this is left to the designer. A page description document focuses on identifying and prioritising content. It is then down to the designer to represent this on the site.

It is an interesting approach and one that I think has a lot of merit. However, I am equally excited to see the other posts in this series, where the author promises to show us example wireframes and provide more details on his approach.

Top five tips for new web designers

The final news story of today is an unusual choice as it comes from our own forum. Our forum is always full of great threads, but one in particular caught my eye this week because it covered the most common question I get asked; ‘what advice do you have for a new web designer?’.

It is not a long thread (yet!) and so is easy enough to follow. However, each poster has provided some excellent advice in the form of their top 5 tips.

The tips include…

  • Advice on business
  • Techniques for improving your skills
  • Areas to focus on
  • Books and sites to read
  • What to learn first
  • How to increase your profile

Without exception they are all gold dust and if you are new to design then definitely give them a read.

Equally if you have been a web designer for a few years take a moment to post your own contribution. I think you will probably learn something at the same time.

Back to top

Feature: Creating Screencasts

Video is becoming an intrinsic part of the web and not just dumb ass videos on YouTube. Video can be used to show off products and provide online presentations. But how do you create a high quality screencast on a budget? We look at this issue in this weeks feature.

Back to top

Interview: Ian Lloyd on Sitepoint HTML Reference

Paul: OK. So joining me today is Ian Lloyd. Hello Ian.

Ian: Hello Paul!

Paul: Have we had you on Boagworld before or is it just .Net?

Ian: Erm… Actually never in real life person. I did the video thing for you before, the screencast.

Paul: Yeah. That’s it. I knew there was something.

Ian: I’ve heard my dulcet tones before.

Paul: Yeah but not on a live, real, happening interview type basis.

Ian: Is this happening? What as in cool, hip and happening? Wow.

Paul: This is happening right now! So there we go. That’s exciting. So the reason I have Ian on the show today is that he had just undertaken and completed a mammoth project no less, in the form of a HTML reference guide that is now available via SitePoint. Now we’ve talked before on the show about the CSS reference guide but the HTML one is a new project that is beta at the moment. Why have you showed a beta tag on it? Come on, put your money where your mouth is. Commit to a real live version!

Ian:Well that’s not really my shout in fairness but I think the reason they do it is that with all the will of the world and all the technical editing that goes on and all the rest of it, invariably there’s going to be things that will crop up.

Paul: I was always under the impression that you were infallible Ian.

Ian:Well I would to keep that myth going but it’s obviously completely untrue. But no, I think it’s sensible. From what I can gather they did this with the CSS reference and they told me that they did get some good feedback as a result of doing this. So it gives them an opportunity to capture anything that has so far evaded various editing stages. There are little things that you can easily, easily miss. So it makes sense. Put it in front of a whole bunch of pedants and you will find that things will be revealed that you weren’t aware of.

Paul:Yes certainly. So tell us a little bit about how the project came about. How did you end up working on this from SitePoint and how you get involved?

Ian:Right… Well it’s actually quite a long story that I’ll try and shorten down. Basically I’ve got a bit of history with SitePoint. It goes back to probably 2001/2002, something like that where I was writing articles for them. I had written a few and they had been scored quite highly. At the end of 2003, I took a year out of work.

Paul: Ah I didn’t know… Yes I did know that.

Ian:While I was travelling around the world I made it my business to try and call in on people that I knew from the web. You know, you’ve part of the world so I’ll pop in and say hello. That’s what I did with the SitePoint guys. I was in Melbourne for a while so I thought I’d pop in and say hello. So we did lunch and I was having a chat with one of the guys there who was saying “Oh, have you ever thought of writing an accessibility book?” and I was like “Oh, I don’t know. I don’t know if I’ve got a book in me. It seems like a lot of work.” But not long after that I was asked if I’d like to do some tech editing and I thought “Yeah OK, I’ll do that” and I actually did it while I was still travelling around Australia in the van. So that was actually quite easy to do, wasn’t too bad at all. And then what happened is that when I got back to the UK I was asked “Do you want to write a book?” and this is the beginners book you have reviewed in the past on the show. So it’s kind of been an escalation from there really. So there was that book and I did a couple of bits and pieces for APress and then not so long ago I got the call back from SitePoint saying “Do you want to do this HTML reference?”. At the time I thought “I don’t know. I’m not sure. Does the world need another HTML reference?”. But I kind of thought that when I did the first book, and that’s done pretty well and I’ve had some really good feedback, so I though “Well, let’s think about this. Maybe it’s worth doing”. In my mind I convinced myself that this wouldn’t be a difficult thing to write…

Paul: *Laughs knowingly*

Ian:See you think you know HTML. You think you know it because you use it everyday and I though “Well how difficult can it be?” compared to say the Javascript reference they were writing. There’s a million and one ways you can approach something with Javascript where as with HTML there’s a finite number of elements or tags, whichever you prefer to use, that you can use in any given scenario so you think it’s pretty straight forward isn’t it. That’s what I thought anyway and I was also thinking in terms of browser compatibility the bigger problems come from the CSS you put over the top. That’s where you get all the quirks happening. So I thought to my mind, “Yeah this isn’t going to be too difficult a job”. But I think I underestimated it.

Paul:Is that not always the way when it comes to any kind of project like this that it always ends up being loads bigger than you thought it was going to be.

Ian:I think it actually surprised me how much more work there was involved. I don’t know if you did that little test a little while ago that was one of those things everyone was sending around, how many HTML elements can you do in 2 minutes or something. Everyone was having a go at it. You think you know quite a lot but then you realise there’s so many more you didn’t know and there was so many that I vaguely remember and but probably would never use. That was the funny thing, writing about these elements where I think “Well, that’s that one done. Never going to use and nobody’s every going to read it either but it’s got to be covered.

Paul:So with the CSS reference guide that they produced they have now turned it into a book. Are they intending to do the same with this? Is that the plan?

Ian:Absolutely. And that was the other strange thing I thought “This is kind of a strange business model. They are going to put it on-line for free but also gonna do a book. Will people actually buy a book?” But I’m sure they don’t do these things without doing the research first. I’m pretty sure they’ve got a good idea on what they’re doing with this. I never went into it thinking I’m going to make millions out of this because it’s never going to happen. Anyone who’s written a book, yourself included…

Paul:I’m still witting so I’m still in that naive state of thinking “Yeah, it’s going to sell hundreds of thousands of copies and millions of copies and I’m going to be rich”. So don’t shatter it.

Ian: Sorry Paul.

Paul: Just say how much money I’m going to make.

Ian: Oh yeah, you’re going to be rolling on a bed of money. You’re not going to know what to do with the stuff.

Paul: Excellent. Wonderful. Great. I’m looking forward to that. *laughs* So basically it’s gonna turn into a book before too long.

Ian: Ah yes.

Paul:You mention that there were some things in there that you thought “I’ve written this but I’m never going to use this and probably no one else is as well”. I noticed there were a couple of sections in there dedicated to depreciated HTML tags and stuff that people actually shouldn’t use. That’s a bit of an unusual decision isn’t it – to put in stuff people that people actually shouldn’t be using. Why take that route?

Ian:Well the thing is because it’s a reference you have to include everything. So everything that is in the W3C approved recommendation, everything in there is included. Even if it’s as much use as a chocolate teapot it has to go in there. And that includes the deprecated tags but there’s also things that are included such as blink or bgsound or marquee that were never actually defined in any standard but because they have almost universal support, not all of them have the same level of support, but basically there’s a lot of elements out there that were never defined in the standard but are well supported. So the decision is this has to go in there, we can’t deny it’s existence. It may not be something that anyone would want to use but as it’s a reference book we should include it. There were some that we didn’t include that I can’t remember off the top of my head what they would be. Things that were perhaps defined in Netscape 4 and just are not supported in anything and given that Netscape 4 is dead and gone a long time ago, there were some things that didn’t make it in. But the reason for having a second index that said “Here are some elements that you shouldn’t use or should avoid or these are deprecated ones” was really a case of saying that we’ve got this index of all these things and I don’t want anyone to think that because it’s in the index that it’s necessarily approved. So I wanted to kind of pull them out and say “It’s in the reference but actually we don’t really you to use those.”

Paul:Which are the worse culprits? Which are the ones you think that people are using a lot and they really, really shouldn’t be? Your chance now to lecture people and preach to them about their bad HTML.

Ian:Well strangely enough I don’t actually see a lot of them used now. I think probably the most common is people using the bold and italics, the and the tags, when really they should be using strong and em. Then again the b and i tags do have their place but they are usually misused. Thankfully the kind if things that I wouldn’t want people to use, you don’t tend to see much nowadays anyway like the blink, marquee or bgsound that was always a pet hate of mine. You’d visit a site and then suddenly you’d get some Indonesian Gamelan music blaring through that was set in a bgsound. I was kind of thinking it’s good that this is gone but if you go to any page on MySpace and they’re replaced it with something that has got sound in Flash. So yeah, that may have gone but they have replaced it with something equally annoying.

Paul:Now there’s a little question there. You say that bold and italic have got that place. How is it supposed to be used? Educate me as to the proper use of those two.

Ian:Well if you what you are actually marking up something that describes something typographical. So if you are putting the b tag around something because you are describing it as bold. So it’s that kind of context. I use in the examples on the reference it’s like I’m describing a sign of something like that. So there are reasons when you use it but generally speaking when people are using it is when you want emphasis or strong emphasis. In most cases what I would end up using would be strong and em because that is what I’m normally trying to do, emphasis.

Paul:What other kind of bad practice have you been seeing? What are the things, not just with specific tags but general bad practice, that are your pet peeves when it comes to HTML? What things are people doing a lot that just piss you off?

Ian:Like I said earlier, because of the kind of sites that I tend to look at I don’t actually stumble across too many coding sins because that’s kind of the circles I’m in I suppose. The funniest thing is when you see your own mark-up from years ago and I’ve just had to do this for something at work where I’ve taken on a reworking of something written 10 years ago and I’m like “Oh my God. This is awful”. It had been duplicated 5 times instead of one file with the logic inside that one file. So it was like “Hang on. I have to do this five times over?”. But it was nice to go back and see something that was old and table layout and all the rest of it and give it a good clean up in the process. So yeah, it’s funny when you look at your own mark-up and think “I’ve moved on”.

Paul:Even when you just look at what you learned from when you started doing standards to when you’re doing it now. I look back on the early standards work I did and it’s all div-tastic. There’s just divs everywhere.

Ian: Oh yeah. But there’s no meaning to the document as such.

Paul: Yeah. No meaning whatsoever. It used CSS so it must be alright *laughs* Which obviously doesn’t quite work does it in reality but there you go.

Ian:I guess the kind of thing that I really see a lot is just general sloppiness. People not closing tags when they’ve said they are using XHTML or unsymmetrical opening and closing. Those kind of things. Probably the first thing is missing alt attributes for images which is such an easy thing to put right but I see it so often. I guess probably the worse offences come from the kind of people who probably have never looked at a reference and may never look at a reference so I don’t know that this would solve the problems. And by that what I mean is people who would never actually get their hands dirty in the code. They’ll be using things like Frontpage, Word. You know – save as HTML in Word. You just want to beat them over the head with a large reference book. I don’t know if those kind of people are beyond hope. Maybe we we’ll be there at one point who knows. Maybe they are not beyond saving.

Paul: Nobody is beyond hope.

Ian:Funnily enough, I was saying about the Frontpage thing. It’s quite shocking I was looking at the program for a local college evening course and out of curiosity I flicked through to the computing section to see if they were doing any web design courses and
yay, there were. How To Build A Website and it was a seven week course, how to build a website using Frontpage. And it was like head slap, what are they doing?

Paul: Ah. That’s amazing that people are still doing that.

Ian: Shocking. So yeah. It’s not going to go away in the short term still.

Paul:When you were going through this reference, putting it together, was there a tag that you came across that you thought “Why don’t I use this more often? That’s an underused tag.” For example, I’ve just suddenly started using definition lists more.

Ian: Paul, you’ve taken the words right out of my mouth. That’s exactly what I was going to say.

Paul: There you go then.

Ian:That’s exactly one of those things that I don’t tend to use an awful lot myself but there are certainly uses for it. When we did this quiz thing that we were talking about earlier, I did with some people at first. So few of them had actually heard of definition lists. It was like “What is this markup of which you speak? What is this dl? What is this dd?” They had never heard of it and it surprises me but, I don’t know, maybe it shouldn’t be a surprise. You see list items used absolutely everywhere but it seems to be a bit of mystery to people. So that would be one that people could use more often and I’d certainly like to see people use them more often.

Paul:Umm. I’ve found it really useful. It’s surprisingly how many of the things, for example a news story where you have a title and then the description underneath the news story. There’s loads of examples like that where there are these paired matchings that suit a definition list so well. It’s a cool tag, if a HTML tag is capable of being cool which is probably doubtful.

Ian:There are some others as well which I would certainly like to see people use more often and they’re not ones that I don’t use, I use them all the time. Things like the accessibility specific type ones like for forms: label, fieldset and legend. I’d like to see them used more often. To some people this is something that they still don’t get. Of course in general, using the proper semantic markup. As you’ve already mentioned sites that are div-tastic. Stick a couple of headings in there and some unordered lists and already you’re starting to give your document more structure.

Paul:So talking about semantics and all that stuff, I noticed that you have a section dedicated to Microformats. Microformats aren’t really part of the W3C specification so why did you decide to include them?

Ian:Because it’s really cool. Yeah, it’s really cool stuff Paul. No, the reason really is because in the process of drawing up the table of contents, looking at all the elements we needed to cover, it became clear that there are certain things that HTML can’t do. Obviously this is not a revelation otherwise Microformats wouldn’t have come about anyway. But it felt right to put it in because essentially although Microformats are still developing they do go through a rigid process of being documented, discuss, ratified and all the kind of thing. So while it isn’t W3C recommendation it feels like it’s controlled. Also it doesn’t really do any harm. You can add this in over the top of HTML. You’re still using plain old HTML but adding that extra richness in without necessarily doing any harm. So it felt like something safe to put in. I guess the only problem with putting something like this in, at least for the printed version of the book, is that as they are developing it can get out of date. At least with the on-line version as things get added and they are adopted, that can easily be added in. It felt like a useful thing to do.

Paul:And it’s good to give Microformats higher profile because I think there are still a lot of people that are unaware of them. So it’s good.

Ian:I was gonna say it is by no means a complete Microformats reference. It really is still a fairly entry level introduction. I mean there are books out there specifically for Microformats. If someone really wants to learn more they’d do better to pick up a book or go to Microformats.org to learn more. Hopefully it would give some exposure to it that perhaps wouldn’t otherwise. And the other good thing about it is because the reference on SitePoint is very, very searchable hopefully by the time that Google’s indexed it you will find people that stumble across that wouldn’t have done otherwise and just from doing a search from inside the site itself. There’s a chance that people might learn about Microformats when they might not have otherwise of done. But we’ll see.

Paul:Bearing in mind that a lot of people listening to this podcast are web designers and you know, they are sitting there going “Well I know HTML”, like we were saying at the beginning that you have this perception that is something you know back to front. So just to finish up with is there a kind of one area that you really want to challenge people over or one piece of good practice that you’d like to push people on where they’re not as hot as they should be.

Ian:Hmmm… That’s a tricky one. I’m obviously aware that the audience of the podcast know a fair amount already. I guess you do have some people that are relative beginners so I’m not entirely sure the advice is appropriate for the audience. But the kind of advice that I would always give is that, and maybe I’m teaching people to suck eggs here, but really it’s so much more useful if you can learn from the ground up. You know, learn the code using really simple tools. I use Dreamweaver a lot, an awful lot, but that’s because I know how Dreamweaver is going to handle the markup. I know if there any little forbals, what it’s gonna do. So it’s very quick for me to use that without causing any real damage. But I wouldn’t really recommend that to a beginner. I’d say learn the basics. Walk before you run. Obviously things like I mentioned earlier – Word and Frontpage. Never, ever dream of using anything like that because they just do an awful, shocking job of it. In essence, HTML is not difficult to get to grips with. What I tend to find is a problem is what you then layer over the top of it. It’s the browser incompatibilities with CSS and obviously with Javascript it can be as simple or as complex as you like. HTML is not massively difficult to learn but it’s still useful to learn from the ground u
p and not let a tool do it for you. I think that’ll be my advice.

Paul:On one hand it’s not difficult to learn but on the other hand I think it’s quite difficult to master, if that makes sense. It takes quite a long time…

Ian:You’re talking about the pedantic kind of… When you start to argue about the fine details about which element is appropriate for this usage and you can get into some debates over some things, yeah.

Paul:I liked the way you referred to it as pedantic. Do you think we’ve gone a little bit overboard with our obsession with HTML and marking up everything correctly?

Ian:I don’t know. I think it’s a good thing that people discuss and try and squeeze the most out of it. But there are some grey areas and you do sometimes think it is a bit limited, hence things like Microformats adding the richness on top of it. But I don’t know. It’s usually good natured, put it that way.

Paul:Oh OK. I thought I was going to get you to say something really controversial that would get you flamed but I didn’t quite manage to…

Ian: What luck “HTML SUCKS!”?

Paul: Yeah like “Just use Frontpage. It’ll be fine man.”

Ian: Yeah something like that.

Paul:OK. Thank you so much for coming on the show and where can people check this out if they want to try out this reference for themselves?

Ian: The HTML reference is at http://reference.sitepoint.com/html and if you want the CSS reference, replace /HTML with /CSS. And I understand that the Javascript reference written by James Edwards aka BrotherCake is still ongoing. So at some part there will be a third part to this reference. So we’ll have all three layers.

Paul:And I have to say I’ve been impressed with what I’ve seen so far. I’ve actually been using the HTML reference believe it or not. In fact I used it yesterday to check something. I can highly recommend it. Much better than that crappy old W3Schools so you can ignore that from now on and use that instead. OK, thanks very much Ian. That was really good and I look forward to seeing you soon.

Ian: OK. Thank you very much Paul.

Thanks to Lee Theobald for transcribing this interview.

Back to top

Listeners feedback:

Can you trust developers?

JW writes: I have been on the buying side of both fixed and hourly projects with lackluster results lately. The process can be quite frustrating for me with some of the following bubbling to the top:

  • Inaccurate estimates both in cost and time
  • A lack of commitment to carry out all agreed items within a scope when it takes longer to accomplish than originally planned.
  • The need to ask for more money when the scope doesn’t change.

Which leaves me asking “How much is the developers “word” worth?”

JW’s email goes on to talk about the differences between fixed price and time and material work. I believe that this is where the heart of the problem lies.

I know many within the web design industry will disagree with me but I advise in my upcoming book to only work with developers willing to agree to a fix price contract.

There are always exceptions, such as when you have found a developer you know and trust. In such circumstances I suggest the complete opposite. However, generally speaking I don’t believe it should be the client who takes the risk for projects overrunning. Obviously, if the scope is changed by the client then additional work should be priced and agreed (once again on a fixed price contract).

Make sure the scope is clearly defined up front even if it delays the project starting. The tendency is to jump right into development work as soon as possible, especially when deadlines are tight. However, this could cause problems later.

Unfortunately, occasionally you will encounter a developer who agrees to fixed price project only to move the goal posts part way through the project. By this stage it is difficult to walk away. How then do you avoid ending up with this kind of developer?

There are two approaches that work well. First, before engaging a new developer ask to speak with a selection of their existing clients. If possible, contact clients independently of the developer. That way you won’t just get fed a tame client who is bound to say nice things.

Second, for larger projects consider separating off some of the initial work into a smaller self contained project. That way you can ‘try the agency out’ before committing to a larger project with a greater degree of risk.

In answer to the original question, I am sad to say you cannot trust a developers word. You have to put safe guards in place and mitigate the risk.

The life cycle of a website

Richard asks: What is the life cycle of the websites we develop as web designers? Do you see it as a short term year / year and a half, or a longer term two / three years? What kind of time period should we expect to wait before being contacted by a client about a potential redesign?

I would like to challenge two presumptions you make in your question. First, you are presuming sites should be redesigned periodically. Second, you suggest that the client has to come to you. In my opinion, neither are ideal scenarios.

I have written before about how, ideally websites should evolve rather than going through a continual cycle of redesign. I do however accept that this decision lies with the client and not yourself. Nevertheless I would encourage you to work hard at persuading the client of the benefits this approach brings. This serves both your interests as a web designer and those of your client. Throwing out all previous work on a site every couple of years is lunacy and totally unnecessary.

I also have to say that you are doing your clients a disservice by simply waiting for them to contact you. It is your role to continually suggest ideas on how their site could be improved based on emerging innovations.

We offer our clients the opportunity to regularly meet with us (free of charge) to discuss their site and where they should go next. This encourages them to think in terms of evolving their sites. It also ensures the sites do not stagnate and die.

Not that this approach is completely altruistic. By speaking with our
clients regularly we ensure they don’t forget us and increase the likelihood of repeat business.

Do we always take this approach? No. Some clients don’t want us continually pestering them. Some simply cannot afford to move their site forward. In this case we take a more passive role, encouraging them to read this blog or just ‘keep in touch’. However, this is the exception not the rule.

So to answer the original question; I would argue that the life cycle of a website should ideally be indefinite, as it evolves and changes overtime. This happens through a partnership between agency and client.

Back to top