Rachel Andrew

Rachel Andrew is a web developer with skills both in server-side languages and front-end development. She has written numerous acclaimed books, including The CSS Anthology: 101 Essential Tips, Tricks & Hacks, HTML Utopia: Designing Without Tables Using CSS, and Everything You Know About CSS is Wrong. Rachel is the director of edgeofmyseat.com, and she co-created Perch, the really little, super-efficient content management system.

Rachel has a personal website, and tweets @rachelandrew.

Published Thoughts

When I was about fifteen, a little younger than my teenage daughter, two men in suits came to my school. They spoke to us in a careers lesson; told us how important computers would be to all of our futures. I had my hand up quickly, to tell them that I was going to have nothing to do with computers. What use were computers to a dancer? The men couldn’t think of a response to that, and agreed that perhaps dancers wouldn’t need to know about computers.

Fifteen year old me could not have imagined the world we now live in. The phone I carry with me is far more powerful than the 486 I ultimately taught myself HTML on. My daughter, a dance student herself, uses computers every day. I wish I’d had access to my entire music library on an iPod, her ability to research ideas online rather than sitting in libraries, and the chance to stay in touch with people she has performed with so easily.

Nothing of what I do professionally existed when I was the age my daughter is now. I am grateful that my teenage angst was recorded in temporary form in diaries and not all over an Internet that never forgets. However I am envious of the photos and video she will have to look back on. What will exist by the time she is my age? That thought is both terrifying and exciting.

At this time of year I often get asked for predictions. What do I think will happen next year, or in five years time? I don’t know, and I’m happy with that. Fifteen year old me thought that what I was doing then, was what I would always be doing. Almost forty year old me is pretty sure there are some amazing things just round the corner. I can’t wait to see what they will help us to create.

Drew and I were chatting over breakfast one Thursday about a significant feature addition for our product, Perch. We decided that the idea was good, fulfilled some customer requests and that we should build it. By the end of the day on Friday we shipped the feature. Less than 48 hours after our conversation.

Such is the joy of a small team, a team in touch with those who use and love our product. We frequently have a discussion with a customer in the forum, like their idea for a feature and immediately implement it. There is great satisfaction in posting back to let a customer know that the feature they needed has been shipped.

Being in touch with our customers helps us to quickly react to their requirements. Understanding and caring about changes in trends and best practice in our industry helps us to create features that support the latest ways of working. As a bootstrapped product we have no investors to keep happy. The Perch roadmap is decided in the discussions between me, Drew and our customers. I can’t imagine doing it any other way.

Due to spending a lot of time at conferences this year, I’ve been thinking about how the advice we give from the stage, or in our writing, scales up and down to the various contexts in which people are developing for the web.

The company I founded in 2001 has a long history of working as an outsourced development agency, working for small design companies. We spent years being thrown Photoshop documents, pictures of websites, and being expected to develop them. In 2011 we started to move away from the model as we couldn’t deliver the sort of sites we wanted to deliver, do the standard of work we wanted to do, when the people we worked for just wanted to draw a website and then not play any further part in the process.

All that said, this model of tightly scoped roles is reality for many small agencies and individual freelancers. We can preach from a conference stage all we like about the ideal way to develop a site, about best practice, about developers sitting alongside designers. From experience however, and from hallway conversations I know that many of those we talk to essentially work alone. When they get a project that is outside their expertise they have to either turn it down, or outsource bits of it.

I have been that outsourced developer. I still work in that world through our product Perch. Many, probably most, of our customers are individuals or tiny design agencies. Many of them rely on products like Perch not just as a content management system, but also to deliver the site itself. The CMS provides functionality that they would otherwise have to outsource to a developer.

This is for everyone, the web is for everyone. Creating good websites is possible on a tiny budget just as much as on a grand scale. However speaking from personal experience it can be easy to write advice off as not for people or companies like us.

While we are exploring best practice for the web of today and tomorrow, I am keen to ensure that we don’t stop looking for ways to create tools and processes that help the lone designer or developer collaborate well with others. How do we distill the lessons learned in big teams, where people can work alongside each other, into tools and working practices that function when these people can never physically meet? How do we take the essence of best practices from large budget sites — and allow the creators of sites with tiny budgets to benefit from them?

