Often people assume that I have done a lot of conference speaking, I’ve certainly been writing about the web for a long time but as it happens it’s only fairly recently in my career that I’ve been a speaker. In fact I used to be terrified of public speaking. I mentioned this to a couple of fairly new speakers at the conference and said I’d write up the things that had helped me get into public speaking as anyone who knows me well will testify to the fact that I was very afraid of speaking in public at all.

I’m certainly no expert at speaking, however if you are scared of speaking and think you absolutely couldn’t do it, then my experience shows that yes, you probably can.

Making a decision not to be scared

I had done a couple of very small talks and been a complete nervous wreck, even standing up and introducing myself and my business at a networking meeting would make me tremble, so I’d decided I was no good at speaking and also too scared to ever be able to do it. Then I was reading a book entitled Stop Thinking, Start Living by Richard Carlson (also the author of the popular “Don’t Sweat the Small Stuff”), and he recounted how he also had been terrified of public speaking but one day just realised that there was “nothing to fear”. It hadn’t occurred to me that I could stop being scared or that it might even be a decision I could make. So I thought I would try making a conscious decision not to be afraid. I stopped telling people I was too scared to do public speaking, I stopped telling myself I was too scared to do public speaking and when the next offer came in I said yes.

I don’t know how well this works for anyone else, but this seemed to work. Nothing had changed, I just wasn’t defining myself as a person who was scared any more.

Learning to present

I also decided that, if I was going to do this, I was going to do it well. I don’t like doing things badly. So I bought a pile of books. The most useful book I have read about the business of public speaking was by Scott Berkun – Confessions of a Public Speaker. Scott is a great speaker and a nice chap – I’ve actually had the pleasure of speaking at a conference he was also speaking at – and explains everything you might want to know about speaking in an entertaining way. I would recommend any speaker to get a copy of this book.

I also enjoyed reading The Presentation Secrets of Steve Jobs. That book deconstructs Steve Jobs’ presentations (all of which can be found online) and explains things about them that work really well.

I have also found the Presentation Zen blog and books really useful. As a non-designer Presentation Zen Design has been helpful when creating slides that will be shown to conferences full of designers.

Watch how other people present

Presentations aren’t really the best way for me to get info. I read very fast and have an excellent memory for things seen in print and very little memory for things I have heard. However I have been far more keen to watch other presentations since I started speaking as you can pick up lots of tips in terms of what works well and what doesn’t work from the other speakers.

It really does get easier

One thing people always tell you about public speaking is that it gets easier the more you do it. This really is true. The first few presentations I made after deciding I wasn’t going to be scared any more weren’t brilliant. The content was fine and I put a lot of work into them but I was still unsure of myself on stage and I feel as if I couldn’t get my personality across. That fact alone made me feel unhappy with the presentation. Being able to relax while presenting just seems to come with time.

Some assorted tips from a non-expert

These are some things that work for me.

If you are feeling nervous, getting some feedback from the audience early on really helps. At Front Trends I showed a slide with an ancient bit of JavaScript on it first of all and asked the audience if they knew what it was. I could have just told them straight away, but getting a response from the audience always breaks the ice. Once you realise they are just a nice bunch of folk who are interested in what you have to say it makes it far easier.

Timing is always hard, as a Geordie from the North-East of England my natural speech patterns are fast and I do tend to speed up. In my slide notes I put a note of time on certain key slides – so for the half hour Front Trends presentation I put a note in on the slide that should be at about halfway. Then if I hit that slide and I’m going too quickly or slowly I know I need to adjust a bit.

Experiment with different ways of creating a talk. I’m a writer first and foremost and have no problem writing an essay. I find it is easier to first write out my talks long form in essay format, once I’m happy with what I want to say I then start to create slides and work out how that essay translates to a presentation. I don’t ultimately read the essay, it just seems the best way for me to clarify my thoughts first. Other speakers create their talks on index cards, on sticky notes, as bullet points or mind maps. Play with various methods and see what works best for you.

Slide notes can help a great deal but try not to read them out. I always have notes in my Presenter View on Keynote for each slide. I often barely look at them, but if I lose my thread I know they are there. Just their presence really helps with nerves as you can always quite naturally stroll to your laptop – take a drink of water perhaps, and look at what you want to say next. If you feel as if you are speeding up it’s also a good way to reset your pace and looks totally natural to an audience. I noticed after watching the talks of experienced speakers how happy and comfortable they seemed to be with taking a few seconds to have a sip of water and pause before moving onto the next section.

