Skip to our site navigation Skip to the content

Responsive Web Design


Episode 122: Spotlight: Sara Soueidan

In our continuing series about the people who make responsive designs happen, we talk with freelance front-end Web developer, Sara Soueidan.

With accessibility—as well as with a lot of things, including responsive design—sometimes you have to do it without asking for permission. Because when you show your clients the benefits of what you’ve done, it’s more likely that they will be convinced.

If you’d like, you can download this episode’s audio file. Additionally, you can follow us on iTunes, on Google Play Music, or subscribe to our RSS feed.

Buy The Books

Everything you need to go responsive, in four short books. Save 15% on all four!

Subscribe Now

The podcast may have ended in 2018, but you can still subscribe! If you want the latest episodes, fire up your favorite podcasting app and subscribe via RSS, Google Play Music, or on iTunes.



This Week’s Guest

Sara Soueidan

Front-End Web Developer

Sara Soueidan is a Lebanese freelance front-end web developer working with companies across the globe, building clean, responsive front-ends for Web sites and applications focused on accessibility, progressive enhancement and performance. She also runs workshops on front-end development and writes technical articles on her blog and for various big publications. Sara wrote the Codrops CSS Reference, co-authored the Smashing Book 5, and has been voted the Developer of the Year in the 2015 net awards.


Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte, and this week I am, in fact, your only host. Karen McGrane is unable to join us this week, which means that I have two times the pleasure because I couldn’t be more excited to be speaking with my friend and colleague, and someone who I deeply respect and admire, Sara Soueidan, who’s coming to us from sarasoueidan.com. Sara, thank you so much for joining us.

Sara:

It’s a pleasure. Thank you so much for having me, Ethan.

Ethan:

Yeah, absolutely. It is so, so wonderful to have you here, Sara. Maybe for those in our audience who are just tuning in this week and have missed the last couple of episodes, we’re trying a little bit of a different format here at the Responsive Web Design Podcast. Usually we tend to speak to a company or a brand that’s taken their site responsive, and this time we’re actually trying something a little bit different, where we actually reach out to some web folk that we deeply respect and admire. And we couldn’t be happier to have Sara as part of that lineup. So Sara, thanks for trying something a little bit new with us.

Sara:

It’s a pleasure. Thank you so much for thinking of me. To be one of the people that you wanted to interview, I’m flattered. Thank you.

Ethan:

[laughs] Well, we were thrilled to have you because, as I was telling Karen earlier, you have probably forgotten more about web technology than I’m ever going to know in my career.

But before we dive in, a few words about our sponsor. I couldn’t be happier to have Gather Content back as a sponsor on the podcast. You see, Gather Content is a content collaboration platform. It helps teams plan, organize, and produce all their web content in one place. They provide structured templates and simple workflows to make collaboration and production easy without the shuffling around of Word documents and unnecessary emails. Centralizing the editorial process will make approval of content easy, so everyone knows what they’re responsible for and when they’re responsible for it. And what’s more, Gather Content has recently published a free online guide to Content Strategy for Website Projects, which they’ve written for all the people who want to make smarter, content-led decisions on their designs. So every responsive design, I believe, benefits from a content-first approach. But as Gather Content’s guide says, that doesn’t mean waiting until all the content is written. Instead, it means considering and thinking about content at every single stage of your project. And Gather Content’s guide can help you do just that. So whether you’re working in an agency on client websites or maybe you’re working on an in-house team, Gather Content’s guide should help you more effectively contribute to your digital projects. You can read it online for free at gathercontent.com/RWD, or check out Gather Content’s products at gathercontent.com.

Maybe for those in our audience who aren’t as familiar with your work as I am, maybe tell them a little bit about yourself.

Sara:

This is usually the hardest part because I always start stuttering and I’m not sure what to say. Basically I’m a freelance front-end developer. I started doing this a couple of years ago—actually four years ago, to be more specific. I have a Bachelor’s degree in computer sciences, but I still consider myself self-taught because I never really got to attend any of my front-end development courses in college. Most of the people who know me and who follow me know me because of the writings that I have done. I basically started writing three years ago. I started sort of writing deep-dives into topics like CSS and SVG in particular, and then I started speaking about these topics and people started knowing me more because of that.