Something that puzzles us in technical support for Perch: The number of web designers and capable front-end developers who are unable to diagnose something as simple as a 404, file not found. Or have little understanding of what any server-side solution might be doing. We read some very strange theories as to what our users believe is happening when they encounter a problem due to this lack of understanding of what happens prior to html being delivered to the browser.

Perhaps those of us who began working on the web in the early days have an advantage here. When I wanted to start doing server-side development, I bought a tatty old Compaq desktop from a chap who sold old technology that businesses wanted to recycle. I then had to work out how to install Linux, compile Apache and configure Perl to work with the web server. This took days. This was before I even started to learn Perl. However, this somewhat torturous process taught me how web pages are served. I read a seemingly endless string of error messages; I learned how to search the web and Usenet for answers; I learned how to formulate a post asking for help in a way that wouldn't get me flamed and might get me an answer.

In 2012 many people who are working with server-side development seem barely aware that is what they are doing. One-click installs of WordPress and similar on their hosting causes the process of getting set up to be hidden. They work, quite terrifyingly, directly on their live server. Even if you want to go one step beyond that and run a local development environment that is now incredibly trivial to set up due to packages such as XAMPP and Mamp. We can easily find ourselves protected from the technology that we are relying on to serve our sites.

All this ease and convenience is great. I don't think that everyone building a website should be forced to compile Apache from scratch. However I do believe that if you are developing for the web, you need to have enough understanding to be able to take a holistic view of the entire process. If you do not understand how a script serves up your HTML, then it will appear baffling when something goes wrong. It will be very hard for you to start to diagnose problems, even enough to be able to raise a support request that will get you help.

If you are working with any kind of CMS, blogging software or other server-side solution and are treating it as a black box, you will be amazed at how a little bit of time invested in understanding how this stuff works can save you hours in the long run.

It is summer. We get about a week of actual summer here in the UK, a brief glimpse of what it must be like to live somewhere hot and sunny and then the clouds roll in again, and the rain starts.

This year we also have the Olympics. The rowing events happen just down the road from where I live and work, at Eton Dorney. I don’t have tickets, as they are like gold dust, but the coverage on TV is impressive—we cycled up there a week before the event started to see the huge towers they have erected for the world’s longest ever Sky Cam system.

Even if it rains I still enjoy the longer summer days as I like to be able to run before or after work while it is still daylight. I’m a fairly recent convert to participating in sport. I’m an ex-dancer so I didn’t really do much sport at school, however in the last few years I have discovered running and now run half marathons. I started by doing the Couch 2 5K Program, and once I could run 5K joined a running group, the ladies there encouraging me to work up to the half marathon distance. This year I decided to join the local athletics club. There they have runners who frequently come in first in local races—to me these were the serious, “proper” runners. I was pretty nervous going along to my first ever track session.

I didn’t need to worry. As someone who has come to running fairly late, and with a stack of injuries working against me, I’m never going to be anywhere near the fastest person there. It doesn’t matter. They met me where I was. My starting point was my level of fitness and ability when I walked through the door, my achievements at chipping a little bit off my times are noted. I don’t feel like a second class member, or compared negatively to those who actually win races.

Back to the day job. I spend quite a lot of time supporting users of our CMS product, Perch. Our customers range from our peers in the industry, to people who are just starting in web design. Including those who can’t even really write HTML as they have been using some software to generate their HTML pages. Many of the support tickets we see raised have little to do with our product and everything to do with a lack of knowledge of HTML, or the fundamentals of how the web works.

I’m sometimes asked whether it is really frustrating dealing with customers who don’t understand HTML and CSS, and yes, sometimes it is. It would be a lot easier if everyone had 10+ years of experience and cared deeply about web standards, but they don’t. We have to meet people where they are. We have to understand what they are trying to achieve and try and steer them towards the best solution for them. Should we demand that every person building a site as a hobby understands the finer points of best practice? I suggest not, the web has always enabled people to create, and I would hate that to change. Should we pour scorn on the student who has been taught outdated practice at their college and now is having to unlearn all of that to progress in their web career? I don’t think so, but have seen it happen.

Many people will be inspired by the Olympics to get active. I hope they all find local clubs and gyms full of people willing to meet them where they are and help them to achieve their goals. Even if they will always be in the back half of the field come race day. Achievement in sport for most of us is not about being better than everyone else, it is about being a bit better than we were last time.