Remember that you never look as nervous as you feel. You will notice that your hands are shaking, that you stumble over a word or two, or that you feel like the audience can hear your heart beating, just ignore it. The audience probably won’t notice at all and the more you think about being nervous, the more nervous you get!

Practice and practice and practice. Then practice a bit more. You will be more nervous if you feel unprepared.

Something that I worry about and that other people have said to me that they worry about is, “what if the audience have heard it all before?” When presenting at a technical conference it is easy to feel the pressure to have something new to say. Firstly, find out who the audience are from the organisers, and what sort of level of knowledge they are likely to have in the subject of your presentation. That way you can avoid beginner level introductions for an experienced audience or being over the head of an audience comprising of mainly beginners. For many web design and development conferences the audience will be very mixed, and in that case you really have to accept that some people may well have heard it all before, and that’s ok. The person next to them in the row may find your talk the most useful of the day.

Think of the audience as your peers, and that you are just sharing something interesting with them. Just as you might in conversation. If you think of yourself as THE EXPERT with something Very Important to Say that’s a lot of pressure to put yourself under! The most successful presentations I have given and also that I have listened to, have been those that shared something of the presenter’s working practices and experiences. What we do is interesting to other people who do similar things. Share your stories. Share problems and how you solved them.

You start a conversation when you do your presentation. The best thing for me is when afterwards, people come and chat, they tell me if what I said was helpful and sometimes they disagree with something I said. Those conversations often carry on into the after party or into future collaborations. Those conversations are a big part of what makes speaking enjoyable for me.

Further reading

I’m not an expert on speaking and my aim with this post is just to give some hope to anyone else who finds public speaking terrifying. It is possible to get to the point where you actually really enjoy it!

For some practical tips from very experienced speakers then I suggest you have a look at Seize the Room from Derek Featherstone, and also the chapter on Delivering Presentations from Chris Heilmann’s Developer Evangelism handbook.

If you have any tips and resources then please share them in the comments.

As so often happens, the ideal topic for the talk showed up quite naturally. Through things I have seen while supporting Perch, in the course of our own client work on the Greenbelt website in particular and in various conversations I have had recently a theme of understanding problems and solving them appropriately has developed.

In a post on the Pastry Box in April I thought about how our core languages of HTML, CSS and JavaScript were the things we could be sure of in a fast changing world of technologies. On this site I wrote about not solving problems before you have them, and also made some notes on the process of developing the Greenbelt website. I tried to pull together some of these thoughts in my 30 minute talk.

It was a really friendly, international crowd at Front Trends and my presentation seemed to be well received and also fit well amongst the thoughts of several other speakers. In my hotel room after day 1 I tried to include references where appropriate to speakers from the first day and pick up on common themes.

My slides can be found on Speaker Deck although they probably aren’t very useful on their own. I believe that the presentations were all recorded so if those go up I will no doubt tweet the link.

The Conference

My talk was just 30 minutes of a very enjoyable two day event. I was speaking in Day 2 so could sit back and enjoy the first day. It was fun to hear Vitaly Friedman speak about the Smashing Magazine redesign. It’s the first time I have met Vitaly, despite being a Smashing magazine contributor in the last couple of years.

Chris Coyier gave an entertaining presentation on the things we don’t know when developing a website. I referenced many of the articles that Chris has written on his CSS Tricks website when updating the CSS Anthology recently, it was great to actually meet in person.

I spent much of the conference hanging out with Harry Roberts and Jamie Mason. Harry thought his talk in day one might be in direct opposition to my talk in day two with my web standards focus. As it turned out our approaches are far closer than it might first appear. Harry is a senior UI developer for BSkyB, working with a large team, whereas I tend to work on projects with a very small team or where I have complete control of the front and often back-end. Our contexts are very different and it was interesting to hear what works well in these larger teams.

Another person I met for the first time was Lea Verou. I was really impressed by her live coding style with only the relevant CSS needed for people to understand the technique shown on the slides. This works really well and the demonstration of CSS transitions and animations was interesting as I haven’t yet really played with these effects in any great depth.

Where so many conferences beg the question, “where are all the women?” Front Trends had a very diverse line-up and there were also a lot of women attendees too – although the line for the ladies bathroom was notable by it’s absence! It was fantastic to be on the bill with so many other technical women. In addition to Lea, we heard Divya Manian speaking on Designing in the Browser. Tali Garsiel gave a fascinating presentation on How Browsers Work Internally. I enjoyed hearing how a browser actually takes our HTML and CSS and renders it – and the things we can do to improve speed and limit redraws when making changes using JavaScript. Rebecca Murphey struggled through her sore throat to give an interesting presentation on how to organise non-trivial JavaScript applications and we also heard from Jina Bolton and Tiffany Conroy.