Yeah, I’m just another front-end developer.

Ethan:

Well, I think you’re selling yourself just a little bit short, Sara. But it’s been incredible to me to just sort of watch the work that you do in general on the sidelines, especially over the last few years. I think I first came across your work when you sort of wrote this really articulate and passionate defense of CSS regions. The entire internet had sort of taken this specification apart, but you actually stepped in and very thoughtfully said that there’s actually some value here, and you presented a different way of looking at this technical approach of laying out pages. That really struck a chord with me, because I’ve always appreciated how accessible you managed to make these very technical concepts, like SVG or really complex CSS layouts.

Sara:

Thank you. I actually enjoy that; I love doing it, I get a knack out of it. I don’t know why, I’ve always been like that.

Ethan:

Tell me a little bit about how you fell into the web, because I didn’t realize you only just got your start three to four years ago. I thought you’d been working for quite some time. Tell me a little bit about how you found an entry point into the web.

Sara:

My first entry point was in the eighth grade. So, basically we took only a few classes of computer in my computer class basically, in school. Our teacher thought that he would introduce us to what was then called HTML, or the way to build websites. I had never seen anything like that before. But as soon as he started writing on the whiteboard, writing the paragraph tag and the HTML tag, I thought, hey, this looks familiar, even though I had never seen that before. So, it was sort of love at first sight. I started digging deeper into the topic, even though we stopped learning the material in school. But I got a book from one of my friends who was in college, so I got his college course book and I started digging deeper. I built a couple of personal projects at home using iFrames and tables and a lot of pictures and font attributes, then I stopped for a few years because basically school and life happened.

But I’ve always loved it so much—I’ve been interviewed a lot of times and people always ask me how I got started, but there’s one thing that I always forget to mention, which is that I loved HTML so much and it felt so natural to me… I did have a few friends who also understood HTML, so when I would write emails to them, I wouldn’t write text emails. What I would do is I would create a web page and index that HTML. I would write my email in HTML, I would add a background image, a fixed background image, a scroll effect, and maybe some marquee or something. So, basically a really fancy HTML in the form of an HTML format, and then I would attach that to the email and then I would send it over. I loved it. I just loved it.

And then the last thing that I thought I would study in college was computer science. I never thought I would do that. But a lot of things happened over the course of my life that made me make decisions that I didn’t really want to make, and those decisions are what got me here today. So, I didn’t want to do computer science but I ended up having to do it because basically my parents could only afford getting me into one college in Lebanon, and I only had a few options at that college, and I thought that computer science was the least bad than the rest. So, I chose that, and then the middle of the first year I almost switched majors to study electronics physics, basically. Then the second year I almost switched to study—it has always been my dream to be an architect, so I almost switched to architecture, as well. Then two days before I went to the other college to study architecture, I decided to change my mind again, and I continued with computer science. I’ve never been a geek, I’ve never been a tech person, I’ve never been into computers or into anything of that sort. So to be here today doing this, it’s sort of like, “Really?” I had no idea. But I couldn’t be happier with this.

Ethan:

That’s great. Was there a point in your career or during your education where you remember transitioning from kind of reluctantly doing computer science and doing technical things, to sort of being as passionate about it as I think you are today?

Sara:

Yes, that happened after college. About a year and a half after college, basically when I had no clue what to do for a living, I had to do something for a living, and one of my best friends knew that I loved HTML. He was actually one of the people that I used to send HTML emails to. He said, “You have a base in HTML. You could learn CSS.” I had zero CSS knowledge four years ago. He said, “You could learn some CSS and then you could transition to JavaScript and you could start building websites. You have the potential for that, so why don’t you try it?” So he gave me these ten lessons, basically. He would design these simple designs. It started with a very basic design, basically three rectangles, positioning one rectangle inside of the other. Then it started getting more complex with each one and I started learning about positioning in CSS, floats—basically CSS, learning CSS.

