Emily Lewis

Emily Lewis is a freelance web designer with a passion for semantic HTML, CSS, usability and accessibility. She writes about web design and standards on her blog, A Blog Not Limited, and is the author of Microformats Made Simple and a contributing author of the HTML5 Cookbook. She's also a guest writer for Web Standards Sherpa, Script Junkie, .net Magazine and MIX Online. Emily speaks at conferences and events, including SXSW, MIX, In Control, Voices That Matter, New Mexico Technology Council, InterLab and the University of New Mexico.

Emily has a twitter account, too, @emilylewis.

Published Thoughts

Project delays. They are simply a reality. Sometimes the client changes requirements. Sometimes a server problem becomes a time-suck. Sometimes a bug gets the better of a developer.

What isn’t a reality is that a project delay equals an angry or lost client … as long as you honestly communicate with that client.

When a client wants to make changes that will affect the project scope, it is my responsibility to tell them that. It isn’t always about saying “no,” it’s about saying “yes, but this will affect the timeline and budget.” When a client is delayed on their tasks, it is my responsibility to remind them how it will affect the timeline. When these things happen, I’m not doing my job if I pretend that the project will still launch when we originally planned.

It isn’t easy to say “no,” or “yes, but …”. It isn’t easy to inform a client a project will be delayed. Sometimes clients get (initially) upset. But I guarantee they will be really angry when they find out, a week before launch date, that the project is going to be delayed, just because no one wanted to tell them about the realities.

Honest communication is part of my job. It not only shows respect for the client and project, but respect for my own business. I want my clients to trust me, even if what I have to tell them isn’t the best news. Trust and honesty build goodwill, even amidst a project delay. And goodwill, combined with delivering a great final product (of course), means referrals and repeat business.

Working with truly talented people is something I’ve always wanted in my career. Like playing tennis with someone who is better than me, working with someone who knows more and can do more raises my game. And few things are more inspirational to me than witnessing (and being able to contribute to) great work.

But talent doesn’t trump a bad attitude or inconsistent work ethic.

No matter how skilled someone is… no matter how incredible their final work is… no matter how great their technical reputation is… If that person is an ass, I don’t want to work with them. If that person can’t follow through, I won’t work with them.

True talent may be rare, and it is unquestionably an asset to any endeavor. But someone I can count on, who works well with others, is invaluable.

Last month, I was checking out the #eecms Twitter feed for updates about ExpressionEngine, and I saw an update from Amy Witty who was trying EE for the first time:

And shortly after, she posted an update that made me remember my first time with EE:

Learning EE is challenging. Learning anything new is challenging. It’s a frustrating process and it can be hard to ask for help, especially as a newbie. Which was why it was so gratifying to see the EE community show it’s true colors in response to Amy’s #eecms updates.

After her first “frustrated” tweet, several folks chimed in to offer support:

And it just continued from there. It’s still continuing as I write this. From issues with her initial install to her ongoing development, the #eecms community has offered Amy support, resources and advice. And Amy has her first EE site up and running:

If you follow me on social networks, you know that ExpressionEngine is a major focus for me these days. The reasons: 1) I’m co-host of EE Podcast, so I have to be focused on EE and 2) it’s my CMS of choice now that I’m working for myself.

But this isn’t why I highlight this story. I share this story because it reminds me of the best of the web industry.

I learned how to be the web professional I am from my colleagues; my community. Sure, I got the “piece of paper” certifying for the uninformed human resources recruiter that I’m “qualified” for my job. But what I do every single day is a result of people sharing information, and me taking the time to test that information.

This cycle of sharing and learning is one of my favorite things about being a web professional. When I started on the web, I learned by reading blog posts and tutorials. 13 years later, I’m growing by reading blog posts and tutorials and Twitter and Facebook. We’re still sharing, and we’re still learning.

I love the story of EE and Amy. It shows how a community can help an individual learn and grow. And it shows how individuals of that community can be reminded of the importance of being an active part of an community.

I’m not an “early adopter.” I don’t get excited about gadgets, phones, computers or even new software. It takes me forever to make a decision about what to buy if I need a new tool, and even longer to actually make the purchase. New techniques are interesting, but I always take (probably too much) time to experiment before I’m “convinced.”