The beer

Front Trends was the first conference I have been to where there was beer available during the sessions. There was always plenty of coffee, tea, water and a range of juices at all of the breaks however and while some people were enjoying a beer in the sunshine it didn’t seem problematic. I chose not to drink as I think the warm sun and a beer would have left me sleepy in the afternoon, and not drinking wasn’t an issue at all. The only negative that I put down to there being alcohol available was that the noise from outside did increase as the day went on, with people sitting outside to chat and not realising they could be heard even at the front of the auditorium. The sunny weather may have been as much to blame however and the relaxed atmosphere did make the conference feel very low-stress and fun. I think a good balance was struck all in all and another time perhaps it just needs someone to tell people to move away from the auditorium to chat!

Warsaw and Poland

Speakers were looked after very well and put in a hotel near the Old Town area of Warsaw. This meant that even though I only had a little time after arriving and on the morning that I left, I could still explore this part of Warsaw. It really is very pretty and interesting as much of it was rebuilt after WW2, you can see the photos that I took on my walk around on Flickr.

I would love to go back to Warsaw and spend more time being a tourist. There were lots of great places to eat – even vegetarian and vegan food – and thankfully for a non-Polish speaker most people spoke English and restaurants had English menus. There is also good, inexpensive public transport, which is useful as Warsaw is a lot bigger than I had imagined.

Front Trends has been a real highlight of this year so far and I think the most enjoyable conference I have been to in a long time. The atmosphere was fun but the content was also excellent, and I’d recommend attending future Front Trends events to any web developer.

We’re not interested in investment. We’re not a startup, we’re essentially a small software company. We “bootstrapped” Perch, out of profit from our service business, and it has been turning a profit since day one. However despite not being interested in investment I am very envious of the mutual support network that builds up around startup incubators and communities. Much of the focus around things like Y Combinator and the Brooklyn Beta Summer Camp is to get the startup to a point where it can get more investment. This is a reasonable goal, just not our goal. It does make me wonder if it would be possible to create a community of self-funded software companies based on the practical support we could offer each other.

It seems that companies who are developing and launching products without investment could do with working together even more so than invested companies. After all, we have to fund everything from our own pockets, usually can’t afford to go on a hiring spree to bring in skills that we need, and so rely on what we already know or can learn quickly. If we could exchange our specific knowledge with other companies that would hopefully benefit all of us.

As an example, I know a lot about payment integration. I can help a less techie company work out the best way to take payment for their digital product. I am not a marketing expert however and I’d love to chat with someone who is, and could give us some ideas as to new ways we could promote our product. An exchange of emails or a couple of phone conversations could probably save each of us a lot of time or potential mistakes.

I haven’t got a lot further than thinking that this could be a good thing. I don’t know if anything like this exists already. Perhaps all this is to start with is a Google group or similar for those of us who run small, self-funded product businesses and would like to chat to similar people and help each other out informally.

It may be I’m the only person who thinks this is a good idea. If you are in a similar situation and think it would be helpful then leave a comment (or contact me via email or Twitter) and with the knowledge that it isn’t just me thinking along these lines I’d start something up.

This situation is exactly what we asked for in the early days of the Web Standards movement. That browsers support standard features according to the spec, so that developers could build their site using a single browser and be confident that it would then work in the other browsers. Vendor prefixes aside (and I personally believe they are a sane solution to the problem of implementing early stage CSS) that is where we are now. I do most development in Firefox on my Linux desktop and it just works in the other modern browsers and platforms that I test in. Even something that might be considered complex – such as a large-scale responsive design – works pretty consistently across not only desktop browsers but mobile ones too.

However, despite us entering a seemingly golden age of browser consistency, what I am seeing is an increasing reliance on a whole slew of polyfills, CSS frameworks and boilerplate starting points. I am concerned that these things are being promoted as something everyone should include from the outset, rather than being a toolkit you draw on to deal with problems once they have arisen.

Here is my “HTML5 boilerplate”


<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
</body>
</html>

That’s it. For at the start of a project I don’t necessarily know what problems I am going to encounter and how I might deal with them. Adding a bunch of polyfill JavaScript at the start doesn’t help. Firstly, I might not need it, however if I have been developing with it there from the start how do I know if there is a better way to do things that negate the requirement for it? Secondly, it might actually cause me a problem – is that issue I am seeing a browser bug, or a problem with the polyfill? Thirdly, if I am adding a lot of JavaScript right from the start I am very likely to end up with bits of my layout needlessly requiring JavaScript to work.