After ten lessons, I had to start googling for stuff. I wanted to do something and I had no idea how to do it, so I started using Google like everybody else does. And then at some point I found Codrops, and then I found CSS-Tricks, and then I started finding even more articles and more topics to read, and I got hooked, I just couldn’t stop anymore. That’s when I realized I want to do this, I just love doing this. That’s what sparked it.

Ethan:

That’s really wonderful. Hearing you talk a little bit about your mentor and how he introduced to CSS, I can see that structure sort of mirrored in a lot of the writing that you do, which I think is very socratic, it’s very easy to follow, and it builds on top of each other. Your blog is something I really enjoy reading, so I can see that influence in you.

Sara:

Thank you, I appreciate that.

Ethan:

But I think education is a big part of your work, if I’m not mistaken. You do a significant amount of conference speaking and a significant amount of writing, and additionally you occasionally show up for podcasts like this one. Is there something about that that’s helpful to you in your work? Is there a reason that you enjoy writing? How do you make the time for all of this stuff?

Sara:

Actually, I’m not sure if you’ve noticed, but I haven’t been writing as much in the last six, seven months, or even the last year, actually, because I started getting more client work during that period. A couple of years ago, the client work that I used to get used to span two to three weeks, tops. But last year I started taking projects that took a lot more of my time. For example, a project would span four months and that would be like the minimum amount of time. And then I started working on Smashing Magazine, which was also four months. And then that was followed by another project in December, which I started in January because I was almost burnt out at the end of that year. So, I haven’t been writing as much. I’ve been focusing more recently on writing case studies. So, basically real life projects, real life things. Instead of educating about a specific topic, I would be talking about how I use the stuff that I know in order to solve real life problems.

I haven’t been finding a lot of time to do it. It’s not something I can give up easily because it’s inspiring. For example, I have a talk coming up next month, so today I was thinking I have to start preparing for that talk, and preparing means doing research, and testing and experimentation. So, it always drives me to keep learning and to keep testing. Writing is also another form of taking notes for me. So whenever I’m learning something, whenever I’m working on something, I have to take notes basically because I have to remember how I did something, or it’s sometimes just documentation of my work. So, I write for that reason as well. But I’ve been doing it a lot less, recently.

Ethan:

Yeah, work tends to pull us away from the things that we might prefer to be doing. [laughs] But tell me a little bit about your practice and the kind of work that you enjoy doing. I’m assuming that you work as maybe the sole front-end developer—or do you partner with other developers? What kind of clients do you tend to work with?

Sara:

I usually take, actually, any kind of projects that I would enjoy. I don’t have any specific clients that I would work or not work with yet. So, basically all of the clients that I’ve worked with before have been just like Smashing Magazine. So basically there’s a team, I’m usually the sole front-end developer on the team, which I know makes it a lot easier for me, because when you have multiple front-end developers working on the team, you have to start thinking about a lot of extra stuff, like agreeing on, for example, the same naming conventions and all of that stuff. Yeah, that’s a whole different world. So I’ve been the sole front-end developer on all of my teams, but I’ve been working directly with designers and back-end developers at the same time. So, I’ve been part of a team, but only being the sole front-end developer on that team.

Companies include, for example, my latest project was for Provata Health, which is a health company in the US. I’ve worked with them twice before, and this was the third time, so they’re a returning client. I’ve worked with Smashing Magazine; I’ve worked with another start-up in Germany, which is called COBI Connect. So, basically they’re all small companies—aside from Smashing Magazine, which is sort of huge—and it would be building some sort of product, or I usually focus on building the user interface for whatever they’re working on. I love doing that, especially when I started working with teams.

A couple of years ago I would be working on my own, like I would get, for example, a PDF of a design somehow and I would build it and then I would send it over, and then god knows what happens on the other side, I had no idea what would happen next. But then last year I started working with designers up close, we started connecting on Slack, we started discussing designs. I started contributing to changing the design completely sometimes, because as a front-end developer, when you start coding the logic—especially when you start getting into JavaScript, then you have to code the functionality of the user interface—some things just don’t make sense when you start thinking about them logically.