But damn if I don’t grab my username immediately upon hearing of any new service.

I love project management. It is a huge part of my freelance business. In fact, it’s probably more important than any other thing I do for my clients and projects (and sanity).

At any given point, I usually have at least two client projects I’m working on. Combine that with my “personal” projects and just running a business, there seem to be a million details I need to keep track of every day. While I’m a naturally organized person (with a freakish passion for to-do lists), strategic project management is the only way I’ve found to ensure that everything gets done on time and to the best of my ability.

I think that at least 50% of effective project management is tied to the person, and their internal ability to organize, collaborate and communicate. Some folks just inherently make great project managers, and some don’t. But that other half of project management, depends on tools. During my almost–two–years of being self-employed, I’ve found some great ones that I simply could not live without to manage the projects in my life.


I use Basecamp for all of my client projects, as well as for running my business. The standard features of messages, to-do lists, calendar and files are great. My clients appreciate having the big picture view of a project, while I couldn’t live without the small picture view Basecamp provides.

But what I really love about Basecamp are templates for to-do lists and projects. Each client project has many of the same tasks and milestones as other projects. Rather than creating a project from scratch each time, I have a handful of project templates that I use to get started. One, for example, is setup with milestones, messages and to-dos relevant to an ExpressionEngine build.

When I start a new EE project, I use that project template and in less than a minute, I have all of the core to-dos and milestones in place. The project template also includes the introductory messages I send to the client. It only takes about 10-15 additional minutes to add to-dos and milestones that are unique to the project.

For repetitive tasks that involve several steps to complete, I rely on to-do list templates. For example, when I ran Webquerque, every month we had an event. There was a ton of work involved to bring an event to life, but it was always the same tasks every time: pre-event promotion, venue coordination, A/V equipment prep, etc., etc. So each time I began work on a new event, I would use to do list templates to get my lists for that event ready … in about five minutes.

Aside from all the time I save, these templates are invaluable for me to keep track of details and nuances. Whenever I realize I’m missing a step in a process, or even if I find areas I can trim, I update the templates and they are ready for my next project. I don’t have to think. I know the templates represent my current process with all of the detail necessary.


For time tracking, billing and expense management, I use FreshBooks. It’s not too much different than some of the other online billing management tools like FreeAgent and Harvest. But it has just the right features for me.

The dashboard is solid, giving me high-level views of paid/unpaid invoices, expenses and hours. The time tracking is simple, and I love that my clients can see hours logged on their project whenever they want. FreshBooks also handles invoices in a way that allows me to selectively charge Gross Receipts Tax for my in-state clients (thank you New Mexico Taxation & Revenue), but not my out–of–state clients.

In addition to managing my time and money, FreshBooks has been invaluable in helping me assess my project budgets for hours, which has led to much more accurate estimating.

And my last favorite thing about FreshBooks is the ability to set up recurring expenses, such as rent, internet and the monthly fees for services like Basecamp and FreshBooks.


I use Shoeboxed for expenses that have paper receipts. It is a unique service: You mail in receipts, Shoeboxed scans them, enters the amount and payee, and even categorizes the receipt using tax categories. Prior to Shoeboxed, I did all of this manually and it took forever. Just scanning my receipts so that I could keep digital copies is hours upon hours of work. But I also had a (bad) habit of leaving my receipts and expenses until the end of the year, so getting my tax information ready took me days. It was miserable.

Now, I’ve totally got my expense management under control. I mail my paper receipts in to Shoeboxed each month. Once they are posted, I review and make sure everything is correct. Then I export the expenses for the month from Shoeboxed, and import them into FreshBooks which gives me the big picture view of my expenses in relation to income.

That’s it. Takes about 30 minutes a month, probably less. And I’m 100% ready come tax time.


The last service I couldn’t live without is Gmail. It is my one and only email client, and I manage all of my various email addresses and inboxes with it. One of my favorite features of Gmail is labels. Every email that hits my inbox is automatically assigned a label (via filters), so I never have to worry whether a communication has been properly labeled for my organization purposes.