Take the Greenbelt website I wrote about last week. I was working alongside the designer when developing the site, I didn’t know at the start exactly how we would solve many of the problems inherent in such a large, responsive site. So I developed the site for modern browsers, working in Firefox, with a mobile first approach. The only thought I put in for older browsers during the entire front-end development was to make a note of any CSS3 Selectors that I knew were unsupported in IE8 and below. Once we had the site developed and snagged in modern browsers on desktop and mobile, I moved on to look at IE8, 7 and 6.

Problem 1: IE8 and below have no support for media queries

At first view, IE8 was showing the mobile version of the site as it did not load in the other stylesheets. Here I could choose to use respond.js to enable support for media queries (but create a reliance on JavaScript) or include a stylesheet for IE8 that fixed the width. I chose the latter option. I also used this stylesheet to fix up a few small CSS issues that I spotted in IE8.

Problem 2: IE8 and below had no support for certain CSS3 selectors

Some of my layout looked a bit wonky due to my use of CSS3 selectors. I do love my CSS3 selectors. I knew this would be an issue and again I had a choice. I could use a polyfill such as Selectivizr or I could polyfill them myself with jQuery. As we were already using jQuery on the site and I knew exactly which selectors were an issue I chose to just add a function into our global UI file to polyfill these myself. If the site had been littered with these issues then I might have chosen to just use Selectivizr – again, by waiting until I could see the problem I was in the best place to make a decision.

Problem 3: IE6 and 7 … what are you doing?

With the IE8 stylesheet loaded for IE8 and below, the layout actually held up reasonably well in older Internet Explorer browsers. There were of course the usual crazy layout issues which were mainly solved by getting the element concerned to have layout, and a few rounding issues. However I was surprised at how well the layout worked considering that everything bar a few items was still sized using percentages – my IE8 and below stylesheet having fixed the width of the main container.

This large and complex site, which had been over 4 months in development, was tidied up in old browsers in around 1 day of work, mainly by way of CSS added via our old friend the conditional comment.

Don’t solve problems that you don’t have

Build for modern browsers. Test your work in those and make sure the experience for an up to date browsers is as you want it. Then look at the problems you have, alongside your policy in terms of what you are delivering to older browsers, and see what you need to fix those issues.

There is some amazing work out there in terms of polyfills, frameworks and libraries. However you don’t have to use them, and in many cases won’t need to use them. So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

If you are an experienced developer be very careful about suggesting that a whole slew of things are required as a solid base for any given project. Depending on the sort of projects you work on, it may well be that you do need all of this stuff and make use of it well. However, it’s a confusing world of options out there to the beginner and learning the basics of HTML and CSS development for modern browsers, then solving the issues that come up, is still the best grounding for any new developer.

This is a really special project for us. Our company has a long working relationship with Greenbelt Festivals, we have for many years looked after their box office and customer database. We are also however Greenbelters and Greenbelt volunteers, onsite Drew volunteers with the official photography team and I volunteer as a floor manager in the GTV Studio. We love the festival, so it was always going to be a labour of love as well as an interesting client project.

Greenbelt placed a lot of trust in us to design the architecture of the site, and what we tried to do from the outset was provide them with an infrastructure not just for the main site, but for other projects in the future. In doing so we’ve met a lot of interesting challenges and both Drew and myself will be writing about these in the coming weeks.

My role in this project was mostly on the front-end, and so this post is to outline some of the decisions that went into the front-end of the site. All of these points probably deserve their own post, and I’ll expand more in future weeks rather than create an epic Friday afternoon essay.

A responsive design

From the outset we knew we wanted to provide the site with a responsive design. It makes absolute sense for Greenbelt, the festival has always embraced new technology and mobile – there are iPhone and Android apps developed for the festival guide. We know there are a lot of people onsite at the festival using mobile devices and also who use them at home.

That said, I wanted to built the site in a responsive way but without creating a reliance on JavaScript or bloating the front-end. I wanted to be able to take a sane approach to responsive design that wouldn’t store up a whole bunch of technical debt for me to wade through every time I needed to make a change. I also wanted to support old browsers in line with what I knew from looking at the statistics for the existing site – but in a way that made it easy for me to drop the extra stylesheets when they started to disappear from the stats.

I’m not into cleverness for it’s own sake, so if we were doing responsive design it was going to be a responsible responsive design, progressively enhanced to support as many users and devices as possible.