So, for example, with COBI, there was this profile page which contains a form, a settings form where a user can change their email and their settings. The user interface was initially really good, but as soon as I started coding it, I had to know how it would interact with the back-end, what kind of responses we would get, what kind of logic. That’s when some problems—actually, a lot of problems—started surfacing, because the designer didn’t really connect with the back-end developer before I got onto the team. So, everyone was sort of working on a separate planet. A lot of discussions happened, a lot of changes happened to the UI.

The same thing happened with Smashing Magazine. Not exactly the same thing, but, for example, we had an initial design that we started working with, and then when user testing started happening, some of the things in the design didn’t really work out. For example, the one component that took the most amount of time was the navigation. It was fantastic, I loved it, but it was initially hidden; it was collapsable basically, so you would only see the menu button, even on desktop. I didn’t really like that idea because I don’t like hiding menus on desktop, but then it started growing on me. I started thinking, okay, it’s fine. Especially if the other components on the page are engaging enough, users may be able to go from one page to another without actually needing navigation—that would make it even more engaging. But with more testing, we realized that, okay, the navigation had to be shown because of clicks and business, and stuff like that. And then when we showed the navigation, it was too large, so it took a lot of vertical space, which means that with the layout for the article that we had, we had the “Authored by” at the top of the article before the heading of the article. So, the title was actually pushed down so much that you wouldn’t even see it when you first visited the page, which was also unacceptable. So, we did so many iterations and so many changes. It took us about four to six weeks to finally get to one solution that we were happy with, and I’m actually very proud to say that I was the one who sort of experimented to get to that solution.

I’ve enjoyed very much getting into the design part with Smashing Magazine. Mainly my work is building the front-end HTML, CSS, JavaScript, but sometimes lately in my recent projects I’ve been getting into more UX consultancy and a little bit of design.

Ethan:

That’s great. I’m a firm believer that those disciplines are sometimes a little bit more separate than they actually need to be, especially now that we are, as I think you said, collaborating a little bit more closely on fleshing out some of these issues. I’d like to talk a little bit more about how you do that. On your client projects, how do you get to a point where the designers actually trust your perspective, that when you make recommendations that things might need to change or maybe to rethink a specific part of the layout? Are there strategies you use or techniques that you use that allow you to do that?

Sara:

Actually, I would say two points. The first point is it’s usually logic. I always, always, always think from a user’s perspective, not from a developer’s perspective. So whenever I get a design and I start coding it, I start interacting with it and I start thinking, “Okay, if I’m a user… “and I start, for example, to tab through the pages on my keyboard; or if I’m a screen reader user, how would a screen reader actually read it out loud? I think from a user’s perspective and then I start thinking, okay, this will probably confuse users; or if something confuses me, then I think it’s safe to assume that it might confuse someone else. So, I convey this idea to the rest of the team and usually it makes a lot of sense—thankfully—so they usually agree with me and we end up making the changes that, with user testing, prove to be a lot better for the UX.

The second thing is I think that they trust me, which is also good. That’s not something I’ve told them to do, but…

Ethan:

[laughs]

Sara:

Basically, I think it’s my work that gives me some credibility on the side.

Ethan:

I’m sure it does. The proof is in the pudding. Well, tell me a little bit about the kinds of websites you work on. Do you find that most of them tend to be responsive these days? If so, has that changed your workflow as a developer?

Sara:

Yes, absolutely. I’ve never worked on anything that was not responsive until my latest project. It was actually also for Provata. I worked with them before and their marketing website was responsive by default—all of my clients have been not only embracing responsive design but they’ve also been embracing progressive enhancement. For example, when I talk to them and tell them, “Okay, browser support is your friend. I’m going to be using some advanced features, I’m going to be using feature detection, the website is not going to look exactly the same on every browser, so is that okay with you?” I think I’ve been extremely lucky because all of them have always said yes. They always say, “Do whatever you think is right, whatever you would recommend, whatever you would do on your own projects,” and that’s what I would do. Yeah, so it’s been a little bit easy for me so far.