I also use fairly detailed labels, as well as nesting, to keep communications organized for easy retrieval and reference. For example, I have a label for “Freelance,” and nested within that are labels for each prospect or client I engage with. Similarly, I have a label for “Writing,” with nested labels for each publication I write for.

The other Gmail feature I love and, frankly, owe much of my productivity to is the Priority Inbox. This setting divides my inbox view into three sections: Important, Starred and Everything Else. With just a few hours of use, Gmail starts "learning" which of my communications are important to me, and those land in the Important section.

For me, Gmail is trained to treat all milestone notifications from Basecamp as priority, as well as event reminders from my calendar. These are the emails that are time sensitive and, this way, I never miss them.

The Starred section, meanwhile, is used for emails of purchase receipts, such as from Amazon. So, when I do my once–a–month expense management, I check the Starred section of my inbox for any business expenses that should be entered into FreshBooks. And when I balance my personal checkbook each week, I also refer to this section of my inbox for any personal expenses that need to be tracked.

Then, when I’ve processed all of the email receipts in the Starred section, they each get a label (Personal/Finance/Receipts) and archived in case I need to reference them in the future.

After that, all that is left is Everything Else. I reference this portion of my inbox for personal communications and emails that don’t need to be addressed immediately.

I get writer’s block fairly often. In fact, as I’m writing this, I have writer’s block. I’ve been thinking about this pastry box contribution for over a month and … nothing.

I’ve tried all the tips for overcoming writer’s block, from doing writing exercises to keeping self-imposed deadlines. They don’t typically work for me. I’ve tried shifting focus to something else, listening to music, reading, pretty much anything. Nope, that usually doesn’t work either.

To be honest, I don’t know what “works” other than time and, for me, playing the mental game of figuring out the source of my block. And sometimes, when the deadline is looming, the only thing to do is write something, anything, and move on. Thanks for reading my something ;)

When I decided to work for myself, a part of me envisioned all the extra free time I would have. Two years into it, I definitely don’t have more free time. I’m working harder than I ever have, and I’m involved in more projects than ever before.

I often work long hours. I don’t typically take a traditional weekend off. I sometimes even work holidays. It isn’t exactly what I expected. It’s actually better.

I’m more productive than I’ve ever been with work. I never responded well to a Monday–Friday, 9–5 week. So much of what I do is creative in nature, and sometimes I just can’t force it. Rather than sitting behind a desk, wasting hours feeling frustrated and stagnant, I now get chores done, read a book or go for a walk. And because I work from home, my office is there when the productivity bug strikes.

Not only can I work when I want, I work where I want. Sometimes it’s the local coffee shop. Sometimes it’s the hotel room when I’m at a conference. Sometimes it’s my sister’s house in Charlottesville or my best friend’s condo in Seattle. I have freedom to go where I want and still be responsible for my business.

My days feel more balanced. I wake when I want (or, rather, when the cats want to be fed). I have time to exercise and get outside before I even turn on the computer. I have weekly appointments that I don’t have to book months in advance, because I’m available the middle of the day. I bypass crowded grocery stores because I can hit Trader Joe’s when no one else is there.

No, working for myself, I don’t have more free time. I have more quality of time.

I don’t always have the pleasure of working on projects where I get a chance to learn something new. This isn’t tied to freelancing. I remember it was like that with every single one of my previous employers. It’s just a simple truth that not every project is innovative or challenging.

That doesn’t diminish my desire to learn. In fact, it probably makes me more inclined to try a new technique or software, if only to stimulate my creativity. But if the project doesn’t require it, I find it hard to justify a higher project cost or longer timeline just so I can learn something new.

This is why I write. This is why I co-host EE Podcast. This is why I give presentations.

Whether it was writing for my blog, a publication or even a book, I never started with all the knowledge I ultimately shared. The process of writing is how I learned (and even mastered) subjects. Researching, creating examples, finding ways to convey information simply … this process of teaching someone else teaches me first.

It’s even more true with the EE Podcast. The subjects we cover are frequently those I have little to no experience with, and the guests we interview are far more experienced with ExpressionEngine than I am. And I like it that way. It’s like playing a sport with someone better than you: it makes you better. All the research and prep we do for each episode, combined with the actual interviews, give me at least four dedicated hours a month of focused EE education.