Embracing the one web

I was very keen that we didn’t offer a cutdown version of the site to people on mobile devices. I wanted someone on a phone to be able to access all of the content and the phone and tablet versions of the layout to be understandable in the context of the desktop layout. My aim was that the content was the same no matter what you used to access it – embracing a one web approach.

I am using a mobile first approach, with media queries loading in the layout and changed navigation for larger screen widths. This means that mobile devices and those browsers that do not support media queries get the basic stylesheet. This contains all the text formatting that will make the site readable. The exception to this being the older versions of Internet Explorer that made a significant appearance in our server statistics – and I explain my approach there below.

It had to be super fast – for everyone

As Bruce Lawson pointed out in a post yesterday, speed is important. Even if a user has a large screen, it doesn’t mean that they are actually on fast broadband. In our case it was highly likely they are using mobile broadband or slow wifi while at the festival. Therefore instead of worrying especially about load times for mobile devices, we worried about load times for everyone. From a front-end perspective that meant compiling together CSS where appropriate, not writing bloated CSS and mark-up, ensuring images were optimised as much as possible and served quickly. While optimising the front-end was important – serving these assets quickly turned out to be the most important thing. Read Drew’s post on How to Make Your Website Fast.

What we ultimately didn’t do was attempt to serve different images at different breakpoints, instead preferring to try and optimise all images and serve them quickly. As already mentioned many users may be at standard desktop size yet using mobile data connections and a small images for small screens approach wouldn’t help them. I am following with interest the responsive images debates and this may well be something we revisit. All assets are served via a media server built as part of the project so recreating assets for a future responsive images strategy is a possibility.

Care and feeding of old browsers

When I was in the final stages of browser testing the site, I was making silly comments about IE6 on Twitter and was surprised at the number of people who acted with some incredulity that we would “support IE6″. Not supporting IE6 was never an issue, it’s a browser people use, it shows up in the logs. It may well just be people in offices who still use IE6 checking the festival date to fill in a holiday form, but I am going to support them.

That said, I will not reduce the experience for the majority in order to support legacy browsers. Support does not equal “looks the same” I am also very against solving problems before I have them with a starting point of a mass of polyfill JavaScript as some kind of “boilerplate”.

Looking at the stats our Internet Explorer users were split mostly between IE9 and IE8. The site worked beautifully on IE9, the problem we had with IE8 was that our media queries – used to deliver the mobile first design – are not supported. I could have used respond.js to polyfill media query support for Internet Explorer 8 and below but I don’t see what the benefit of doing so really is. IE8 users are on a desktop and a fixed width layout is appropriate, so as part of the compilation process for the CSS we compiled together all of the layout CSS and served that to IE8 in a conditional comment with an additional stylesheet to fix the width at 940 pixels. With a few lines of JavaScript to polyfill some selectors we were done. As IE8 is using the main CSS any changes will be compiled into the CSS for IE8 and I don’t have the overhead of maintaining different stylesheets for browsers that are going away.

As you can imagine IE6 and 7 needed a little more shoehorning to get them to behave but they also are served the old IE CSS along with additional CSS to prod difficult elements into place. It turned out to be pretty trivial to serve most of the layout to IE6 and 7 and the number of IE7 users we have in particular warranted that extra work. In the future we may just serve IE6 the basic styles as usage drops off.

HTML5

If you look at the source the site has an HTML5 doctype however we are not, at this point, using HTML5 semantic elements. The reason for this being that I wanted to be able to support old browsers without the use of JavaScript or adding redundant mark-up. That said it probably would take no more than a day to switch the site to using HTML5 elements in the mark-up once we get to a point with those old browsers that we feel happy just serving them the mobile stylesheet. All of the mark-up is templated rather than being mixed into the PHP. I also tried to avoid clarifying selectors with an element extensively in the CSS – meaning that .wrapper for example could select div.wrapper now and section.wrapper in the future.

The big use of HTML5 on this site is in the media section. All of the video and audio content is served as HTML5 with Flash for fallback. We are currently using encoding.com to encode the various formats for video.

Navigation

The hardest part of the front-end build was the navigation. There is an awful lot of it and some of it is fairly complicated – for example the facets in the contributors section. I’m pretty pleased with the end result that Wilf, Drew and I came up with, I’m sure it can be refined as we see how people use it and navigate in practice.

… and relax

