Search Site

Subscribe

Demystifying Web Development for Clients

Your browser doesn't support HTML5 audio, and won't play Demystifying Web Development for Clients. You can download this episode to play on your preferred media device, or you can read our transcript.

Summary

Do your clients value the work you do and understand how it supports their business goals? If you don’t know (or the answer is ‘no’), then you need to start communicating better! We continue our client-friendly series exploring how technical web terms create a barrier between ourselves and our clients. In this episode, we tackle front-end development, explaining the technical terms and acronyms in ways non-web folks can understand!

Tags

Sponsored by

Episode Transcript

CTRL+CLICK CAST is proud to provide transcripts for our audience members who prefer text-based content. However, our episodes are designed for an audio experience, which includes emotion and emphasis that don't always translate to our transcripts. Additionally, our transcripts are generated by human transcribers and may contain errors. If you require clarification, please listen to the audio.

Show Notes

Preview, Lea Alcantara: The point of this episode is we want to make sure that we are discussing technology in the context of their business and what our clients actually relate to. And essentially reminding all of us that’s why they’re paying us to code. The code is just the…

[Music]

Preview, Emily Lewis: …Means to get a business goal met.

Preview, Lea Alcantara: Exactly.

Lea Alcantara: From Bright Umbrella, this is CTRL+CLICK CAST! We inspect the web for you! Today Emily and I are going to talk about demystifying web development for your clients. I’m your host, Lea Alcantara, and I’m joined by my fab co-host:

Emily Lewis: Emily Lewis!

Lea Alcantara: This episode is brought to you by mithra62’s BackupPro, a complete backup solution for WordPress, ExpressionEngine 2 and 3, Craft, PrestaShop and concrete5. We use this one ourselves for some of our client sites. It’s insanely customizable and includes automated backup integrity, eight built-in storage locations, console routing. Basically, Backup Pro was built to make disaster recovery as painless as possible. Just visit backup-pro.com to get started.

Emily Lewis: So today we are resuming our Demystifying Web For Clients series.

Lea Alcantara: [Agrees]

Emily Lewis:Our first episode, we tried to talk about web design and the terms involved in web design from a non-technical client/human-friendly person that do. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: And so this episode we’re going to take that same approach to the topic of web development, so before we actually get started we do recommend that if you haven’t listened to the first episode, go do that. [Laughs] There are a lot of contexts that we provided in there about the reasons and the value for taking this approach that I think is important to listen to before you dive into this episode with us. So we’ll include that link in our show notes.

Lea Alcantara: Yeah, absolutely, and just to reiterate why we’re even doing this series, it’s really important to take the time to educate our clients. I think one of the most important skills that we have isn’t necessarily even our coding skills or our design skills, but how to communicate the value of those particular aspects of our business in terms that the people who are signing the checks can understand.

Emily Lewis: [Agrees]

Lea Alcantara: And we want to sure our clients are comfortable from the very beginning of all of our projects because that sets the tone for how we communicate throughout the entire thing in the first place, right?

Emily Lewis: Yeah.

Lea Alcantara: I mean, it’s not setting expectations.

Emily Lewis: Exactly. I mean, and this is all learned the hard way of not taking the time to do this and having surprises come up in terms of a client saying, “Well, I thought I was going to get this or why didn’t this happen?”

Lea Alcantara: Right.

Emily Lewis: Taking the time to make sure they understand what we are saying and we understand what they’re saying pretty eliminates those sorts of surprises and that, of course, means you don’t have disappointed clients.

Lea Alcantara: Right. And I mean, the impetus of all of this, too, beyond the fact that they understand what you’re saying and you’re understanding what they’re saying is putting it all in context to the business needs, right?

Emily Lewis: [Agrees]

Lea Alcantara: Like the point of this episode is we want to make sure that we are discussing technology in the context of their business and what our clients actually relate to and essentially reminding all of us that’s why they’re paying us to code.

Emily Lewis: [Agrees]

Lea Alcantara: The code is just the…

Emily Lewis: …Means to get a business goal met.

Lea Alcantara: Exactly, exactly, and so this series in this episode we’re trying to make sure clients understand our value, the work we do and how we communicate.