Except for the latest project. It was still easy, but it was the first time that any of my clients have ever asked me to build a fixed layout. I was like, “What…? Why?” I know Provata, I’ve worked with them before. They know responsive design, they love responsive design. So, I couldn’t help but ask the CEO, “Is there a specific reason why you don’t want to go responsive on this?” He said that, “Honestly, I don’t think it looks good on mobile, and we already have a mobile application, so users are probably going to be using the mobile application, they’re not going to be using this web app.” That didn’t really sit well with me because, one, you can never really tell what your users are going to be using. Maybe they decided to explore the web UI. Maybe they just want to go to the web UI on mobile. You can’t really guarantee that they’re going to be using your mobile application.

And two, the project is actually just a survey, and a survey is just a long form, and a form is just a set of input fields, and input fields—I mean, why wouldn’t input fields look good on mobile? I mean, they’re so simple. The design was so simple that every single page was contained to one to three input fields tops, and then there were the longer pages that contained a list of multiple choice questions, so basically radio buttons and checkboxes. So I thought there’s no way this wouldn’t work on mobile. It does work, it should work, it must work. So, I think they had a problem with it not working because there was a lot of vertical centering and there were these background images that were literally just decoration added to the page. They were maybe thinking that if they were to shrink the page, then the background images are not going to be visible anymore because the input fields would sit on top of them. Anyway, I told the CEO that I wanted to make it responsive. I mean, after all—this is a side note here—I have a reputation to keep…

Ethan:

[laughs]

Sara:

[laughs] I’m not going to build a fixed layout, and if I did build a fixed layout, I was totally not going to put in my portfolio.

Ethan:

No, man. You’ve got cred, absolutely. Fixed-width design, who does that? [laughs] Just kidding.

Sara:

Yeah, absolutely. It’s 2017. [laughs] Anyway, I told the CEO that I wanted to make it responsive, and because I wasn’t really sure if they were going to let me keep the responsiveness of the design, usually whenever I think Sass, I usually put the media query for each component inside of that component. So, instead of doing that, I just put all of the media queries together in one CSS file and I started changing the layout in that file. So if my client should not want to use them, I would just delete that file and we would go back to phase zero. I made it responsive; it was very simple, very easy to do, actually. I had to do a lot of media queries using vertical media queries. So instead of querying the width of the screen, it would query the height—it was the second time I’ve actually used this in a real life project; I did it in Smashing Magazine, too.

So, the only problem that I think was their main problem was with the background images, so that’s when I had to make a decision. I was like, these background images are only background images. They’re only there for decoration. They’re nice to have. So, for example, if you’re selecting the input field for the weight and the height, the background image would change accordingly, which is a really nice touch, but it’s not really essential for the functionality of the form. The user will be able to take the survey, you will be able to complete it perfectly without these images. So I thought, okay, I’m just going to remove these images on smaller screens, there will be no overlaps, everything else will work as expected. So I made it responsive, I sent Alex the preview, and thankfully he said, “Okay, I stand corrected. This does look good.” He loved it.

Ethan:

Congratulations. That’s wonderful.

Sara:

Thank you.

Ethan:

That’s great, because I think it’s a challenge, sometimes when talking with clients, when there’s a bit of a disconnect between looking at sort of PDF, as you said, or a Photoshop file or something like that and just sort of assuming that when we take this to the web, that may not necessarily translate to everyone’s experience. Maybe fonts won’t load, or maybe JavaScript won’t load, or maybe they’re going to be on a smaller-sized screen. I think that kind of ties into something I’ve always admired about your work, especially in the last year or so, which is you’ve gotten very vocal in talking about accessibility and how to ensure that really complex layouts and really complex functionality can be understood by people who might be using a keyboard or who may not see the screen as you or I might.

How did you find your way into accessibility, and are there any resources that you would especially recommend to anyone else who’s sort of interested in learning more?

Sara:

I don’t really recall what started it, but I know that what got me to get deeper into it are the people that I follow on Twitter, the people that are already passionate about accessibility. I can’t just build something and be like, okay, if Person X can’t use it, then that’s their problem. It’s not in my nature to do that. So, as soon as I learned that there’s something that I can do to make my work more accessible to more people, I started doing it. For example, the Provata marketing website is not the most accessible thing in the world because I didn’t even know about accessibility two years ago. But ever since last year, I started caring more; I started convincing designers to add focus tiles. I added the focus tiles to Smashing Magazine without even asking for permission, and they loved it.

So basically with accessibility, as well as with a lot of things, including sometimes responsive design, sometimes you have to do it without asking for permission. Because when you do it and when you show your clients the benefits of what you’ve done, it’s more likely that they will be convinced of the idea and they will get on board with it.

For example, Léonie Watson once said at a conference that, “You don’t have to ask for permission to make your site accessible.” When I started building the survey for Provata, I mentioned before I started working on it, I told the CEO that I have to make it accessible, we have to make sure that it’s accessible. In a lot of the emails, he said, “Sara, you’ve mentioned accessibility a lot of times. What does it actually mean?” So, I explained it to him. You know, they’re a health company and there’s a high probability that their user base will include users that have some sort of disability, so it’s even more important for them to have accessible web applications and interfaces than it is for anybody else, for example, because they’re in the health field. So, you have to do it. If you can do it, do it, especially since accessibility is more on the lower level code. Designers probably don’t even start getting into it until you start talking about, for example, accessibility of color and tabbing and focus tiles. Then you have to start convincing designers to do it as well.

But I think the first thing that we can do as front-end developers is to just do it. Seriously. This is the best advice that I can give. Léonie Watson said it best: “Do it. You don’t have to ask for permission.” Just like I did, for example, with the Provata survey. I made it responsive. I knew that it was going to work. Yeah, basically doing it is what got it to be accepted.

Ethan:

I think that’s great advice. But speaking of advice, if there’s anyone who’s listening to this podcast today who is either a front-end developer or maybe a company that’s thinking about going responsive, do you have any advice for folks that are going responsive in the near future? Anything that you find especially valuable?

Sara:

I would say try visiting your application or your website on your mobile phone, and try spending some time doing it. Don’t just do it on desktop. Try visiting it once, twice. Try getting things done on that interface and see how that works. If you start feeling even just a little bit of frustration, then you can bet that a lot of users are feeling the same. Most people these days—I mean, seriously, everyone I know walks in the streets with a mobile phone in their hand, browsing, buying, purchasing things online, reading things online. I’ve never been really a mobile person, I’ve never really liked using small screens because they’re small and my eyes get tired easily. But even now I find myself using my phone to make purchases online, to read; sometimes I open a Twitter link online. If a website is not responsive, if a form does not behave as expected, it’s extremely frustrating. As a user—as I said before, I like to think from a user’s perspective—I’ve stopped and decided not to buy. I’m talking about business here: users will abandon your website more if you do not make sure that it provides them with a usable experience on mobile as well. Especially these days, it’s 2017, most people use their mobile phones every day. It will benefit everyone in the long run, including your company. So, it may take a little bit more time at the beginning, but the results are definitely worth it.

Ethan:

Sara, I think that was beautifully said, and, in fact, I think you’ve just earned the right to take over my spot on the podcast because I couldn’t have said that better myself. That was beautifully said.

Sara:

[laughs] Thank you.

Ethan:

Sara, this has been an absolutely wonderful chat. I can’t thank you enough for coming on the podcast. For our listeners who want to keep in touch with you, who want to follow your work, where are some things they should check out? Where should they find you online?

Sara:

Well, unless they’re interested in the photos that I take when I go places, which is where I post on Instagram, I’m usually most active on Twitter and on my website. So, basically all of my writings and all of my projects are on my website, sarasoueidan.com. Then I’m actually most active on Twitter, as well. I basically tweet about front-end development, sometimes some random rants, but those rants are also generally about front-end development, CSS, SVG. So, Twitter and my website.

Ethan:

Very nice. Well, they will see you there, and Sara, thank you so much for your time.

Sara:

Thank you for having me.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.


Skip to our site navigation; skip to main content