Giving a presentation, too, is a learning experience. Of course assembling the deck and talking points reinforces my knowledge, but it’s the attendees who teach me the most. After presentations, I always get great questions from attendees, and I particularly love the ones I can't answer. These give me a broader perspective of my topic, as well as a reason to learn more about the subject for next time.

All of this, plus my client work, means I’m ridiculously busy most of the time. Yet, for me, it is worth it on so many levels. Writing, podcasting and presenting has helped me build my reputation and are, basically, my main avenues for marketing myself. Sometimes I even get paid for it (woo!). But most of all, I pursue these endeavors as a means to satisfy my personal desire to learn and to do my job better and faster.

I recently did a Q&A for .net magazine (June 2012, issue 228), answering a few reader questions. One person inquired about my experience going full-time freelance. In my answer, I discussed how I'd always been fearful about going out on my own because of the sales process.

Having spent the majority of my career in the marketing and sales departments of various employers, I hadn't seen much in the way of “sales” that appealed to me. Particularly the aspects of it that always struck me as sleazy.

I just couldn't see myself being that kind of person. Pushy, fake and even dishonest. I also couldn't see myself as the confident “people person” I thought you had to be in order to be successful with sales, sleazy or not.

My first year freelancing, I avoided sales. And, fortunately, I was able to get away with it… but only for so long. This year has been slower for me so far, and that means I've had to take more action in terms of generating new opportunities. Ick. Even writing “generating new opportunities” feels like the kind of sales-speak that bothers me.

But this is the problem. My perception of sales.

Thanks, in part, to speaking with Brad Parscale on the EE Podcast, my perception is changing. I'm not only learning to embrace the sales process, but I'm learning to re-think what sales really is. And, even better, my business is benefitting from this shift.

I'm discovering that true sales is about the prospective client and the fact that I can help them achieve their business goals. It's about the need to establish a relationship so they feel secure to trust me with their business. It sounds like common sense, I know, but re-defining sales from this perspective has been key for me.

I'm now spending more time with prospects, not only trying to learn more about their project but also building a relationship. For example, I created a project questionnaire that I ask all prospects to complete. It has been a fantastic tool to give me a big- and small-picture perspective of the prospect and their needs.

The questionnaire has also impressed several prospects (one of which is now a client), who appreciate the more professional fact-finding tool than a simple email. And, for those who don't want to fill it out, the questionnaire has served as a red flag for prospects who may not be a good fit for me.

Beyond the questionnaire, I'm also taking more time to research prospective projects and clearly define what I can deliver before following up with a call. I take more time to ask questions about a project that the prospect, perhaps, didn't address or didn't consider.

This preparation, though a bit time-consuming, is worth it. Every single time, the prospects I speak with are impressed with how well I know their project and how prepared I am to deliver. Even for those prospects who don't become clients, I've left a positive and professional impression that could lead to work in the future or a referral.

I won't lie and say that I like all the extra work this now involves for me. I'd much rather write HTML and CSS all day long. But there is a rhythm to it, and it is nice to constantly fine-tune my communication skills and materials.

Also, by investing in this upfront time with a prospect, when I do win a project, I'm so much better prepared to execute and my estimates are much more on-target. I've also found that the clients I've earned with this considered sales approach are more committed to their projects and invested with the vision we've come up with during the sales process.

What I realize now is that if you are doing sales well, you don't even think of it as sales. It's building relationships, understanding a client and a project, and demonstrating you can deliver. Nothing sleazy about that.

If there is one thing that is guaranteed to damage — if not doom — a project, it's ego.

Consider the project manager who hoards information because only she knows what's relevant to other team members and when. Or the new developer who just joined the company and wants to change established procedures because he knows how to do things better. Or the designer who won't consider critical feedback because she knows what she delivered is exactly what's needed.

I've worked with all of these types of people. In fact, at stages of my career, I've even been these types of people. At those times, I thought I was being passionate or committed to the project. But the truth of it was, I was letting my ego drive. And my ego wasn't interested in considering anything external. Because that's how egos are.