Likewise I hope we, the community of experienced web designers and developers, remember that some people are beginners, some have been taught incorrectly, and others are just having fun building sites as a hobby. That those things that seem obvious to us can be baffling to someone who hasn’t had the benefit of years in the industry, or great people to work closely with. When we meet people where they are, helping them is far less frustrating, and we can support and encourage them as they go on to achieve more than they realised they could.

How did I get here?

We have directed you here because your browser does not support accepted web standards. Or you may have followed a link to this page in order to learn more about upgrading your browser.

What “web standards?”

The ones created by the World Wide Web Consortium – the people who invented the Web itself. The W3C created these standards so the Web would work better for everyone. New browsers, in general, support these standards; old browsers, in general, don’t.

What can I do?

Your choice of software may be out of your hands. However, if you do have control over what software you are using you should consider upgrading your browser. Doing so will improve your web experience, enabling you to use and view sites as their creators intended.

The above text is from the Web Standards Project “Browser Upgrade Campaign” launched in early 2001. Web designers and developers were frustrated that people were not upgrading away from the buggy Netscape 4. To fix this problem, and encouraged by WaSP, designers started putting a message on their sites exhorting people to upgrade or even redirecting them to a page blocking access to the site. A search on Google for some of the above text finds many of these upgrade pages still in existence.

As time has passed most of us have realised that locking people out of sites because we don’t like their browser is not appropriate. However, ever since 2001, our frustrations repeat. Internet Explorer 6 becomes the enemy. An online retailer runs a PR stunt announcing that they would apply a tax to anyone using their store with IE7 due to the cost of supporting these older browsers. 37 Signals announce that people using Internet Explorer in the latest versions of their product will require IE9 or greater.

The better our browsers become the more this frustration looks like the whining of people who forget that not everyone is on a shiny Mac, on a fast net connection with easy access to the latest browsers; who forget that many regular folk do not even know what a browser is. If you are a professional web developer then your job is to deal with legacy browsers, operating systems and devices. That was the case in 2001 and it is still the case now. The faster the pace of new additions to HTML and CSS, then the quicker perfectly capable browsers look out of date due to their lack of support. However as anyone who developed for Netscape 4 will tell you, lack of support is very different from buggy support. We have never had it so good.

Of course supporting and testing in older browsers adds time and effort to our projects. Doing a professional job does take time, effort and thought. I will continue to be led by the real browser stats I check before starting work on a project. The decision as to which browsers I support and the level of support I give them is not an arbitrary one that I make, it is led by data, and is different from project to project.

If you believe that your job is to show off how clever you are with the latest technologies then you will always be frustrated by older browsers. However the web I care about is the web that is for everyone, that enables people to participate, learn and communicate with each other across many different divides. My job is developing for that web, and sometimes that means I have to make technology choices that aren’t quite as fun or interesting to me. That’s a shame, but ultimately I’m not developing these sites for me. By keeping my user in mind I know that the work I do to give them an appropriate level of support is worthwhile.

The web makes being a creator easier than ever before. Creators of digital things need no raw materials and no expensive machinery to get started. A computer, an idea, some talent and hard work can turn out a product that makes the lives and businesses of thousands of people better.

Many of the products, services and websites I use in the course of my work are created by individuals and small teams. I didn’t give this a lot of thought until we became a small software vendor with the launch of our product Perch in 2009. When you make a thing that other people use; you really care about your product and the experience people have with it. I can’t stress enough how happy a positive bit of feedback can make you. Equally, a harsh review from a frustrated user can feel devastating.

Armed with this knowledge I try to remember to tell makers when I love their product, rather than just assuming my continued use shows that I am happy. I also try to phrase criticism in a way that is constructive, kind and helpful. We often find that our greatest fans are our toughest critics. They love the product and want us to continue improving it and their suggestions often go into the product. Makers want your feedback as well as your praise.

Have a look at the products and services you use. Which are made by individuals or small teams? Which of them would you really miss if they disappeared? Have you ever dropped the maker a note via email or Twitter to say how much you love using their work? If not, why not do that today?