I can’t remember the last time I was so nervous when a site went live. We really wanted to produce something that would bring the festival to people all year round, that Greenbelters would love. Hearing good reactions from other people who love the festival was worth a lot. Greenbelt produce a huge amount of content, which previously was spread over various sites such as Flickr and YouTube. Being able to centralise and make use of that content really has been one of the big challenges of the project, and it is lovely to see people enjoying the effort that has been put in by so many people over the years.

It doesn’t end here, we’re very happy that we have a continued involvement in the site as well as the festival and I’m really looking forward to helping Greenbelt share all the fantastic stuff they are doing at the festival and throughout the year.

I thought I’d have a look back over the last year of blog posts here, and I am glad to say that I did post much more than in the year before. It was really interesting to look back over my year of posting and to see what I happened to be thinking about at different points that made it onto the blog.

In March I raised my concerns about StartUp Britain and in April explained why I do not want to be called a Mumpreneur.

In May 2011 I mused over the tendency of people to choose one tool and use it for everything however unsuitable in “If all you have is a hammer…”, then asked readers to Stop turning contact form spam into a user problem and also wrote up my post-FOWD thoughts.

In June I posted a roundup of things people need to know when starting a business or going freelance in the UK, in response to answering that question many times on forums. I realise that I often use my blog in this way. Instead of saying the same thing to lots of people I will write up my thoughts and point them to it – which also gives a place where people can add to my thoughts in the comments.

In July I spoke at the Highland Fling conference in Edinburgh, about content management. This helped me formalize a lot of thoughts I had been having around the subject and I wrote two posts. Your CMS as Curator of your Design and Content discusses how a good CMS can help inexperienced content authors to preserve the content strategy of a website. Your WYSIWYG Editor sucks explains why they suck, and what we should be doing about it!

In September the theme was very much online payments, and the two posts where again very much in the spirit of sharing things that I’ve had to figure out in regard to the thorny issues of taking payment online – How to move your online sales away from PayPal and Complying with PCI-DSS when using a hosted payment page.

In November I posted my thoughts on the startup “bubble” in Setting people up to fail – why I am afraid of the bubble. I also got annoyed with flashing and rotating banner ads and wrote Include your advertising policy when considering website accessibility.

In December I pointed out that there were other ways to do business than the working every single hour, sleeping under your desk start-up culture might have you believe. In response to a high-level of industry snark I asked people to be kind to one another and also thought about how so often “lucky” people are just the ones who say yes.

I started 2012 by presenting at an online conference, talking about our product Perch, and then posted my thoughts on the conference and on presenting online. In February I posted some tips on writing tutorials for a beginner audience then I rounded up this year of ideas with an announcement of my new book – The CSS3 Anthology.

For this next year I’d like to share more of the interesting things we have been doing at edgeofmyseat.com – including work on Perch and also client work. Looking back over the last year shows that people do still comment on blog posts, many of my posts got more than 10 comments and sparked responses on other blogs too. That to me is the great thing about blog posts. I ponder on some subject that interests me and then see the comments and response posts come in, all giving me more to think about and other insights into a subject. That collated knowledge is then out there and available for other people to think about. In an industry where many of us work alone for a lot of the time, blog posts can help us debate and share information and ideas.

If you would like to revive your blog:

• Write a post called Ideas of March.
• Write about why you like blogs.
• If you don’t already blog regularly, pledge to blog more the rest of the month.
• Share your thoughts on Twitter with the #ideasofmarch hashtag.

The first edition of the book was published in 2004. It contained solutions such as, “How do I hide CSS from Netscape 4″. In many ways the situation we were facing with Netscape 4 was very similar to that with Internet Explorer 6 today. The browser had almost gone away, but was present enough in particular contexts, that most of us were still needing to account for it in testing. The second and third editions left the version four and five browsers behind, however were very much updates to the material from that first book.

The 2011 fourth edition is an almost complete rewrite. I have always aimed to make this book a practical handbook of CSS tips that I would happily use myself in production code. When I wrote the third edition browser support for CSS3 was such that I couldn’t do much more than mention in notes that there were better ways to achieve things on the horizon. This time CSS3 is front and centre – with a chapter dedicated to helping you decide what to do with the old browsers that some of us still need to support.

It’s not only browser support for CSS3 that is new. Our attitude to device support and our understanding of what the mobile web will mean to web design and development has changed. New concepts such as responsive design have transformed the way we think about supporting devices. Older editions of this book demonstrated how one might create a layout to be fixed width or fluid. In this version the final chapter demonstrates how to create fixed width layouts but quickly moves on to serve as an introduction to responsive design.