Egos don't care about requirements, timelines, budgets, user needs, limited resources or legacy systems. They don't care about other opinions or ideas. They are roadblocks to everything essential to making a project successful, especially compromise, collaboration and communication. And, worst of all, ego keeps you from growing. Your ego won't let you learn something new. Or see a different perspective. Or even get inspired.

Knowing this is so much easier than doing something about it, though. It can be hard to distinguish your ego from your opinion (or passion or commitment). But it's just as important to hone that skill as it is to keep up with changing technologies, because employers want someone with a point of view who is open to other points of view. Clients want to work with an expert who listens to them and considers their realities. Colleagues want to work with someone who has great ideas and welcomes others'. All of us want to be inspired, but not if it means tolerating assholery.

One of the simplest ways to keep ego in check is to take your time. I've learned to never respond immediately to a change request or a demanding question. Ego is always ready with the first answer, which is rarely the most thoughtful one. A little bit of time can make the difference between an ego-driven reply and a well-considered response.

It also helps to keep your focus on what's important. For example, if I feel myself getting defensive when a client wants to change a design, I try to shift my focus back to the client and what he needs and wants. This doesn't mean sacrificing my expertise or the project goals. It simply opens me to communication, which is the gateway to a successful project and a happy client who wants to work with me again.

I often find myself in absolute awe of my colleagues' work. But when I was still new to web development, it wasn't just the work I was in awe of… it was the people too. I put those folks on pedestals. And the fact that I only “knew” these people online made it easier to idealize them and even hold them to standards of perfection.

It wasn't until I attended my first conference that I realized how this mentality was hurting me. I was terrified to introduce myself to people I admired and genuinely wanted to know. And because I believed these people were somehow better than me, I wasn't pursuing opportunities to challenge myself and be a better designer and developer.

Over time, I also began to suspect that this mentality hurts the people being idealized. The negative tone in our industry — that doesn't seem to be getting better — can't be blamed entirely on the easy firing off of casual insults on Twitter. I wonder if it's because of idealization and expectations of perfection. When someone is flawed, or makes a mistake or simply doesn't meet someone else's expectations, why is the response anger and name-calling?

Maybe it's my age and the glorious maturity that comes with it, but today, I'm more interested in connecting with my colleagues than putting them on pedestals and judging them when they fall off those pedestals. It not only makes it easier for me to understand them, their work and their decisions, but it makes it easier for me to have meaningful relationships with people I admire. And those relationships have given me far more — both professionally and personally — than my youthful idealization ever did.

One of my favorite parts of developing web sites is working with markup. HTML fascinates me because it is deceptively simple. How it impacts assistive technologies, browsers and devices is an ongoing journey of education. Understanding the semantics is challenging, yet satisfying, like the New York Times Sunday crossword.

And my fascination has only intensified with HTML5.

So I find it particularly frustrating when I read articles that poo-poo the value of semantic markup, or whine that it's too hard to figure out whether to use <article> or <section>, or complain that something in the draft HTML5 spec isn't where it "should" be.

If semantic markup and HTML5 is confusing to someone, it only suggests to me that someone needs a bit more experience and knowledge. My first site with HTML5 took at least three times longer than if I'd stayed with good old XHTML Strict. But this experience didn't leave me believing that it was pointless to attempt writing more semantic markup. That's just how it goes when learning something new. Not acknowledging a learning curve and blaming the technology doesn't do anyone any good.

And let's not forget, HTML5 is a draft. Even once it's formalized, that doesn't mean vendors are going to magically support everything all at the same time. In our industry, this is just how it is. Complaining won't change that, but it certainly could discourage other people from learning something new.

I get that it's human nature to bitch. I'm a pro at it, myself. But when it comes to helping move things forward, bitching is at the bottom of the list. At the top of the list: education and openness. That's what has helped me move forward in my career.

As I build more sites with HTML5, I continually get better and the semantics make more sense to me. Through this process, I'm becoming a craftsman (craftsperson? whatever …). I'm a better developer because of the struggles I had learning and the challenges of staying up–to–date with a draft spec. But the best part is I'm differentiating myself from the folks who don't care to master the craft, which means more and better opportunities for me.