I enjoy reading books by successful people in different types of business. In our very new industry I think we can learn a lot from more established industries. I recently read Strong Woman: Ambition, Grit and a Great Pair of Heels, an autobiography by Karren Brady, a UK businesswoman who became the Managing Director of Birmingham City football club at just 23 years of age. Her story is really inspiring, but I highlighted one quote in particular.

And, if you are the first woman anything, and I'm told I'm the first woman in football, then that's something to take heart from–because you have opened a door. The trick is to hold that door open as wide as possible, for as long as possible, to allow other women to march through it.

I couldn't claim to be the first woman in anything, but I know a thing or two about working in male dominated industries, and this idea of "holding open the door" really appeals to me. When we talk about wanting to get more women into tech, that's exactly what us women who are already here need to do, we need to hold open the door. We need to show that this is a fantastic industry to be involved in, we need to support those who are taking their first steps and we need to be visible so that other women and girls know that they are not alone. That they won't find themselves without female friendship. That they won't have to fight battles just to be accepted.

It is important that we point out as inappropriate the examples of sexism that we do see. However we should also take care to reassure those who might want to walk through the door that these examples are actually few and far between. Yes, sexism has been directed at me, but not often. I don't believe that being a woman has disadvantaged me in my work or career. We need to get a balance between showing that sexism is not welcome here and demonstrating that in general we work in a welcoming and friendly industry. We need to show those looking through the door that most people here are only interested in what you can do, share and contribute, and that there are great opportunities and a whole lot of fun to be had.

I was having a conversation yesterday with another developer who has had a long career in web development. We reminisced about crazy old browsers and the hacks we used to deal with them. I found myself thinking about how different it is for a new developer today, in comparison to what I needed to learn when I got started.

I started to teach myself web development before the launch of Internet Explorer 3 - the first commercial browser to have CSS support. I can also remember seeing my first image rollover and wondering what sort of magic was this that could create such an effect! The landscape was much simpler, I learned HTML and built webpages. I learned some (frankly terrible) JavaScript and added image rollovers and pop-up windows. There really wasn't much to learn, and far fewer decisions to make in terms of how to implement a site.

The industry is growing up. We have new technologies, we can create amazing applications right here in the browser. We also have discussions on process, and best practice. We have created tools that make development faster and more accurate and all of this is good. However it makes for a confusing place to start when researching any subject is likely to give you compelling arguments as to why you should try any one of four or five approaches. It can be hard even as an experienced developer to work out what is best in any situation, never mind for the beginner.

I feel fortunate that I started when I did because there was nothing to distract me from the core technologies that any developer needs to understand. If you are starting out as a front-end developer now then my best advice would be to learn HTML, CSS and JavaScript. Learn how to do things robustly in modern browsers. Anything else is a distraction from that core knowledge. Even worse, I frequently see people who are clinging to some outdated tool or framework simply because they learned that tool as a replacement for this core knowledge. Changing to something else would really mean starting again.

Over the course of my career, accepted best practice has changed many times. JavaScript frameworks have fallen in and out of favour. Our understanding of accessibility and the devices we need to support has changed. However I still write HTML, and the knowledge gained even in the early part of my career still stands me in good stead today.

Don't let yourself be distracted. Seek out high quality, modern tutorials and learn your core languages. Put yourself in a place where you are able to assess the usefulness and quality of tools, methods, frameworks and libraries. Use those tools lightly, always with an eye for whether they are still the best approach as you begin a new project, and your core knowledge will enable you to keep up to date and fresh in what you recommend and use.

There are few occupations that are as open, where the barrier to entry is as low as it is in web design and development. If you have the ability, and are willing to learn, you can get started without a formal education or having to pay for college courses. Most of what you need to know can be found free of charge online.

Likewise, if you are good at what you do you might like to write articles and books, speak at conferences, be included in discussions on subjects. To get started all you need to do is start publishing your ideas somewhere, or offer to speak at small events, and other offers will start to come in.

In this industry we don't have to wait until the "powers that be" recognize our talent, we can put ourselves out there, and we have the skills and tools to do it.

When I have been asked to speak at a conference it is usually because the organizer has read an article of mine somewhere and feels the subject would be a useful inclusion. If I am asked to write on a subject it is frequently the result of posting something on my blog. That chain of events goes back over ten years to the articles I used to write on my personal site. Each article, book or slide deck leading to other offers, leading to new opportunities. You have to start promoting yourself, by producing good quality content, before people will automatically think of you as associated with a subject.