Emily Lewis: Yeah. I kind of think it’s like one of the things I find frustrating, even though I’ve been doing this for 20-some odd years, most people I meet, I have like exterminator come to the house or a landscape contractor and eventually they ask what I do and I say, “Oh, I make websites,” and they’re like, “Huh.” [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: They just don’t even get it.

Lea Alcantara: Right.

Emily Lewis: But if I were to say, “Oh, I’m a car mechanic,” people know what that is and they understand it’s craft, that it’s a specialized skill, and they understand that actually the value of the mechanic and why you get your money’s worth when you do or don’t pay for mechanic’s expertise.

Lea Alcantara: Right. Because there are all these types of nuances in regards to that as well and I feel like using the car mechanic or car analogy even is pretty good because it’s actually pretty complicated how a car works.

Emily Lewis: Yes.

Lea Alcantara: But we all need to have our car serviced at some point. [Laughs]

Emily Lewis: Yeah.

Lea Alcantara: And we don’t need to necessarily know exactly every single nuance on how that works, but people should still be able to communicate back and forth to understand why something is not working and why you’re paying for them to fix it or not, right?

Emily Lewis: Yeah, especially I love the car analogy for this because I have a car and it’s almost 20 years old.

Lea Alcantara: [Agrees]

Emily Lewis: But when I first got it, brand new car, it made this noise when I got over a certain speed.

Lea Alcantara: Right.

Emily Lewis: And I could not communicate with the mechanic for the life of me for like three years, different mechanics, different places, trying to get them to hear it and understand it.

Lea Alcantara: Right.

Emily Lewis: And it ultimately never got solved and I just tolerate this noise. [Laughs]

Lea Alcantara: Right. And we’re trying to avoid that for web design.

Emily Lewis: Right.

Lea Alcantara: Because there are a ton of clients who go to us with a particular issue or problem and something needs to be solved, but because there is a language barrier of understanding, then things don’t get resolved or problems that they weren’t actually asking you to solve were solved instead while this niggling issue is still around, right?

Emily Lewis: Yeah. And also if we don’t take the time to communicate and try and speak in terms that our clients can understand, it contributes to misperceptions about our industry.

Lea Alcantara: Oh yeah.

Emily Lewis: People not understanding what we do or why we do it or having a perception that web developers are hard to work with, you can’t count on them, they do stuff. Do you know what I mean?

Lea Alcantara: Yeah, yeah.

Emily Lewis: So we hear it all the time, clients were coming to us from a bad experience.

Lea Alcantara: Yeah, absolutely. And I think one of the issues why that happen is that there are just so many assumptions that people like our knowledge is common knowledge and it really is not. Just to give you a real world example, very, very, very recently, we had a client kickoff, and during that kickoff, we made sure to ask her if there were any terms that we were using that were unfamiliar with. The thing is like even when, for example, Emily and I are very conscious of this issue, hence, why we’re doing this series in the first place, and yet we still throw out these terms because it’s our language without even thinking, right?

Emily Lewis: [Agrees]

Lea Alcantara: So it’s really important to ask your clients or your prospects if anything that you’ve said needs clarification.

Emily Lewis: [Agrees]

Lea Alcantara: And so with this super recent kickoff, it was just really interesting when we mentioned that, she did bring it up.

Emily Lewis: [Agrees]

Lea Alcantara: There were terms that didn’t make sense to her and they were actually front-end terms, which is the point of this episode.

Emily Lewis: [Agrees]

Lea Alcantara: And I also want to point out that this particular client is a super smart financial litigator, but she didn’t understand what HTML and CSS actually meant.

Emily Lewis: [Agrees]

Lea Alcantara: And that’s the building blocks of the web, right.

Emily Lewis: Yeah.

Lea Alcantara: Like we just assumed like everybody knows what HTML and CSS is, but that’s just really too far into our heads to make that assumption because not everybody understands what that means. They might generally understand that means, “Okay, I guess they’re talking in the context of the website so I guess these acronyms mean website related.”

Emily Lewis: [Agrees]

Lea Alcantara: But she didn’t actually quite understand, but because we pointblank asked her if there were terms she didn’t understand and perhaps also because of the type of client she was, she’s a financial litigator, she was comfortable pointing this out and asking for specifics, but not all clients are like this.

Emily Lewis: And I think that’s important to underscore, just because your client didn’t say that they don’t understand does not mean that they understand.

Lea Alcantara: Yeah.

Emily Lewis: It can be scary or intimating or who knows? Maybe it’s something she’s just not comfortable mentioning that they don’t understand something, and so we make a point of asking.

Lea Alcantara: Right. And when you do that, it sets the stage for the rest of the project. When communication is going great and then you’ll have faster calls and then there will be less versions and change requests simply because you’ve already set the tone and already set the language.

Emily Lewis: Yeah, I’ve been so pleased with this particular project because we’re literally experiencing this. We’re more efficiently using our hours because she understands what we’re doing. [Laughs]

Lea Alcantara: [Laughs] Yeah, right.

Emily Lewis: Because we took that time at the beginning to really underscore our process. We’re trying to use the same language when we hand over a deliverable so she has the context of previous conversations, and we literally are not having to do as many versions of deliverables, literally, which is great. [Laughs]

Lea Alcantara: Right, right. It’s because we’re not having to over-explain something because we’ve already set the tone at the very beginning.

Emily Lewis: [Agrees]

Lea Alcantara: Yeah.

Emily Lewis: She understands the deliverables when she gets them and doesn’t ask for things that aren’t a part of it because she understands that’s not part of that particular phase.

Lea Alcantara: Right. Right. So I think it’s really important, especially in a kickoff or obviously the entire project to make sure that you have a conversation like this where you actually ask them, “Do you understand the terms this and this?”

Timestamp: 00:10:15

Emily Lewis: [Agrees]

Lea Alcantara: And then you actually wait for them to explain it to them. Don’t talk over them. Wait for them to explain it in their words and then see if they’re correct, you know? [Laughs]

Emily Lewis: [Agrees]

Lea Alcantara: Because sometimes they might re-explain it to you because that sometimes what happens, too, like we’ve had experience where we explained, “So do you know what HTML is or do you know what this is,” and then they’re like, “Oh, I think it’s this.” Like I think we’ll talk about accessibility later on, but our other client, we realized that she didn’t actually understand what accessibility was after the conversation continued, right?

Emily Lewis: [Agrees]

Lea Alcantara: And then we had to like break in, break down the actual definition, and then she understood, right?

Emily Lewis: [Agrees]

Sponsored by

Lea Alcantara: Because it really is so important that everyone is on the same page.

Emily Lewis: Yeah.

Lea Alcantara: Now, I think it’s also important that when you’re discussing language is that it needs to be an agreed upon term between the parties that are involved.

Emily Lewis: [Agrees]

Lea Alcantara: So what I’m saying about that is that the terms that we’re going to be using on this episode might have broader meanings and I don’t want to debate specifics, because I feel like in a room full of front-end developers, there will be a ton of definitions of even what front-end development means, right?

Emily Lewis: Yeah.

Lea Alcantara: So I think the emphasis on we want to talk about front-end in human terms and that anyone can understand should be the focus of this episode and your mindset as you’re listening to our discussion.

Emily Lewis: So let’s start with just a couple of examples of how we as designers and developers or even project managers may get it wrong when talking with clients where we just get too technical.

Lea Alcantara: Right, yeah.

Emily Lewis: And even if you’re working with someone who’s in IT or even a developer, you can’t assume that they know what you’re talking about.

Lea Alcantara: Yeah.

Emily Lewis: Because they have their own set of expertise, you have yours, so take the time to get to know what their context of where they’re coming from. Don’t make any assumptions.

Lea Alcantara: Exactly.

Emily Lewis: Like for example, Angular, React, those are names of JavaScript libraries, frameworks, but not everyone is privy to that is privy to that. In fact, most of our clients wouldn’t know what it is.

Lea Alcantara: Yeah, I know.

Emily Lewis: And in fact, I’m not even completely familiar with all the nuances of libraries, and frankly, I don’t need to be to do my job.

Lea Alcantara: Right.

Emily Lewis: I don’t rely on frameworks, but our clients don’t need to be either to get the project done.

Lea Alcantara: Right.

Emily Lewis: Frankly, it’s not appropriate to throw Angular or React at a client and expect them to have any sense of what that means.

Lea Alcantara: Exactly.

Emily Lewis: That’s where you can get it wrong in throwing these names out there that maybe they’re written about a lot within our industry or talked about, but they don’t have context for clients.

Lea Alcantara: Right. And as you mentioned too, even if you’re talking to someone within IT and as I mentioned even the definition of what a front-end developer means can be a loaded thing. So just always enter a conversation with an open mind and in a helpful generous manner where you are in a teaching mode as opposed to like judgment mode as in, “What? You don’t know what Angular is?” Is that actually appropriate to the business or the project? Let’s get to that type of conversation instead.

Emily Lewis: [Agrees]

Lea Alcantara: And besides those terms, I think what we really get wrong is the acronym soup that we force clients to eat.

Emily Lewis: Yeah. [Laughs]

Lea Alcantara: So terms like — again, these are acronyms that we in the industry are used to, but no one else is like HTML, CSS, JS, SEO, RWD, HTTPS, and you might think like, “Well, I could just break down each acronym.” But doing that, it actually doesn’t explain anything. For example, telling your client, “Well, HTML is Hypertext Markup Language. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: How does saying Hypertext Markup Language actually explain that is the code that adds context and meaning to the texts and images to your site? At some point, you don’t even need to define the acronym or explain it. You just say it adds context and meaning to the text and images to your site, you know?

Emily Lewis: [Agrees]

Lea Alcantara: Don’t muddle the definition.

Emily Lewis: Yeah. And don’t throw text-sounding terms like semantics or accessibility out there. This is something that I did a lot in the early days of freelancing because semantics and like structured data is my area of expertise.

Lea Alcantara: Oh yeah.

Emily Lewis: And because my head was in it, I thought everyone understood what that is.

Lea Alcantara: Right.

Emily Lewis: And so when I would pitch to a client or respond to an RFP, I’d say, “Semantic markup and structured data,” that means nothing to them. [Laughs]

Lea Alcantara: Yeah, right, right.

Emily Lewis: Yeah. And frankly, some of these things aren’t even features, as much as it may break my heart. A client may not value semantics or accessibility unless it’s been explicitly asked of them.

Lea Alcantara: Right.

Emily Lewis: So I don’t even go into those terms anymore. They are too techie, they’re too nuanced, and it really is not something that comes up unless we’re kind of getting into the nitty-gritty of some specific business requirement for the website.

Lea Alcantara: Right, yeah. I know, I totally agree.

Emily Lewis: It kind of happens behind the scenes. They don’t ever know about it.

Lea Alcantara: So it’s just a matter of figuring out the context and not just defining terms for the sake of defining terms because it sounds cool or you’re trying to pad some sort of RFP. If you can say something in a way that actually resonates towards the goals of the site, the goals of their business, then that makes more sense, I think.

Lea Alcantara: Right, right, right. Exactly. So with all of these in mind, let’s talk about web development from that non-web/client perspective.

Emily Lewis: I have to tell a little joke that I wanted to tell you offline, but I thought maybe our listeners might appreciate this. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: So when we recorded the last episode, our listeners, if you’ve heard it, you know we’d kind of doubled down on the home building analogies and after the episode, you said to me, you’re like, “We really went HAM on that analogy.” And me, I don’t even know what that meant, but I heard HAM and we were talking and so I was like, “Ham radio? Okay, maybe, I guess. Maybe we were old school.” [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: I didn’t even know what you meant and I had to go look it up after our conversation to be like, “Oh.”

Emily Lewis: Well, yeah, but like I’m not into like the acronym speak. I’m only just now getting into emojis and stuff. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: I’m old. I feel old.

Lea Alcantara: Not with the kids are saying.

Emily Lewis: Yeah, exactly.

Lea Alcantara: Yeah, yeah.

Emily Lewis: So anyways, in honor of not going all HAM on the home building analogy, we are going to do a car building analogy.

Lea Alcantara: But please note [laughs] that everything I know about cars, I’ve learned from my husband and Top Gear/The Grand Tour, so all my analogies are based on that and I know in my mind.

Emily Lewis: And I know nothing about cars. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: So I’m trusting Lea.

Lea Alcantara: Right. But I mean, like just the overall concept, like with cars, we can go with the Ferrari or a Ford, like you could customize each car as you want and go to a higher end model from the outset or you could go find a Honda or a Ford and just go the Pimp My Ride route, right?

Emily Lewis: Right, right. [Laughs]

Lea Alcantara: So let’s talk a little bit more about web development.

Emily Lewis: Yeah, so I think web design and web development, especially for lay people, people outside of the web industry, they kind of sound like one and the same.

Lea Alcantara: Right.

Emily Lewis: And while they are very tightly related and interconnected, they aren’t the same. So web development is the process of building a website, translating all the work from that design phase into an actual interactive website that you can be on a browser.

Lea Alcantara: Right. And I think it’s pretty easy to just say that web development is the backbone of building blocks of the web.

Emily Lewis: Yeah. And often, obviously, we use terms like front-end and back-end, and those terms don’t really mean much to a regular person and even back-end got its own suggestive meanings. [Laughs]

Lea Alcantara: Right, right.

Emily Lewis: So I think what’s useful whenever I mention that I’m a front-end developer, and I do say that, that is what I am, but I find it easier than to further explain that I write the code that brings Lea’s designs to life on the web. I write the code that powers what people experience when they’re actually visiting a website.

Lea Alcantara: Yeah. And I think that makes a lot more sense than just saying front-end developer.

Emily Lewis: Right.

Lea Alcantara: And it doesn’t really make much sense to a lay person.

Emily Lewis: Right.

Lea Alcantara: And we understand again that this is a simplified explanation, but we also want to emphasize this episode that simplified explanation is okay.

Emily Lewis: [Agrees]

Timestamp: 00:19:56

Lea Alcantara: I think our industry has a bad habit of trying to explain every single nuance of web development when a client just wants to know what’s happening in each phase.

Emily Lewis: Yes.

Lea Alcantara: Again, with that car analogy, it’s like trying to explain every part of a driving car and like how pistons and the gas and the gears and engines work when all you’re trying to say is, “Press the gas and the car goes forward.” Right?

Emily Lewis: [Agrees] [Laughs]

Lea Alcantara: Don’t overcomplicate things and get to the point that you’re trying to make first.

Emily Lewis: Yeah. So I think getting a little more specific about front-end and back-end development to tie it onto the use of analogies, front-end development would be like the frames and shell of a car, like a framework, so where the seats are, the wheel, the pedals, the windows, the gear shift, and all the other features that need to be in the car. They have to exist as a structure before you can do anything to them, and just to point out, that structure is defined during design. So I don’t just start building a car, I have — what it would be — are they blueprints for cars?

Lea Alcantara: Yeah, it’s called blueprints, yeah.

Emily Lewis: So a car, you’re referencing the blueprint and you’re building that structure for it.

Lea Alcantara: Yeah, absolutely. And then the back-end development is like the gear that actually put that front-end framework to life.

Emily Lewis: [Agrees

Lea Alcantara: So that’s what’s actually drives the car and gives each of the pieces that the front-end puts together some type of functionality, right?

Emily Lewis: [Agrees

Lea Alcantara: Like a gas pedal does nothing if it’s not connected to the engine that actually powers the vehicle and moves it forward, a.k.a. like ExpressionEngine. [Laughs]

Emily Lewis: [Agrees

Lea Alcantara: The content management system, which is the back-end that powers a particular website, for example, right?

Emily Lewis: And I feel like I do want to bring up the home building analogy again in this one because I think it just further strengthens this idea of front-end/back-end and so with building a house, front-end is putting up your walls, pouring the foundation, adding the roof, whereas if we’re talking about back-end, that’s kind of the dynamic automated systems of the house, the plumbing, the electricity, the HVAC.

Lea Alcantara: Right. That actually powers the house, right?

Emily Lewis: So front-end is the structure, back-end I guess I think of it’s like your automated systems.

Lea Alcantara: Yeah, absolutely. So let’s talk a little bit about the most common of all the acronyms that we throw our clients, which is HTML and CSS.

Emily Lewis: Yeah. So HTML is my favorite part of web development. It really is. It’s probably the simplest for tech people, but it’s my favorite part. For me, it’s the foundation of a great website. If you don’t have good HTML, you’re already starting off on the wrong foot. So HTML is the language that defines your web content. As I mentioned, it’s the structure of the website. So if Lea gave me a design that had a heading and some body content and a hero image, I would write HTML that tells the browser, “This is the headline. This is a paragraph of body content. This is an image. And so on.” So essentially, the HTML is the shell of the car, the actual components that say, “What’s the hood? What’s the door? This is the door. This is the hood. This is how the car is going to be put together.”

Lea Alcantara: Yeah, exactly. Like in the blueprints of a car, too, like you’re actually pointing out what’s what in all of that.

Emily Lewis: Yeah. And I don’t write HTML just out of the cloud, like out of thin air.

Lea Alcantara: Right.

Emily Lewis: It’s from the blueprint that is your design comp that was built through the phase of design.

Lea Alcantara: Exactly.

Emily Lewis: That becomes my blueprint that I’m following.

Lea Alcantara: Yeah, exactly. And very, very closely related and important to that HTML is semantics.

Emily Lewis: Yeah. So semantics, like I said earlier, doesn’t come up much with clients, but I do think it’s important, especially if you’re maybe in a sales process where the client may be wants to understand why your agency may be a better value than another one or when you’re trying to explain to a client that the way you build HTML is a certain way and therefore, that’s more valuable for them for different business reasons. So those are mostly the scenarios that this will come up, but semantics is when you’re adding proper meaning to the proper content, so what I just described, I’m writing code that says, “This is the headline, this is an image,” I wouldn’t label the headline as an image. I wouldn’t label the paragraph as an image. They’re labeled, they’re coded to be very specific to the content that they’re containing, and the benefit, and this is what I really try and focus on when I’m talking about semantic HTML is it’s a foundation that gives our clients the added benefit.

Lea Alcantara: [Agrees

Emily Lewis: I mean, not only do you get HTML that is the structure for your website, but search engines favor semantic markup. When you use the right code to say, “This is a headline,” search engines say, “That’s a headline.” That is more important than something else on the page that’s maybe just a paragraph. Headlines tend to have keywords, so search engines can read a page and say, “That’s a headline,” that’s important information that may be factored into your ranking.

Lea Alcantara: Yeah, absolutely.

Emily Lewis: So that leaves to another acronym, SEO, that’s Search Engine Optimization, and frankly, all of our clients know what this is. [Laughs]

Lea Alcantara: Yeah, right. [Laughs]

Emily Lewis: They all do because it’s a bottom line kind of thing, and so by emphasizing that this semantic HTML helps with organic search engine optimization, that search engines’ favorite, that is a selling point for it. In addition to aiding SEO, semantic HTML is the foundation for accessibility, and accessibility, when I have to get into that with the client, it’s really just about explaining to clients that not everyone experiences the web the same way. Some people are on a slow mobile network and don’t have images displayed or some people have vision issues and don’t see a website, but rather hear it. Some people can’t use a mouse so they rely on their keyboard to use a website, and so semantic HTML is the foundation that all of these different types of people with different needs can still access the information on your website without anything special other than one standard code base.

Emily Lewis: And accessibility, it may come up. It’s probably going to come up as an issue, especially when we’re dealing with a client that is in e-commerce. There are a lot of things that need to be taken into account when building and designing an online store, but it’s also something that can be government mandated. Basically, any US — well, who knows what’s going on now, but in the past, US departments and agencies were beholden to something called the eGov initiative, which included being accessible.

Lea Alcantara: [Agrees]

Emily Lewis: And so if you worked on a site or a sub-site or micro-site or whatever for any of those agencies, you had to follow accessibility rules, but even if you’re not a government agency or you don’t have to follow these rules for some business requirement, a website that is inaccessible is a future legal issue. It is a problem waiting to arise. In the past year, there has just been more and more litigation against retailers, education, universities, entertainment like — oh I’m blanking. I think it was Disney.

Lea Alcantara: Right.

Emily Lewis: These major companies and industries are facing or have faced major litigation because their customers couldn’t actually use their websites because they were not accessible to those customers.

Lea Alcantara: Right. And when you stop and think about it, you might say like, “Why is that such a big deal?” But then you need to take a step back and understand that accessing the internet is now a human right, right?

Emily Lewis: Yes.

Lea Alcantara: This is what we’re doing right now, what we’re contributing with our skill set is a fundamental part of people’s lives, and if you’re not a part of the industry that’s trying to make sure the everyone can have access to it, there can be consequences not just your own personal ethical mindset, but financial and legal consequences as well, and large industries are being punished for ignoring these.

Emily Lewis: Penalized. I think punishment suggests that like — I don’t know. I think penalty like they knew what the rules were and didn’t follow them. [Laughs]

Lea Alcantara: Right, right. [Laughs]

Emily Lewis: So this is what you get. And I don’t want to focus too much on accessibility because honestly, the episode with Greg Tarnoff is just excellent. If you really want a good primer on the topic, but you may feel compelled to say things like Section 508 or WCAG, sometimes pronounced “WeCAG.” These are essentially just specific standards within the field of front-end development that are defined by a standards body and followed by software makers like browsers and screen readers, and so if a client brings these up and wants them to be explained and there are some sort of directive from either the government or a board of directors or something to be Section 508 compliant or WCAG compliant, they’re really just the rules that me as the front developer should follow when I’m writing HTML or CSS or JavaScript to other languages of front-end development.

Timestamp: 00:30:05

Section 508 is very common within government. It isn’t as modern, I’d say, as WCAG, but because it just hasn’t evolved as rapidly as WCAG has, but I can say for a fact it’s still but used by government agencies. Jason is literally working on a project right now for a government department to bring their legacy systems by the way of compliance so it’s still very common, and then WCAG is a bit more contemporary because it seems to be a specification that’s sort of evolving as our web is evolving to include like mobile devices and touch screens and things like that.

Lea Alcantara: So you explained all the nuances and reasons for Section 508 and WCAG, but do you actually use these terms when speaking to a client?

Emily Lewis: No, really only if they specifically brought it up.

Lea Alcantara: Oh.

Emily Lewis: And if they’ve brought it up, then it’s something that someone has told them they need it. It’s probably not something that they are that aware of, and so sometimes it’s necessary to break it down a little bit, but I think ultimately, your best bet is just to focus on the bottom line, but there are accessibility standards and they allow you to have a site that helps people for however they experience your website, they can get to the content. They can access the content. They can purchase a product. They can buy a ticket no matter how they’re experiencing your website.

Lea Alcantara: Right. And if you want to use a car analogy when trying to explain this to a client, it’s pretty straightforward, “Does this car have easy handles or easy-to-close doors or can it accommodate wheelchairs?” Right?

Emily Lewis: And not even home building, but just construction in general like public buildings, there are standards you have to follow because you have to be an accessible building.

Lea Alcantara: Yeah.

Emily Lewis: It’s the same thing with the website; there are standards to follow to be accessible.

Lea Alcantara: Okay, so we’ve talked a lot about HTML, how about CSS, the next really common term?

Emily Lewis: Yeah, so CSS, this is basically the code for the site’s look and feel. It’s taking the underlying HTML, and I guess to clarify, I write HTML before I write CSS so that HTML is the first step and then I go in and I make that HTML look good. I make it look like Lea’s designs and I use CSS to do that.

Lea Alcantara: Right.

Emily Lewis: So I can make a headline purple and I can add a bunch of space on the left and the right of a paragraph and I can move an image to the left or to the right. So if we just take the car analogy, that’s you have leather on the seats versus cloth or the color of the car or maybe even — what’s that called, the lines like the fine line drawing they do on cars?

Lea Alcantara: Oh, I don’t know. [Laughs]

Emily Lewis: Like fast cars, with the pinstriping. [Laughs]

Lea Alcantara: Right, right, right, or like any other custom kind of paint job or some other type of thing in order to make it look exactly the way you want it, right.

Emily Lewis: Yeah. And another thing, we’re going to talk a little bit later about responsive web design, mobile web design, but CSS, it’s not just colors and spacing, but it also controls how a website looks when you view it on your phone.

Lea Alcantara: Yeah.

Emily Lewis: And what it might look like if you looked it on your iPad and what it might look like if you are on your desktop. So it’s still the look and feel, but it also is much, much more robust than colors.

Lea Alcantara: Yes, absolutely. And then after that, there’s another level, another acronym that is involved.

Emily Lewis: Yeah.

Lea Alcantara: And that’s JS or JavaScript.

Emily Lewis: Yeah, so JavaScript is kind of the last thing I add when I’m building a website. It’s essentially what adds behavior or interaction to the site, and I feel like that’s how a lot of us explain it, but I feel like that is even a little technical sounding.

Related Episodes

Lea Alcantara: Right. Like this is the behavior of the site, like that sounds a little bit weird.

Emily Lewis: Right.

Lea Alcantara: So I feel like sometimes the easiest way, whether it’s accurate or not, because again at the beginning of the episode, I’m saying, “Okay, we might be using terms that might not be a 100% exactly right.” But saying like, “It makes this thing move or it adds animation with JavaScript,” that could be an easy way to just simply explain whatever something is happening with JavaScript.

Emily Lewis: [Agrees]

Lea Alcantara: Another simple one, too, is that, okay, and again, it’s not a 100% accurate because there could be server-side checks, blah, blah, blah.

Emily Lewis: [Laughs]

Lea Alcantara: But JavaScript can be used in the front-end version to check if someone filled a form correctly, right?

Emily Lewis: Yeah. And honestly, kind of like CSS, JavaScript is so much more robust than that.

Lea Alcantara: Yeah.

Emily Lewis: I am not the strongest JavaScript developer so I’m not the one that goes deep into all the other things it can do, but frankly, I don’t do that with clients.

Lea Alcantara: Exactly.

Emily Lewis: Even if we need robust JavaScript and have to contract it out, the client just needs to know that we’re going to make sure when someone fills out a form, when they submit, if they haven’t put in a valid email address or phone number, they’ll get a little error, and so that’s something that they can completely understand and that’s something that JavaScript supports.

Lea Alcantara: Yeah, absolutely. And if you’re thinking about a car, some cars are outfitted with those backing cameras to check the curve.

Emily Lewis: Right.

Lea Alcantara: And it gives you like a beeping sound if you’re getting too close and then it turns red and all that kind of stuff, so that’s the same thing like when you’re trying to fill out a form, if something wrong, if something is missing and the JavaScript is the code that helps check that, to check mistakes.

Emily Lewis: And I think that analogy is sort of a nice way of also adding the note, and I’m not sure I would always bring this up with clients, but it is worth saying, JavaScript should not be required on a site, in my opinion.

Lea Alcantara: [Agrees]

Emily Lewis: This is something that, as you just described on a car, if it has that backup camera. Well, if you don’t have that backup camera, can you still back up? [Laughs]

Lea Alcantara: Yes. [Laughs]

Emily Lewis: Do you know what I mean?

Lea Alcantara: Exactly, totally.

Emily Lewis: So if someone, if for some reason, JavaScript isn’t working, can someone still fill out a form and submit it?

Lea Alcantara: Exactly.

Emily Lewis: So that’s the point. I believe my fundamental philosophy is that JavaScript is that extra layer. It’s like the delicious frosting on the cake.

Lea Alcantara: [Laughs] I like that. I like that. Yeah, and I actually love that you pointed it out that can you still back up without staring at that camera.

Emily Lewis: Right, exactly.

Lea Alcantara: It’s absolutely true. It’s absolutely true. So I feel like those were the fundamental things that the acronyms that we usually talk when developing a website, but all of that leads us to another very popular acronym and phrase that involves all of the things that we just said, which is RWD and mobile.

Emily Lewis: Yeah. So, I mean, it’s so open. RWD stands for Responsive Web Design, and sometimes it’s treated interchangeably with the term mobile, but they’re not the same thing. So mobile essentially refers to the concept of being on a mobile device. Looking at a site, viewing a site, a site being viewed from a mobile device, so that could be a phone, a tablet.

Lea Alcantara: Everything you can carry really.

Emily Lewis: Yeah, anything that you’re not tethered, almost anything like your own Wi-Fi or data or something like that.

Lea Alcantara: Right.

Emily Lewis: So that’s mobile, and responsive web design is the concept of making sure the site looks and works great, maybe not exactly the same, but looks and works great, whether you’re on a phone or a desktop. So it’s less about whether you’re connected to something and mobile and more about the device you’re using.

Lea Alcantara: Right. And it gets more complicated because something could be responsive, but still not mobile-friendly, right?

Emily Lewis: [Agrees]

Lea Alcantara: Because some people try to interpret responsive as let’s just shrink something so it fits in phones. Okay, so now it can load on a site. That doesn’t necessarily mean that you can use that site as well as it can be on that phone. It just simply means it loads on the site, so that means it’s not mobile friendly.

Emily Lewis: Yeah, and I mean, I think this topic is one that lends itself well to analogies of itself.

Lea Alcantara: Right.

Emily Lewis: Because I don’t even think you need to get into cars or houses because a lot of people today understand being mobile.

Lea Alcantara: Right, right.

Emily Lewis: Because they have like a mobile data plan or something like that and they understanding using a different device.

Lea Alcantara: Right, right.

Emily Lewis: And so we would try and put in the context of that sort of kind of almost human today experience.

Lea Alcantara: Right.

Emily Lewis: So for example, you’re saying something can be responsive and not mobile-friendly. Well, mobile-friendly, one of the things to be mobile-friendly is to be fast.

Lea Alcantara: [Agrees]

Emily Lewis: So that if you’re not connected to a network through cable that you can still view that site really quickly. That has nothing to do with whether you’re on a phone or a tablet or a desktop. It’s just not the same. So, it can look right on your phone, but it can be really, really slow to load.

Lea Alcantara: Right.

Emily Lewis: So it’s responsive, but not mobile-friendly.

Lea Alcantara: Yeah. So it’s really important to note. So I think it’s important to define some of these things, especially when you’re trying to sell some sort of responsive web design or mobile solution for your client because some clients these days, they might come to us saying like, “Okay, my site loads on a phone,” but that doesn’t necessarily mean it’s actually being optimized and maximized for its potential to actually help their business on mobile devices, and we do have a few resources that will add to our show notes about responsive web design and specifically we do have a responsive retrofit episode with real-world client examples, breaking all the nuances down.

Timestamp: 00:40:28

Emily Lewis: All right, so moving on, I think it’s worth bringing up a topic that we actually don’t bring up too often in the beginning of a project, but it does come up, especially when we are handing over the site for the client to see for the first time in the browser and they’re going to test it and click around and things like that.

Lea Alcantara: Right.

Emily Lewis: So these browsers and compatibility.

Lea Alcantara: Right. And that is a front-end subject, right?

Emily Lewis: Totally, totally.

Lea Alcantara: And I feel like sometimes people gloss over that because they’re too focused on HTML and CSS. Let’s think about where that’s actually being rendered, which is our browsers. An important thing to impress upon…

Emily Lewis: Well, actually, I just want to interrupt you.

Lea Alcantara: Sure.

Emily Lewis: What you just said was super techie.

Lea Alcantara: Oh.

Emily Lewis: So where it’s actually rendered.

Lea Alcantara: Oh, right, even the term, yeah.

Emily Lewis: Like our clients isn’t going to ever understand that, and so like when we were talking with a client you referenced early where we had to explain some of the acronyms.

Lea Alcantara: Right.

Emily Lewis: One of the things I asked her when I got to explaining what a browser or I got to saying the word “browser,” I said, “Do you know what a browser is,” just to ask because that term, people may not know. They may understand Internet Explorer or they might understand Chrome.

Lea Alcantara: Right.

Emily Lewis: I mean, gosh, I know more clients who understand Internet Explorer than any other brand name.

Lea Alcantara: Right, of course.

Emily Lewis: But anyway, so it’s important to not just say where it’s rendered, but explain that the browser is the software on your phone or on your computer that you open up and type in an address to go see a website, so it’s what shows you the website.

Lea Alcantara: Yeah. And I think the next step once they understand that is that everything that we’re coding for them is actually understood differently depending on whether you’re looking at this on a Mac or a PC or on your phone, right?

Emily Lewis: Yeah.

Lea Alcantara: So that’s really important to set the tone for your client that not everything will look exactly the same or behave exactly the same simply because all those different devices will treat the code that we create differently.

Emily Lewis: And it’s one of those things that I bring up when I hand something over and I’m giving them instructions on how to test.

Lea Alcantara: Right.

Emily Lewis: So I explain that I need to know if they’re on a PC, and if they’re on a PC, what operating system and version they’re on, and then what browser they’re on, and so that’s the context of why they need to understand what each of those things are because when they’re testing, if they find something, any front-end developer knows we need to know those details in order to begin troubleshooting.

Lea Alcantara: Yeah, absolutely, and it can get so nuanced because there are so many different ages of computers so it’s not even just between Mac, PC or iPhone or Android, but what version are they using and are they somebody who updates their system very often or not, right?

Emily Lewis: Yeah. Or if they’ve installed some sort of browser add-on, so many things are, you know?

Lea Alcantara: Oh, totally.

Emily Lewis: And that’s why it’s important to educate your clients about this because you will sometimes go down this rabbit hole.

Lea Alcantara: Yeah.

Emily Lewis: When they’re reporting a problem and you’re trying to figure out what on earth is happening on their end, and it ends up being isolated to their computer or their device.

Lea Alcantara: Yeah, absolutely, and at that point, sometimes it’s actually more cost effective and time effective by just picking up the phone and walking through that problem and that helps you understand whether it is an isolated incident to their computer. Because when you were just talking, explaining over like maybe it’s just them. [Laughs]

Emily Lewis: [Agrees]

Lea Alcantara: Maybe it’s just their own very, very specific install, it reminded me that we’ve got a troubleshooting message about content management system login situation where she kept mentioning, “It doesn’t log me out. Every time I log out, it logs me back in,” and I was like, “Oh wow, that’s crazy bug, I wonder what’s going on. I wonder if it’s an Internet Explorer issue or whatever or a version issue, and that we just need to update.” On and on and on and on it went, and then so I picked up the phone and went through the process with her on her site using her login at the same time and I didn’t have the same issue as her when I went through all of it, and then fast forward, it’s because she had this LastPass browser add-on that had auto-complete, auto-log in hooked up, right?

Emily Lewis: [Agrees]

Lea Alcantara: So it’s funny how as web designers and web developers, we can get calls that are completely unrelated to web design and development, but might seem like it actually is related to you and it is just the browser or something very, very specific.

Emily Lewis: [Agrees]

Lea Alcantara: So usually when we’re talking about browsers and compatibility with clients, we try to tell stories a lot more than analogies because I feel like it’s hard to explain an analogy with, “This won’t work over here or there.”

Emily Lewis: [Agrees]

Lea Alcantara: So like another example is like one of our past clients who’s talking about how they can’t see the site properly on their computer and then when I found out that they were looking at the site at a hospital where they worked and considering the context of the medical industry and hospitals and how slow they are to update their systems, we found out it was just like literally an isolated incident that no one else will ever see this site on that very specific situation ever.

Emily Lewis: [Agrees]

Lea Alcantara: So they didn’t need to pay us costly amount of time and money to fix an issue that didn’t need to be fixed.

Emily Lewis: Yeah. You mentioned it’s always a good idea to jump on the phone, but also jump on the phone and be ready for some screen sharing.

Lea Alcantara: Oh yeah. Oh yeah.

Emily Lewis: Or have something set up where you can see their system.

Lea Alcantara: Yeah, absolutely. So now that we’ve set all the definitions for this episode, let’s talk about the process that we actually follow for all these moving parts.

Emily Lewis: [Agrees]

Lea Alcantara: So how can we describe that, especially in relation to each other?

Emily Lewis: Well, I do think it’s important to emphasize not in too much detail, but when you’re explaining to a client, especially in the sales process, that there are standards, best practices when it comes to web development and not everyone follows them, and it’s frankly to the detriment of that client.

Lea Alcantara: [Agrees]

Emily Lewis: It’s not a detriment to the web developer, but it’s the client who’s going to suffer if standards aren’t followed, and so me, as a web developer, I need stay informed and follow web standards. Just like a building contractor has to be licensed and needs to know what the new codes are for his city or a mechanic. I don’t know, do they get licensed or they have to have training.

Lea Alcantara: Well, someone who actually builds the car will need to be an engineer.

Emily Lewis: Right.

Lea Alcantara: So they would have to follow specific codes and even diving deep into that, there’s like fuel efficiency rules or things like that that people have to follow.

Emily Lewis: [Agrees]

Lea Alcantara: So I guess it vary state by state, but regardless, the point is there are rules that everyone has to follow to fit a specific standard so that the product that you get is superior.

Emily Lewis: Exactly. And not only is the product superior, but it’s more cost effective because frankly it cost more to fix a poorly-coded site than it costs to build it right the first time.

Lea Alcantara: Right.

Emily Lewis: So if your site isn’t semantic or it isn’t accessible or your CSS isn’t mobile friendly, it’s going to cost you more in the long run, and that’s why standards are important.

Lea Alcantara: Yeah, absolutely. So let’s talk about the actual process of building a site, so at the beginning I mentioned the Ferrari or Ford analogy, we can go all out, bling it out, have the highest end model or we could start off small and add to the car, we could also customize the car, and that’s the same with the web.

Emily Lewis: [Agrees]

Lea Alcantara: You can have a budget for a highly-custom site and we can add more bells and whistles and testing and way more solid code to make the foundation of your site rock solid. So I think the analogy for me, like if we’re using cars again, it’s like choosing carbon fiber versus like sheet metal. So carbon fiber is the higher end material and that’s like the light weight in optimized code because it helps make a site fast because there’s less weight on the site, and the reason why it’s important to point something like that, oh, because there’s more than one way to code a site and it can still work, right?

Emily Lewis: [Agrees]

Lea Alcantara: Both ways you can code a site, it can still have a page show up on the browser without any issues, but it takes more time and effort to make that process actually efficient and trouble free in the future.

Emily Lewis: [Agrees]

Lea Alcantara: The other thing too is if you have less of a budget, it might mean we’ll need to test on less devices and browsers, right?

Emily Lewis: [Agrees]

Timestamp: 00:49:47

Lea Alcantara: For example, that hospital situation that I mentioned, well, if that’s just the one isolated incident where this person was viewing it, well, does it make sense for us to spend the extra time and money to make the site look good on those computers when that person is the only one looking at it there? Right?

Emily Lewis: [Agrees]

Lea Alcantara: So there’s really kind of like a rabbit hole that you could go into when trying to explain how far a site needs to be customized in the front end.

Emily Lewis: Yeah, but still making sure that the client understands that that foundation, regardless of their budget, is still going to be supported.

Lea Alcantara: Yeah, absolutely.

Emily Lewis: Yeah. And I think it’s one of those things that it’s part of also the process of helping the client prioritize.

Lea Alcantara: Yes.

Emily Lewis: Because no client has an open-ended budget. I mean, I’ve certainly never found one, and so everyone has got some budget and you have to fit in with that and so whether it’s during the sales process or during the early part of the project planning process, explaining to them where they can save money now or where we could shift something to later, where it is smart to invest, like I was explaining good semantic markup following standards, that’s always a good investment, but do you need the JavaScript frosting for Phase 1 or can that wait till later?

Lea Alcantara: Right.

Emily Lewis: So it’s a matter of helping them prioritize and doing it in a way that doesn’t get too technical about, “Oh, well, we can skip the JavaScript,” and instead say, “Well, can we skip that form giving an error if someone gives the wrong phone number or the wrong phone number format? Can we skip that for later?”

Lea Alcantara: Right.

Emily Lewis: That kind of questioning.

Lea Alcantara: Or even like when we’re dealing with responsive web design or mobile development, we could have super rock solid HTML, but we won’t have all the CSS for every single device known to man, but we could launch with a few devices that we will test with that will accommodate a majority of mobile devices, right?

Emily Lewis: [Agrees]

Lea Alcantara: So we’ve just spoken and defined everything we could about front-end development.

Emily Lewis: [Laughs]

Lea Alcantara: And there are still more to say, but we’re going to end it right here with the note that all front-end is influenced by web design, like this entire series is building upon each other, and eventually…

Emily Lewis: Just the way they build on each other in a project.

Lea Alcantara: Yes. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: And eventually, that episode before this one, the web design one, and this episode on web development, will influence our next episodes, which will dive into the functionality that we kind of hinted about when we’re trying to say there’s a difference between front-end and back-end development, like how to update the content of the site.

Emily Lewis: [Agrees]

Lea Alcantara: Or like in a car, how can we customize this car to do things that other cars don’t do?

Emily Lewis: [Agrees]

Lea Alcantara: Right?

Emily Lewis: Yeah. So that brings us to the end of today’s episode and normally, we would be doing our rapid fire ten questions, but Lea and I have both already answered them this year in previous episodes.

Lea Alcantara: [Laughs]

Emily Lewis: So I’m actually going to put Lea on the spot and just ask for one question.

Lea Alcantara: I’ve got a repertoire, but it’s Don’t Speak by No Doubt.

Emily Lewis: [Laughs]

[Music starts]

Lea Alcantara: CTRL+CLICK is produced by Bright Umbrella, a web services agency obsessed with happy clients. Today’s podcast would not be possible without the support of this episode’s sponsor! Thank you, BackupPro!

Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website, ctrlclickcast.com. And if you liked this episode, please give us a review on iTunes, Stitcher or both! And if you really liked this episode, consider donating to the show. Our links are in our show notes and on our site.

Emily Lewis: Don’t forget to tune in to our next episode when Andy McCormick joins the show to chat about disaster planning using the Cloud. Be sure to check out ctrlclickcast.com/schedule for more upcoming topics.

Lea Alcantara: This is Lea Alcantara …

Emily Lewis: And Emily Lewis …

Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!

Emily Lewis: Cheers!

[Music stops]

Timestamp: 00:54:07

Love this Episode? Leave a Review!

CTRL+CLICK CAST inspects the web for you!

Your hosts Emily Lewis and Lea Alcantara proudly feature diverse voices from the industry’s leaders and innovators. Our focused, topical discussions teach, inspire and waste no time getting to the heart of the matter.