The book aims to be practical and down to earth, and I hope will be really useful to readers. If you’ve read it then I’d love to know what you think!

Your job is to get your reader to the point of asking the next question

You cannot teach your reader everything you know about a subject, somehow getting them to the same level you are in the course of a book or article. Your job is to get them to the point where they can implement something at a basic level, and understand what they might need to search for to be able to take their knowledge to the next level. Trying to explain too much – for example going into alternate theories of “best practice” or detailing edge cases where a technique might not work is best kept for a more advanced tutorial.

Address a solution in the context of the problem your reader might have encountered

This is a really helpful way to explain things. As an example, if I am writing about CSS and explaining how to clear floats, I will introduce the subject with an example. I show the reader an example of some elements in a container that has a background colour. After floating the elements the background disappears – what has happened? I can then go on to describe how floats work, and the various methods of clearing in the context of a problem they may well already have encountered, or will encounter at some point.

In the case of online writing, explaining the problem is also very helpful in terms of people finding your work via search engines, as they won’t be searching for the solution – they’ll be searching on keywords relating to the problem.

Demonstrate the simplest cases

Try and make examples as simple as possible, it’s very tempting to show “real world” examples, with all of their inherent complexities. However if there is too much going on in an example, it weakens and makes less clear the point you are trying to get across.

It is often necessary to explain a problem within the context of how it will be used – however making those contexts as simple as is possible will help your main point to become the focus of learning, and avoid the reader becoming confused as to what is actually creating the effect that you are describing.

However when simplifying, take note of my next point.

Be careful not to leave security holes in copy and paste code

It’s not too much of a problem to simplify examples in CSS, however if you are writing about serverside technology then there are levels of complexity that you cannot avoid including. Christian Heilmann has written about the very real issues of showing a cool technique simply, at the expense of security in his article, Teach Them How To Hit The Ground Running And Faceplant At The Same Time?, for Smashing Magazine.

Just saying, “this is not production code” is not enough. People will still copy it and use it as is. Often people don’t even fully read an article that has code in it, they just grab the code example and use it.

Often the best approach is to avoid showing any fully worked code on the page. This stops a person just using the code as is. Show the snippet you are describing and then provide a link to a fully worked and commented download that includes any functions or linked in libraries that will allow the reader to deploy the example in a live site safely.

You can treat included libraries as a black box, meaning that you don’t need to fully explain what they do, more than a couple of lines or a code comment to justify the inclusion and say why it is important. This maintains simplicity and gets round the copy and paste code problem.

Use words and phrases that your reader can Google to find more information

It’s important that you include in your writing the key words and phrases that people could stick into Google in order to find out more. Sometimes this won’t actually be strictly correct terminology, in which case you can explain what something is called and then also say, “often referred to as [...]” or even, “you’ll find more information on this subject by searching for [...]“.

Short, to the point, question and answer solutions work well

The format that Sitepoint asked me to use when I wrote the first edition of The CSS Anthology was one of short questions and answers, each dealing with a particular CSS topic. The book has maintained that approach right through the the fourth edition that I am currently working on. Sitepoint have used the same approach on several other books dealing with different technical topics and it is an approach that really works well. As a writer or speaker, sticking to answering a question helps keep the solution focused and helps stop you heading off down various tangents. The reader also gets a clear solution to a real problem, so they feel they have a “take away” that works.

Build something that works as quickly as possible

When learning any new subject, getting to the point of having built something that works is really important. It’s at that point you can say, “I did that!” Having “done it” builds confidence. This is especially true when teaching technical concepts to people who don’t feel this is their strongest area. The most important thing you can do for a reader or talk attendee who is feeling outside their comfort zone, is to get them quickly building something that works. Realising that they can do it, that they can understand, will give them confidence to continue and build on those first steps.

I really enjoy helping people make their first steps into learning about a subject. I often hear from people who started learning CSS with The CSS Anthology, who are now excellent front-end developers and could probably teach me a thing or two!

If you write for beginners and have tips to share, add them to the comments.

… inspire, engage and inform women showing how bloomin’ marvelous the digital world can be.

As I explained to .NET Magazine when I was contacted by them to comment on my involvement, I’m not comfortable with women only groups and events where they encourage an “us and them” attitude. I don’t think we do ourselves any favours if we simply huddle up in a corner together. However, given that there are fewer women involved in technology, it doesn’t hurt to make sure that those of us who are working in the business are visible. If only so that women thinking of this industry as a career can see role models, see that there are women working right across the industry.