My husband and company co-Director Drew McLellan publishes the 24 Ways website in December each year. Many of the authors this year were new to the site and most of those new authors wrote for the site because they approached Drew with a great idea. So don't sit around and wait to be asked if you have great ideas to get out there. Publishers and conference organizers are usually more than happy to hear from people with ideas.

Get writing, get speaking, contact sites that publish articles and tell them your ideas. Contact the organizers of events and tell them what your talk will bring to the event. Don't wait for someone to do it for you, as that really isn't the way things are done around here.

Almost 10 years ago I wrote a blog post entitled It doesn't have to look the same. In which I said:

Different is not wrong, this is the web, a dynamic medium where we have no control over our user nor should we want to have. By building sites that separate style from content we are free to display the same pages in as many ways as our imagination will allow. We can have bells and whistles for the new browsers, we can have attractive and readable designs for the version 4 browsers, we can display the content legibly for older browsers, devices that do not support CSS.

I was writing about Version 4 browsers - the versions of Netscape and Internet Explorer released in 1997/98. In particular I was speaking about Netscape 4. A browser with such a crazy implementation of CSS that absolutely positioned elements would lose their position on resize, form elements would become unusable with CSS applied, and in which CSS didn't work at all if JavaScript was turned off. I was explaining to my clients why serving this browser a simpler layout was a good thing, as it was technically incapable of displaying a modern CSS layout, and for the most part they agreed. I was frustrated when I wrote that post because the excuse many people were using for ignoring web standards was, "but it won't look the same in Netscape 4."

It is now 2012, and still I hear the same argument for not using CSS3, for not taking advantage of all that has been developed over the past ten years. Yet I think there might be a light at the end of the tunnel. A way to squash the idea that websites need to look the same to everyone once and for all. Old browsers will always be with us, there will always be people who don't upgrade, won't upgrade or have computers so old they can't upgrade. However, the increase in "responsive design", websites that adjust themselves according to the capabilities of the device they are viewed in, means that the average person will become used to the fact that websites don't look the same on all devices. It will become obvious to them that their phone has different capabilities to their desktop at work, and that the site responds to that. It's then far easier to explain that when they view the site on that ancient PC in the library, that runs IE6, and it looks plainer than on their top of the range laptop - that's just the site once again responding to what it is being viewed in.

Even our most non-technical of clients is likely to have experience of seeing a website on a phone or tablet, and we can use that to explain a one web approach to development. An approach that serves a good experience to everyone, no matter what the capabilities of their browser or device. Yet doesn't attempt to provide an identical experience, as that simply isn't possible.

Towards the end of 2011 there was a lot of, sometimes angry, debate about how we speak to each other online. How should we criticise and point out bad advice without offending and hurting people? Time and time again people confuse being kind with being uncritical, as if the only positions are to accept everything as lovely or make personal attacks with no explanation of what the actual problem is.

Critiquing something on Twitter is likely to end up with hurt feelings. As a commenter on Sarah Parmenter's post on the subject pointed out, it is similar to being with a group in a pub, and hearing something you disagree with so standing on your chair and shouting, "THIS PERSON HERE, IS AN IDIOT!", sitting back down and continuing your chat. Most of us would agree that is not a constructive way to behave - even if the person attracting this treatment was wrong.

I want to encourage a culture of argument and debate, that takes the web and technologies forward. A culture that takes everyone's view as important. A person who has only been in the industry for a year may well have insights that those of us who have been around a very long time do not have. I can remember CSS being introduced, and debating the merits of using it instead of font tags, how much of my thinking is clouded by our history? That said, those of us who have 10+ years of web development experience, by way of that, have insights into a wider range of projects and problems that newer folk do not have. We can seem stuck in our ways when we point out potential issues - but our advice is tempered with experience.

We move things forward by listening to each other, and arguing our various viewpoints to bring new methods and ideas into being. When we argue however we need to remember that there is a real person behind each email, behind each Twitter message, behind each keyboard. That person may have strong ideas and opinions, but might also be having a tough day and wording their thoughts badly. Or have little experience in arguing a point of view and so come across aggressively. By being kind, we prevent people becoming entrenched in their positions, and constructive debate can occur.