There's this home improvement show called Holmes on Homes, where a contractor visits a home that has been plagued with problems like electrical issues or roof leaks. The contractor, Mike Holmes, inspects the house from its foundation to its insulation and identifies the culprits of the issues.

99% of the time, the reasons for the problems with the home is that the original contractor simply did a shitty job. Sometimes, the shitty job can be blamed on money: the home owners didn't want to spend the money, so they hired an unlicensed contractor. In those cases, you get what you pay for.

But most of the time, the shitty job comes down to a lack of fundamentals. Over and over, Holmes points out areas where the original contractor did the job without following best practices or even relying on fundamental techniques and materials.

And 100% of the time, these homes look great. They appear grand and fancy, with all the modern amenities.

From the first episode I watched, I immediately drew parallels with the web industry because I don't think the majority of practitioners in our field focus on fundamentals. In fact, I'm not even sure the majority of practitioners even know the fundamentals. And this lack of knowledge and/or execution is damaging our industry.

Consider the scenario I currently find myself in: I have a client with a custom, in-house-built CMS who needed a design and front-end development for their CMS templates. Straightforward enough. That is, until I got into the templates.

The HTML was a sea of nested (and nested and nested) <div>s, inline CSS and <span>s for headings, just to name a few offenses. The linked CSS was even worse, bloated with unused selectors, overly-specific selectors and redundant styles.

These templates weren't developed years ago … not even a month ago. December 2011. By a developer who says he has “many years of experience”.

While I will hold my tongue regarding the aforementioned developer's actual "experience," this situation is far more common than I think people realize. Especially if you find yourself insulated by the web standards bubble, where we all talk to each other and buy each other's books and read each other's blogs and work on projects where standards are a given.

Amongst "our own" we think everyone is passionate about semantic markup or that everyone cares about progressive enhancement or even that everyone already knows how to build with standards. But this, sadly, isn't the case … especially in an industry where skills are overwhelmingly self-taught.

Outside the web standards bubble I like to reside in, the web seems like the Wild West. Standards? What standards?

If a <span> gets the job done, who cares about semantic markup? If you can't get your specificity right, use !important and use it everywhere! If text won't indent, throw five <div>s around it and give each padding! If a column won't align, put it all in a <table>. Who cares if it doesn't work if JavaScript is disabled? Who cares if a blind user can't turn off the audio that started playing on page load?

Pedantic? Perhaps. But though these things may seem small, they are actually a big deal. For me, as the front-end developer who has to work with that kind of crap, I get frustrated and I tend to hate my job in those moments. But that hassle isn't my main concern. It's the cascade effect this kind of development leads to.

It's now a big deal to my client, who has to pay me more because working in such convoluted markup and CSS takes more time than the alternative. It's now a big deal to that developer, who is has a very unhappy employer.

But even worse, it's now a big deal when my client talks to other prospects or considers future work. Because, from my client's perspective, he's paid two developers and still doesn't have a solid system that meets his needs and is easy to maintain.

No, it isn't a bomb that goes off to destroy our industry. It's a trickle of water that slowly (but surely) erodes opportunities, trust and perceptions of value.

And let's not forget, it just isn't possible to build something awesome on a shitty foundation. Whether it is a house or a web site, the latest techniques and trends require a solid understanding (and execution) of fundamentals.

Take responsive web design. If you don't understand the basics of the box model and how an element's true width is determined, good luck getting a fluid design working before you bang your head so hard against your desk you pass out.

Fundamentals are important. Not just to sate the pedants and standardistas, but to ensure that we all have great opportunities for work. To ensure our clients feel satisfied with their investment and remain positive about future development with people they can trust. To ensure that our field is respected so that we can all earn pay commensurate with our value.

I'm hopeful efforts like Move the Web Forward will help slow the steady stream of crap that plagues our industry. The project offers a variety of fundamental ways designers and developers can get involved to make our industry (and the web) better. Please go check it out, and then spread the word far and wide.

Pretty please? Because I want to dream of a day where I never again encounter 20 nested <div>s inside a <form> that encompasses everything between the opening and closing <body> tags, all of which styled with inline CSS.