I presented new material on “Launching a Product“. This is something I have been wanting to speak about for a while, and was based on our experiences launching Perch two and a half years ago. I had some nice feedback on Twitter after the event and I hope that the attendees enjoyed it.

The problem with presenting online is it is really difficult to get a feel for if the attendees are enjoying it. Essentially I was presenting to my own computer for an hour, trying not to get distracted by cats wandering around the office car park. None of the clues I pick up when presenting live are there. I’ve done a few online presentations now and the only way to get a feel for how it went is to check Twitter and hope someone says something about my talk!

I had some encouraging feedback on Twitter from this presentation but it led me to wondering how we can improve the feel of an online conference for speakers and attendees. In addition to feedback when presenting onstage, another important place I get feedback after a presentation is in the breaks afterwards. It isn’t about people coming up and telling me they loved it, but rather the questions they come and ask. The ideas they want to discuss. Then I know that the things I have said have hit a chord with a person, and may also pick up something that should be added to the presentation another time.

For attendees an important part of a real world conference experience is discussion with speakers and with each other. The online conferences I have been involved with have generally had a short period of questions after the presentation. Is there a good way to facilitate a more relaxed question and answer session, perhaps using IRC or similar?

With many companies cutting back, employees may find they don’t have the budget to travel to conferences, so I think online conferences are valuable and here to stay. However with so much of the conference experience being the bits between the presentations, I wonder if we can partly create that atmosphere for speakers and attendees albeit in a virtual way.

The first thing I got about the web was its ability to empower the maker. The year was 1995, and I was tinkering at my first website. The medium was raw and ugly, like a forceps baby; yet even in its blind, howling state, it made me a writer, a designer, and a publisher — ambitions which had eluded me during more than a decade of underachieving desert wanderings.

I say “it made me” but I made it, too. You get the power by using it. Nobody confers it on you.

The Maker Makes – on Design, Community and Personal Empowerment

I would be the first to admit I’ve been incredibly fortunate. I stumbled across the web in 1996. At 21 I was pregnant, out of work and with no realistic chance of going back into the job I had been doing. Working as stage crew is not compatible with newborn babies. I had left school at 16 with terrible GCSE results to study dance and all I had ever intended to do was in the theatre in some capacity, it was all I really knew.

Teaching myself HTML, then Perl and Linux systems administration might have been an odd choice, but the web saved me. It enabled me to go back into work in 2000 in a technical role; to use skills I never knew I had; to make wonderful online friends at a time when I was terribly isolated from everything I had known. As I learned things I wrote about them. It seemed obvious to me as I had learned everything I knew from things other people had written, and given freely, that I should also write – just in case it was helpful to someone else.

I helped people out in forums – at the time I used Dreamweaver and the active Macromedia forum had been really helpful to me, so I picked off the easy questions that I could answer and answered them. Paying back the help I had been given.

In time I was offered the chance to write a couple of chapters of a book. I didn’t see the articles I was writing as really writing, I was just making notes to help other people. As I’ve already explained I had no real qualifications, not even traditional qualifications in another subject, and this left me feeling pretty scared. Was I about to be “found out” as this unqualified fool who had the nerve to write an actual book! I said yes. I kept saying yes, and somehow here I am 10 years later and working on the fourth edition of the CSS Anthology. I frequently hear from people who feel one of my books really helped them to get started in this business, and that is a wonderful thing.

However you will not find techniques out there with my name on them. I’m not the inventor of a CSS trick or technique that everyone uses. All I have ever done is worked out how to do things and then written down what I did, in a way that someone who hasn’t worked it out yet can understand. I keep a list, it contains interesting things that I have done at work, that I think would make a good article, presentation or blog post. When I have time I write one up; include them in a book I’m working on or pitch it as an idea for a conference presentation.

So what I do now is not so different to what I did then. I do interesting things in the course of my job and I write – and speak – about them. That path is open to anyone. As Jeremy points out, there are always sites looking for article submissions and conferences needing speakers. If you have something interesting to say – whether it is a new technique or just a good explanation of something useful – then pitch it! If you have no writing track record then your own blog is a good place to start. If you have no speaking track record then look for local events that need speakers for short presentations.

Make 2012 the year you go out and do it. Don’t complain about the “same old faces” – be a new face! If you have something to say you will be most welcome. Don’t worry if you have nothing ground-breaking to talk about, there is always a place for well written tutorials and practical conference sessions. Pitch your work to the places it best fits. Say yes a lot, especially to the things that scare you, and be part of making the web better for yourself and for the people who will be helped by what you contribute.