Posted on

Smashing Podcast Episode 59 With Chiara Aliotta: What Is Design Storytelling?

In this episode of The Smashing Podcast, we take a look at design storytelling. What is it, and how can it help us shape digital experiences? Vitaly talks to Chiara Aliotta to find out.

Show Notes

Weekly Update

Transcript

Vitaly Friedman: She’s an award-winning graphic designer, art director and brand consultant working on digital products, print, editorial, UX, and branding. She has founded until Sunday a design studio focusing on regional branding and visual communication. Now in her work, she usually wears many different hats, designing for large and small organizations such as Joomla, PAMS Foundation, Smashing Magazine, Action Aid Hellas, and Medicine South Frontiers, co-running an art gallery, managing a personal lifestyle brand, and speaking at creative events.

Vitaly: Now, she also strongly believes in the power of storytelling and incorporates it in every project she works on. When she’s not working, you’ll find her traveling, capturing photographs or taking a dip in the sun deviled Aegean Sea. And of course, she’s a cat person living with her wonderful husband and her wonderful cat Kesa on the heavenly Greek island of Syros in the Aegean Sea. So we know she’s a wonderful designer and illustrator, but did you know that she also absolutely loves typography and children popup books? My smashing friends, please welcome Chiara Aliotta. Hello Chiara. How are you doing today?

Chiara Aliotta: I’m smashing. How are you Vitaly?

Vitaly: Hello, Chiara. Hello. Thank you so much for coming along. We have so many questions. We have so many things to discuss.

Chiara: Yeah.

Vitaly: And it’s okay, it’s unbelievable because every time I see your smile, every time I see you smiling, you always think about something, you always dream about something, you always have a story that you’re sharing. Right? And I really want us to start today by exploring your story first. So before we dive into storytelling, maybe you could tell us a little bit about yourself. How did you even end up in this wonderful world of design in the first place?

Chiara: Okay. So let me tell you a story. So once upon a time, there was a little girl, she was probably five years old and asked her mother, mom, is there a job where you can actually draw something every day and you can get paid for it? And the mother answered, yes, you can be a painter like your grandfather. So that little girl was me, five years old wondering if there was a job where I could actually always draw things that I like and that I see around me. And I end up doing art school. And then from that I move into design because I studied at the Polytechnic of Milan, and this is where my design journey actually started. When I was 18, I left Sicily in Italy to go in Milan, still in Italy, but in the north and discovered the world of design.

Chiara: While in Sicily, no one knew about design, of what was designed. The closest thing to design was architecture, but architects and designers and not really the same thing. So yeah, so it was quite a journey because I had to convince everyone in my family that I was going to make money out of this job. And it was quite a thing. I met the only female girl moving abroad and in Sicily we are always taking care of the girls. So it was quite a fight with the family before I could actually do what I wanted in my life.

Chiara: And the reason that I decided to study design it was because I wanted to design toys and furniture for children. So that was my goal. But I end up in doing a master in communication design, and this is where I discovered the world of branding. And I love it so much that since that I didn’t go back to toys. For me, everything is a playground. So it’s almost the same that branding and brand consulting sees what I’m enjoying right now. I love to do. And with different brand from printing to digital products.

Vitaly: I can see that for me it’s always very frustrating, I would say just to see the journey that people take when they get from one place to another in their life. And then I always feel like it’s always either hyper coincidences or just random people that you meet somewhere that kind of really motivate you. I remember a story when I was growing up, I had an uncle, or maybe it wasn’t even an uncle, I don’t even know because I saw him only once. But I remember him coming to me once and I was sitting, I was very young, very small, I don’t know, maybe six, seven years old. But he drew something, I think crocodile on a napkin at the time. And I was so impressed by that. I kept that napkin for a very long time until I think I probably lost it or so. But it had such a tremendous impact on me. Did you have those kind of things that really drove you to design or did you just want to draw things since you were a child?

Chiara: I think my inspiration was my grandfather who I never met. My mom was talking very high with him. And my grandmothee’s house, which was my family place, was full of paintings from my grandfather. So to think that someone could actually leave just drawing for me was mind blowing because I was like, wow, can you actually do this for living? I was very much discouraged by my family somehow to become a painter, but they never say no to my decision to go to art school. So that was also good. But yeah, I guess my grandfather played a big role into this decision and probably because I never met him, he became a me, like an important figure that I wanted somehow to be close to because everyone had a very strong idea and image of him.

Vitaly: But then off you went all the way to becoming a branding consultant as well at this point. But actually when I think about branding, I think that many of our dear listeners will be in the same spot as well. I often think about branding, is it just, I don’t know, logo and a bit of a tagline maybe. And sometimes I see this in advertising like a melody or this tune, which is two, three seconds long and maybe even if you go to extreme, it’s like a color palette and typography, right. But I can sense from the way you’re smiling is that you see branding as something slightly broader than that. Could you explain that?

Chiara: Yeah. Okay. You touch a very hotspot right now because I probably had a lot of discussion about this with clients. And slowly I’ve been educating them into understanding the brand is not the logo or the type line or the color palette. For me and in general for many in the field, a brand is how you make your customers feel about it when they experience your products or service. So it’s not anymore something physical, it’s something that is emotional. And it’s a very important aspect when we design anything, any touchpoints that could be an application, could be a brochure, anything really, even a stand, even a conference. That’s an experience when thinking about smashing conference, this is an experience more than of course you have your logo, you have your taglines, you have everything, but what you’re providing is an experience. And that is your brand.

Chiara: This is what you bring with you no matter where you are. If you are in San Francisco, New York or in Freiburg, it doesn’t really matter. That’s what it for me is a brand is the consistency of an experience that no matter how you decline it, then it’s always the same for the customer, for the final customer.

Chiara:So there was definitely a time where a logo, color palette or the tagline were enough to make the difference. And this was the even maybe I was not even born when this was still valid because there was an economy based on manufacturing physical products. So that was, I’m going to say that was more like there was less competition first of all, and there were less products on the shelf. So you don’t have to really show up too much. There was not talking about experience. The economy of the experience is something that we talk about today and it’s been around for a while. And this is where the brand start to become a bigger player. So when the client asks me for a logo or the color palette or the tagline, I usually call it the identity. I never call it the brand. The brand is something else and it goes just beyond all this. It’s one part is probably made of the logo, but it is never about the logo, it’s always about how people feel.

Vitaly: But then I’m wondering also as well at this point, so where does it stop, right? Because if you think about the experience that you’re providing, the website is an experience, the customer service is an experience and you will see that sometimes we have this kind of terms also in the industry, customer experience design, service design. Obviously user experience design as well. So where do you set, lee’s say the frame or the limitations of the boundaries of your work? Because if somebode’s coming to you and they want to have you to design the branding, do you also design things like voice and tone of the copy that they’re writing? Do you also design, I don’t know, things like the personality, the illustrations, the characters and whatever they want to have? Or would you say that there are particular limitations that branding typically has after all?

Chiara: Yeah, that’s a good question. It really depends by the brief and the budget of the customers. This is first of all, one important thing. This is first of all, the limit. Then of course as you say everything could be brand. And indeed, it is, you produce under the name of something that could be, I don’t know, I just seen Smashing because I just took as an example. So whatever you build under Smashing brand has to fill up the same experience. So the same experience of a community has to be consistent in everything you do. Now, when it comes to tone of voice, or things that are very specific, even a video editing, how we renowned design the entering tone of the Smashing podcast. So that also it’s part of the branding. So you usually go back to the tone of voice that you set up for the Smashing magazine maybe.

Chiara: And then you go back and say, okay, it has to be fun. Maybe we can have some cats meowing. And then you start thinking how this could come together. That doesn’t mean I’m going to be the person. I usually go into a very high level aspect of the brand. So it could be indeed the tone of voice, it could be the keywords we are going to use. And then based on that there are specific people, video editors, copywriter is going to tick my work and interpret it like it’s a script. Actually, that’s what it is. Usually that’s what a brand manual is. It works like a script so that everybody can follow it. And of course it needs some kind of interpretations too. So my work finish when I decline the brand in all the aspects, thinking of how it can be declined in a very high level.

Chiara: And after that there are specific people joining and coming and working with that script, let’s say, which usually is a brand manual, which is wider. Sometimes if you have applications, it could be more than a brand manual, it can go down to design system as well. That’s part of the branding for me because that’s another way to experience, but a digital product. There are a lot of things. So you define those things up very high level and then you find people working with you in defining the tiny bits of the brand. So it could be then, as you say, they could be the copywriting, the task, the illustrations, and so on.

Vitaly: What I really like about this approach, seeing it in this way is that it provides us with some opportunities to do something really interesting with branding. I mean, I know that you’ve been very vocal and very interested in how to connect storytelling and branding. Maybe before diving into storytelling though, I’m very curious just about your feelings today about brands per se? So if I think about brands, I don’t know, 10, 20, 30 years ago, I have this strong feeling, and please correct me if I’m wrong, have the strong feeling that many brands could be neutral in so many things. They didn’t need to take a stand, they didn’t need to have an opinion. They were for everybody. And this is how I perceive not all brands of course, but some brands. So for example, it would be very uncommon for a brand to have a political opinion about how things should be or express it on, of course not on social media, but in print or in advertising.

Vitaly: It was more about the product and really kind of advertising for marketing and all that for the product. And now I have the strong feeling that it’s impossible. You can’t be a brand and, you can be a brand, but you cannot survive if you don’t have principles that you stand behind. If you are afraid to make somebody or some of your customers unhappy, you really, if you want to speak to anybody at this point, you have to eliminate somebody just because you have to stand for something. So do you see it in a similar way when it comes to branding or would you say that many brands can be perfectly fine being neutral around topics that are happening in society or in the world?

Chiara: So that’s a very good question. Probably it’s about evolution of brand. I think the brand, every brand or any is political somehow, if you want to say it this way. So they need to stand, they need to have a culture, they need to have a belief and values. So all these words are already defining what you are standing for. Maybe in the past it was easier because you were talking to the mother with the children or the father working until late at night. Now we are talking to communities, and this is something that’s changed because of the social media. So what we do is usually all together we always influenced by what other people are doing. We feel more and more that we need to belong to something. And this is something that social media is probably, how going to say, exasperated. But the sense of community is so strong that now when a brand talks to community, it identifies himself with the community values and what they believe.

Chiara: So definitely that means that a lot of people are going to be cut out from that brand culture or values, and it’s fine. Because if you want to please everyone, probably you’re not going to please everyone anyway. So you have to be very, I’m going to say, loyal to yourself. It’s about consistency. It’s about being true to yourself. So the brand needs to stand for something. And I recall when I was at the conference in New York and there was Debbie Millman, she did an amazing talk about how brand actually stand for a cause and how they can become a real propeller for a change. And I really love that talk because she actually was nailing it because she show how everything, every movement now has become a brand and how actually this is the power of branding. And this is an amazing aspect of branding, especially when they stand for causes that are bigger than us. So as a unit, as small people, we can do very little, but as a community we can really make a big change. So that’s my take on this.

Vitaly: Yeah, that makes sense. I still have to bring up one question about branding. I know that we will want to speak about storytelling, but one thing that really surprised me, I think it was actually quite a, I don’t know, viral thing I guess for a while maybe a couple of years ago before pandemic, where all of a sudden many fashion brands decided that it’s a good idea to redesign. And they kind of rebranded and they ended up becoming quite generic. So the logos that they ended up having are very generic. The website’s very generic, even the copywriting of how the emails were sent, very generic. But then on the other hand, what has been happening also is that you look at the music industry, and you look at festivals happening and every single DJ, every single music producer needs to have their own brand. They all like whenever you have this wall of DJs that are playing, they all have their own branding in a way with their own custom design typefaces.

Vitaly: On the other hand, you also have these big institutions like banks, huge banks, they don’t know should we now be more kind of citizen-centric and then more playful or not be more conservative and traditional because we’re managing other people’s finances and all that? So I do want to ask you at this point, where do you see what would be the right way of putting it? Where do you see maybe the storytelling, right? Where do you see it fitting well and where it doesn’t? Do you think that pretty much every organization, small and large, every company, every product can benefit from integrating storytelling as a part of the experience?

Chiara: My answer is yes. And I’m completely biased because.

Vitaly: I think you’re a little bit biased. Yes.

Chiara: I believe in the power of storytelling and that’s my motto that I guess it will always be because I have a proof that this is working. But it really depends what storytelling is because what you call storytelling. Because storytelling could be, I’m telling you a story about something very specific and about our customers doing, I don’t know, I’m just thinking about one of the most famous story that I recall when I was young. It was a very child, it was with Barilla, the pasta brand worldwide. And their story was always around the family as mother, father and children. And this was the story of the family joining together and the pasta was the thing that was keeping them together because there was a time when they were eating, so they were all at school, the children were at school, the mom was probably working somewhere, the father was coming home.

Chiara: And then the moment of reunion was the pasta. So the pasta Barilla became the symbol of family. This has changed of course with time because of family now it’s broader now and we have a lot of gender consideration to do based on that, but has been changing. And this is a story, this is a story translating to another type thing. Then there is a story as an approach, like a methodology, which is what the banks and other institution could actually use. And then we use this a lot with organization where especially the not-for-profit ones, because most of the time when they work they focus on analyzing the wrong side of the story. The most of the time it’s the effects, your actions do that you need to reflect on. And this is where storytelling comes to play because through the approach you start following your customer and understanding the emotional journey.

Chiara: And this is where you start to understand probably the story of a child dying every day is not, it’s not the one you want to promote. It’s the one that you save every day is the one you want to promote because that is going to give you the climax, which is what you want in a story. So we are not going to tell, of course, the story of a child dying somewhere or someone, I don’t know, losing their house because of a earthquake happened. Unfortunately of all this disaster, we just try to tell a different story.

Chiara: And so the storytelling approach is mostly a background methodology that help us define what our message is going to be. So it’s not going to transform into an advertising necessarily, but it’s going to be, I can say the narrative behind everything we are going to do and say. So that’s the difference. It’s what could be a story. So the advertising I told you before, it’s Barilla, it’s a story that you see happen in front of your eyes. And then there is the background storytelling, the approach itself, which helps you to actually identify the right message. So I see storytelling apply to everything because there are many ways to apply it. We need to decide what’s the best case and the best scenario for applying it.

Vitaly: Talking about the best scenario, I think I have just the question that I wanted to ask for a long time about specifically how to apply storytelling. And obviously it would be very interesting to see your design process. And I heard rumors that you have just published an article about that on Smashing Magazine, so thank you so much for that. But also I know that you’ve been working with the crypto platform in trying to embed storytelling in there. And I’m just really have to ask, I’m just really curious, how do you work to integrate storytelling to this kind of environments or banks or public institutions or some very conservative environments?

Vitaly: I can see it being almost straightforward for brands that care about fashion or that care about work-life balance or they care about lifestyle brands, that’s probably relatively straightforward, although please feel free to correct me at this point. But I’m really curious how you would try to bring in some sort of storytelling in this slightly less straightforward, I would say, environments.

Chiara: Okay, let me tell you a little bit because I think there is always a misconception about storytelling. Because lee’s say, first of all, I’ll start my meetings with the client saying once upon a time as I did with you when I was talking about myself. So I usually-

Vitaly: Oh, you do not?

Chiara: No, I don’t. They will probably throw me out of the office. Like what she talking about? No, never. So the storytelling is a more subtle thing. And I never disclose in the way, hey guys, I just storytelling. They would never understand everything. What are you a screenwriter, a novel writer? I’m still a designer. So what I actually do is what I was telling you before is that I use storytelling as an approach. So when I meet them for the first time, I usually ask all the questions that help me to fill up the script, my script.

Chiara: That stays with me, it’s the behind the scene that you have seen that you can read now on the Smashing Magazine article that I wrote about the landing page we designed together for smart interface, the design pattern. So is this athlete that script, but you were never going to see it. What you’re going to see is the final movie. It’s what you’re going to see in the cinema. You’re not going to see the behind the scene. I’m not going to tell you how I’m going to fill all the blank spaces of my script or what scene I cut and what other actually went into the final movie. So what I usually do is I usually follow the storytelling structure, so the beginning, middle, and end to help the user be with me on the creative ride so that they actually know exactly what to expect, when and how so that they can actually provide me the feedback I need when I need them.

Chiara: And this is what a director of movie will do, they will ask the actor to say specific line because this is like now shot, cut, done. This is what I do. I just direct the scene and I provide specific elements that I wished them to answer. So the client answers in specific times so they don’t feel too overwhelmed. And what they see at the end is the final product, so the final movie or the final book. They will never see the correction and all the things that went through it.

Chiara: Unless I write an article as I did. So that’s the storytelling thing. So I usually go through the story brand script that Donald Miller provide in his book, The Story Brand. And then from there I start filling up the single spaces. And so the clients want to hear, of course I’m happy to, but really they want to go straight to the climax of the story. They just want to see what I came up with. So I just go very quickly through the different steps but very quickly and then go into, okay, this is a final product and this is where they actually usually they have this wow moment. I still remember actually wow moment when you saw this Smashing book six. I still remember that.

Vitaly: Oh yes, I remember that vividly because everything is coming together all of a sudden. Because what I think that I have a strong feeling that very often when people like something, it’s not just because it’s aesthetically pleasing or it’s nice typography or anything like that, it’s just something clicks and that something clicks when you actually see or not necessarily see, but you perceive the connections. So for the Smashing book and also for the landing page, the idea of having all the different elements that kind of have their own life at first, but then put together, they bring everything else to life as well.

Vitaly: But they also, the only kind of best way of how to compare it in my head is they’re playing in a orchestra. So it’s not every single element is doing their own thing. And you have this horizontal line that looks like this and you have this little characters there having this and then you have this image corners looking like that. Whenever everything really fits well together, it’s always like they’re playing in an orchestra or some sort of a symphony or anything. And I think that people notice that. They might not necessarily be able to articulate it and point it directly, I know exactly why it’s done this way, but it’s almost like you are fighting a little bit of jams or Easter eggs every now and again here throughout your design for people to discover. It’s like a treasure hunt almost. So this is at least my feeling about it. What do you think?

Chiara: Yeah, I really agree with you. And that effect is like magic for me when it happens. It’s like when you watch a movie and you really like and you can watch it again and every time you find something different in the movie that you didn’t notice the first time. And I really like this kind of feeling. If I can say, evoke this feeling, for me it’s like one tick in the box. Actually it’s one of the highest thing that I can hope for my work when somebody notice things that were there, but I haven’t told them, but they notice it. And yeah, this is amazing. This is magic for me. And that’s why again, I believe in storytelling so much because only with storytelling you can put all these pieces together to work together well and also to create sequels if you want to and expand that story even more. That’s what storytelling can help you do. And yeah, I’m happy that you felt this way because that’s the highest achievement for a designer.

Vitaly: Yeah. Also, just to maybe go a little bit more into the process. So you would literally sit down and take a piece of paper and think about the plot, thinking about the climax, think about the Aristotle’s Arc, maybe, the story arc or the heroes in the story and the rivals and I don’t know, all the different things. And really map them before you start designing. Or does it help you to design the elements that will then go into the composition or would you say that it guides you towards the structure, the layout of the page or both?

Chiara: Depends. Depends how, it depends really the kind of work. When it comes to branding, because it’s a little bit more complicated, I usually go through the values and all the elements of the story. So value, emotions and actions that we want the user to do with the brand. So all these things. And I really need to create a plot for that because there are so many variables happening when it comes to brand. When it comes to landing page, like the one we design together for your course, usually I use the landing page as a shot. And the first thing I do is really divide it, the landing page in three scenes: the opening, middle and closing scene. And then I start to fill up with the elements I already asked you about the story. For example, you remember I asked you, okay, how do you want the people to buy your course and what else are you providing?

Chiara: Is there any gift? These are all things that help me. Then I position them inside the page between the different act and this is how I start to build the story for you. And to ensure that actually we can move from one act to another one, so I put some delight. So for example, you were telling me, oh there will be a gift and for the people, I’ll name it access to the deck. And I was like, okay, we need to put it somewhere on the website. It needs to be just before maybe they sign up. So it’s going to be a delight moment or surprise that going to convince them that this is the right way to go. And I try not to use dark patterns, but of course the idea is always to propel to the final action. I just want people to finally go to the end.

Chiara: So it really depends. But for example, for your landing page, it was difficult to find the central team, the concept, how can we look different? Okay, we’re talking about video course, but yeah, but how can we make a little bit more memorable? So the people saying, oh, this seems different. It seems interesting. How we can keep this curiosity and playing around because the designers are very difficult to please. So you were talking with a very difficult audience. So I am one of them. So I try not to put myself in that shoes, of the shoes of the customer. But I have to feel some empathy about a designer who wants to discover a little bit more about UX design and design patterns.

Chiara: So the playful side of registration was probably the most difficult part because I mean was like, oh my god, we’re going to talk about food now. But yeah, he’s in the kitchen. Oh my god, everything leads over there to food experience. Oh yeah, this is what it’s going to be. It’s going to be a food experience. So that was me talking to myself, putting down the notes and was like, yeah, this is going to be, that’s it, this is all for experience. Now I need to transform the cogs into fishcakes. I don’t know how I’m going to do it, but I’m going to do it. Yeah, that was exactly what happened. So I don’t know if I answer your question, but-

Vitaly: Yeah, of course. Yeah, this is just exciting to get a little, I would say, peak behind the scenes. But I also just wondering at this point, so as you keep evolving and you create all these worlds that you then put and bring into life when it comes to designs and all, does it happen to you sometimes that you create this universe almost that actually incorporates all the different aspects of the brand, aspects of the company and the values that they believe on the culture and all that? But then the project is done, you move on to other projects, right, but they need to maintain or evolve that universe that you have created.

Vitaly: And I’m wondering, does it work? Because again, this involves everything, right? Because again, as I mentioned, when it comes to branding, it’s a voice and tones how you do your marketing, how you design your advertising spots or banners and you send out emails through your email list and all. Do you also do some sort of, I don’t know, do you write actually the script as well or would you advise companies to do that, to make sure that you actually speak in the same voice that independent on what touchpoints the customer is going to be experiencing or going through with the brand or the company?

Chiara: Usually when I, okay, lee’s talk about brand because it’s a little bit more my sphere, but I will say than it probably open up to all the other things I design. So when I approach a brand, usually they have a, what is called a design brief. That is like a blueprint for anyone approaching the design of any part of the design to read what we have decided up from. It contains the vision, the mission. I know, the brand manual could have that too, but this is very specific. It really have, it’s called design brief because you read this piece of paper, which usually is made of a few pages. And you really understand what kind of elements come into play when you design something for this company. And then you have the brand manual, that’s also combined. You get a very full picture of what it is going to be, the brand.

Chiara: Whatever you’re going to design, this has to be, someone has to be aware that are these two documents. And usually I provide both of them. If work really well for startups, especially because with startups I’ve been working for a long time with blockchain, especially the last two years. During the pandemic, blockchain was probably one of the best industry to work with and a lot of startups started and they wanted to have documents so that the product while evolving could actually follow up what we have decided. That’s always an evolving procedure with startups. So you never know how the product will end up to how it’s going to look like.

Chiara: When it comes to simply product. They’re digital like an application. Then is a little bit more difficult. I usually like to provide element bits and bites of the interface. Also extra that may be used in the future just in case just to give an idea of what it can look like. I want to call this design system, they’re not. They’re just the elements of the user interface that I provide extra. But most of the time I just leave, how I going to say, I just leave it to the interpretation of the developer to come with some ideas about that.

Chiara: And I have clients that coming back and say, oh, our developer design this bit, can you look at it? Does it look in brand for you? And sometimes it’s good. They’re being reused some pieces, which is great because what I do is usually design by modules. So they just take pieces together and they form the new component. Sometimes it’s not that good, but then when it’s bigger part of the design, maybe they come back to me and ask me, please Chiara, can we continue our story together? Can you think about something for this specific element of the website or the application?

Chiara: And now we move forward from there. It’s more working, I don’t know, I think about the sequel or I don’t know, stranger things, okay. Or maybe, oh no, maybe I will say some movies, where a different director working together and then at the end you have a nice melting pot, but it’s nice. It doesn’t look like strange. Because all of them, they pick up from where the other has left. So sometimes they commit to review some of these pieces and it’s a nice moment because you refresh a little bit of brand, you refresh a little bit what you said and you hope they will follow up from there with their own stats. Most of the time it’s easy. It’s easy then. But I usually been called back to review big pieces of design just because they didn’t feel it was quite right as they were done.

Vitaly: Yeah, I think it’s also can be almost like a never ending story when it comes to this kind of embedding storytelling involving the brand and its on. And fortunately there is a wonderful chance that our wonderful readers or readers or listeners can get to join one of your upcoming portraits where I think going to look into just that. And it’s called the Power of Storytelling and it’s taking place in March in about a month or so from now. Maybe you could share a bit of a few insights with us about what it will be about and why all the wonderful people who are listening to this now should absolutely go ahead and join you in that adventure.

Chiara: Okay, so first of all, thank you for mentioning and thank you for the opportunity to actually be able to run this workshop with the Smashing community. So it’s a quite interesting workshop because I’ve been running this live here on the island of Syros on a very basic level because the students are very young and they’re very new to storytelling. And when I decided that we can do a high level workshop online and because I imagine to be, it’s going to be a very directed workshop because we are going to start by analyzing the fundamentals of storytelling. So again, it’s not going to be once upon a time. Okay, we can start every day of the five sessions, say once upon a time, but it actually is going to be a real diving deep into the elements and methodologies of storytelling. So how we actually divide and map the user journey.

Chiara: So if you think about user journey map and heroes journey, and emotional journey, forget about it because we are going to write a script for an Oscar word application or product that every user going to love. So in general, this is what I want. I want to teach and want my student participant to learn how to use a storytelling in a way to create products that are memorable. So it’s not going to be the beautiful illustration, but it mostly like how we can make an experience memorable for the user.

Chiara: Then it doesn’t matter how you decline it. It matters that it’s consistent. So it’s a mix of user experience, probably a little bit of understanding of interface design because we are going to do it for a digital product mostly. But then after that, once you apply the and you learn these methodology, then you can apply to everything you want. Whatever it’s your project, you can just take this methodology and apply it to everything else. To your next project that is in pixel or in print or just an experience for a venue. It really doesn’t matter because that’s the beauty of storytelling and of this pluses that you can really apply it almost everywhere.

Vitaly: Well, if this is not exciting, I don’t know what is, right. So I’m very much looking forward to this as well. So on the Power of Storytelling, which is going to be taking place with Chiara in a month. Just to wrap up at this point, maybe I do have to ask one final question I like asking because it gives us a little bit of a hint about what people who are in here on the Smashing podcast are really interested in. Do you have a particular dream project, something that you maybe would love to work one day? Just to give you a few ideas, right. Some of the people we interviewed are going really big. They want to necessarily have the option to design one of the rockets that are going to go to the moon. That could be the ambition. But it could also be just something as simple as a series of children books. That’s perfectly fine as well. Do you have a particular dream projects that you would like to realize one day, Chiara?

Chiara: I’m a dreamer and I honestly, I think I live a life that is already close to what I dream of. But there are always new dreams coming up. So one thing I would like to do is on the field of storytelling, I really would like to create a little empire around this idea, methodology, that I want to share with the people. Because I’ve seen it, the magic of transformation that happens behind storytelling. So I would like to write a nice book or things that are maybe pop up book as well, something different that about storytelling and the approach and the methodologies behind storytelling. That’s one dream I had. And to become a more like a mentor in this field because I think I have a lot of to share. Just sometimes you don’t have the time to do that, to start writing a book or writing on things you’ve been through just for sharing.

Chiara: And so the other people don’t have to experience the same, they can just jump at the end of the book and read how it’s ending. So you who is the killer, this kind of thing. I would like to share more so that no one has to endure what I endure because there is no need because you can live out the experience someone else. So that’s one dream.

Chiara: And the other dream is something that I’m working because it was a dream until two years ago. Because of the pandemic it couldn’t happen before. And I’m putting together a little hub here in Syros of designers that are on the island. Because the pandemic brought so many people working remotely. They don’t want to live anymore in a big city. They want to live in a nice place with a sea two meter away. And so I start to meet a lot of people, interested in design, and there is a design school here.

Chiara: And so I think there are the right basis for creating nice hub for a nice spot on Syros to be like in the map of the destination for designers. So I’m working on it right now with some other professional creatives in the field and not only, but also musicians and food experts. So I have an entourage of people that we’ve been thinking and discussing how this could happen. And I don’t know, I keep you posted because I don’t know what is happening.

Vitaly: Oh yes, please.

Chiara: And maybe, I don’t know, Vitaly, you can do a Smashing edition, summer editions, Smashing conference summer edition on Syros one night because yeah

Vitaly: That sounds very exciting indeed.

Chiara: That would be lovely.

Vitaly: Yeah. Excellent. If you dear listener would like to hear more from Chiara, you can find her on Twitter where she’s @ChiaraAliotta. On Instagram where she is @untilsundayagency and also on her homepage, beautiful homepage, untilsunday.it. Thank you so much for joining us today, Chiara. Do you have any parting words of wisdom for people who might be listening to the show? 10 or 15 years from now, where storytelling is just everywhere. Anything that you’d like to send to the future? A message to the future generations?

Chiara: I just think about, just design always to put the smile in the face of your customers. So if storytelling is one way, please do it. If you know other ways, please share it.

Posted on

Smashing Podcast Episode 31 With Eve Porcello: What Is GraphQL?

In this episode, we’re talking about GraphQL. What is it, and how does solve some common API problems? I spoke with expert Eve Porcello to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s a software engineer, instructor, author, and co-founder of training and curriculum development company, Moon Highway. Her career started writing technical specifications and creating UX designs for web projects. Since starting Moon Highway in 2012, she’s created video content for egghead.io and LinkedIn Learning, and has co-authored the books Learning React and Learning GraphQL for O’Reilly’s Media.

Drew: She’s also a frequent conference speaker, and has presented at conferences including React Rally, GraphQL Summit, and OSCON. So we know she’s an expert in GraphQL, but did you know she once taught a polar bear to play chess? My smashing friends, please welcome Eve Porcello.

Drew: Hi Eve, how are you?

Eve Porcello: I’m smashing.

Drew: As I mentioned there, you’re very much an educator in things like JavaScript and React, but I wanted to talk to you today about one of your other specialist areas, GraphQL. Many of us will have heard of GraphQL in some capacity, but might not be completely sure what it is, or what it does, and in particular, what sort of problem it solves in the web stack.

Drew: So set the stage for us, if you will, if I’m a front end developer, where does GraphQL slot into the ecosystem and what function does it perform for me?

Eve: Yeah. GraphQL kind of fits between the front end and the backend. It’s kind of living in the middle between the two and gives a lot of benefits to front end developers and back end developers.

Eve: If you’re a front end developer, you can define all of your front ends data requirements. So if you have a big list of React components, for example, you could write a query. And that’s going to define all of the fields that you would need to populate the data for that page.

Eve: Now with the backend piece, it’s really own, because we can collect a lot of data from a lot of different sources. So we have data in REST APIs, and databases, and all these different places. And GraphQL provides us this nice little orchestration layer to really make sense of the chaos of where all of our data is. So it’s a really useful for kind of everybody all over the stack.

Drew: So it’s basically an API based technology, isn’t it? It sits between your front end and your back end and provide some sort of API, is that correct?

Eve: Yeah, that’s exactly right. Exactly.

Drew: I think, over the last decade, the gold standard for APIs has been rest. So if you have a client side app and you need to populate it with data from the backend, you would build a REST API endpoint and you’d query that. So where does that model fall down? And when might we need GraphQL to come in and solve that for us?

Eve: Well, the problem that GraphQL really helps us with, kind of the golden problem, the golden solution, I guess, that GraphQL provides is that with REST we’re over fetching a lot of data. So if I have slash users or slash products, that’s going to give me back all of the data every time I hit route.

Eve: With GraphQL, we can be a little bit pickier about what data we want. So if I only need four fields from an object that has a hundred, I’m going to be able to really pinpoint those fields and not have to load data into, or load all of that data I should say, into your device, because that’s a lot of extra legwork, for your phone especially.

Drew: I’ve seen and worked with REST APIs in the past that have an optional field where you can pass in a list of the data that you want back, or you can augment what comes back with extra things. And so I guess that’s identifying this problem, isn’t it? That’s saying, you don’t always want the same data back every time. So is it that GraphQL formalizes that approach of allowing the front end to specify what the backend is going to return, in terms of data?

Eve: Yeah, exactly. So your query then becomes how you ask, how you filter, how you grasp for any sort of information from anywhere.

Eve: I also think it’s important to note that we don’t have to tear down all of our REST APIs in order to work with GraphQL really successfully. A lot of the most successful implementations of GraphQL I’ve seen out there, it’s wrappers around REST APIs. And the GraphQL query really gives you a way to think about what data you need. And then maybe some of your data comes from our users and products, examples, some of the data comes from rest, some of it comes from a database.

Drew: I guess the familiar scenario is, you might have an endpoint on your website that returns information about a user to display the header. It might give you their username and their avatar. And you cull that on every page and populate the data, but then you find somewhere else in your app you need to display their full name.

Drew: So you add that to the endpoint and it starts returning that. And then you do your account management section, and you need like their mailing address. So that gets returned by that endpoint as well.

Drew: And before you know it, that endpoint is returning a whole heavy payload that costs quite a lot on the backend to put together, and obviously a lot to download.

Drew: And that’s been culled on every single page just to show an avatar. So I guess that’s the sort of problem that grows over time, that was so easy to fall into, particularly in big teams, that GraphQL, it’s on top of that problem. It knows how to solve that, and it’s designed around solving that.

Eve: Exactly. And yeah, I think that whole idea of a GraphQL Schema, I think is a really, it’s kind of less talked about than the query language part of GraphQL. But I really feel like the Schema in particular gives us this nice type system for API.

Eve: So anybody on the team, managers, front end developers, back end developers, anybody who is really dealing with data can come together, coalesce around what data we actually want to serve up on this API, and then everyone knows what that source of truth is, they can go build their own parts of the app based on that.

Eve: So there’s some tricky Schema management things that come up with that too. But as far as moving from microservices back to monoliths, we’re sort of doing that, but getting all of the benefits we like out of microservices still.

Drew: And do I understand correctly that the typical way of setting up a GraphQL system is that you’d have basically one route, which is the endpoint that you send all your queries to so you’re not having to... Often one of the most difficult things is working out what to name, and what the path should be that this particular query should be at. It’s returning users and products, should it be it slash users something, or slash product something?

Drew: With GraphQL you just have one endpoint that you just fire your queries to and you get back an appropriate response.

Eve: Exactly. Yeah. It’s a single endpoint. I guess, you still are dealing with problems of naming because you’re naming everything in the Schema. But as far as, I feel like a lot of companies who have made big bets on microservices, everyone’s like, what endpoints do we have? Where are they? How are they documented? And with GraphQL, we have one place, one kind of dictionary to look up anything that we want to find out about how the API works.

Drew: So, I’m very familiar with other query languages, like SQL is an obvious example of a query language that a lot of web developers will know. And the queries in that take the form of almost like a command. It’s a text string, isn’t it, Select this from that, where, whatever. What format do the queries take with GraphQL?

Eve: It’s still a tech string, but it doesn’t define where that logic comes from. And a lot of the logic is moved back to the server. So the GraphQL server, the GraphQL API is really responsible for saying, "Go get this data from where it is, filter it based on these parameters."

Eve: But in the query language, it’s very field oriented. So we just add fields for anything that we want to retrieve. We can put filters on those queries, of course, too. But I think it’s a little less direct about where that information comes from. A lot of the functionality is built into the server.

Drew: So you can mix and match in a query. You can make a request that brings back lots of different types of data in one request. Is that right?

Eve: Yeah, that’s absolutely right. So you could send a query for as many fields as your server would allow, and bring back all sorts of nested data. But that’s really how it works, we connect different types on fields. So I guess we’ll recycle my users and products idea, but the user might have a products field that returns a list of products. All of those are associated with other types as well. So as deeply nested as we want the query to go, we can.

Drew: So does that mean to retrieve the data for a typical view in your web application that might have all sorts of things going on, that you can just make one request to the backend and get that all in one go without needing to make different queries to different endpoints, because it’s all just one thing?

Eve: Yeah. That’s exactly the whole goal, is just a single query, define every field that you want, and then return it in one response.

Drew: And the queries are Jason based? Is that right?

Eve: ... Turn it in one response.

Drew: And the queries are JSON based, is that right?

Eve: The query itself is a text string, but it typically returns JSON data. So if I have the fields, then my JSON response matches exactly, and so it’s really clear what you’re getting when you send that query, because the data response looks exactly the same.

Drew: A lot of the queries it seems like are for almost like bare objects, like a customer or a product. Is there a way to specify more complex queries where business logic is controlled at the backend? Say I want to get a list of teams for a user, but only where that user is an admin of a team and where the team plan hasn’t expired, and all those sorts of real constraints that we face in everyday web application development. Can that be achieved with GraphQL?

Eve: Absolutely. So that’s the real exciting, powerful thing about GraphQL is, you can move a lot of that logic to the server. If you had a complex query, some really specific type of user that you wanted to get, all you’d need to do in the Schema is say, "Get complicated user", and then on the server, there would be a function where you could write all of the logic in whatever language you wanted to. JavaScript is kind of the most popular GraphQL implementation language, but you don’t have to use that at all. So Python, Go, C++, whatever you want to use, you can build a GraphQL server with that. But yeah, you can define as complex a query as you’d like to.

Drew: And I guess that enables you to encapsulate a lot of business logic then in new types of objects. Is that fair? You know, you set up a complicated user and then you don’t need to think what a complicated user is, but you can just keep using that complicated user and know that the business logic is implemented on that. Is that right?

Eve: That’s exactly right. So I think this is really nice for front end folks because they can start to prototype based on that. And then the backend team could go implement those functions to make that work. And then there’s kind of this shared understanding for what that type actually is and who they are, and, "What are the fields on that type?" And everything can be handled by wherever in the stack GraphQL is working. And that’s why it’s not really a front end or a back end technology. It’s really kind of both, and neither.

Drew: It sounds like it’s sort of formalizing the API and the relationship between front end and backend, so everybody’s getting a predictable interface that is standardized.

Eve: Exactly.

Drew: Which I guess in organizations where the front end and the backend are owned by different teams, which isn’t at all uncommon, I guess this approach also enables changes to be made, say, on the front end, it might require different data, without needing somebody who works on the backend to make the changes that correspond to that. You’ve still got this almost infinitely customizable API without requiring any work to be done to change it if you need new data.

Eve: Yeah, exactly right.

Drew: So is the GraphQL server responsible for formatting the response, or do you need to do that in your server side logic?

Eve: So the GraphQL server defines two things. It defines the Schema itself that lives on the server, and then it defines the resolver functions. Those are functions that go get the data from wherever it is. So if I have a REST API that I’m wrapping with GraphQL, the resolver would fetch from that API, transform the data however it needed to be, and then return it to the client in that function. You can use any sort of database functions you’d like to on that server as well. So if you have data in a bunch of different places, this is a really nice cohesive spot to put all of that data in and to kind of design all the logic around, "Where’s that data coming? How do we want to transform it?"

Drew: The client says, "I want a complex user", the server receives that in a query and could say, "Right, I’m going to look up the complex user resolver." Is that right?

Eve: Mm-hmm (affirmative).

Drew: Which is the function, and then you write your logic that your backend team, or whoever writes the logic inside that function, to do whatever is necessary to return a complex user.

Eve: Yeah, exactly.

Drew: So that could be calling other APIs, it could be querying a database, it could be looking stuff up in cache, or pretty much anything.

Eve: Pretty much anything. And then, as long as that return from the function matches the requirements of the Schema, matches what fields, what types, were returning there, then everything will work nice and harmoniously.

Drew: I guess it gives you a consistent response format across your entire API just by default. You don’t have to design what that looks like. You just get a consistent result.

Eve: Yeah, exactly.

Drew: I think that could be quite a win really, because it can be really difficult to maintain consistency across a big range of API end points, especially in larger teams. Different people are working on different things. Unless you have quite strict governance in place, it can get really complex really quickly, can’t it?

Eve: Yeah, absolutely. And I think that Schema is just such a nice little document to describe everything. You get the automatic benefit of being able to see all of the fields in that Schema whenever you’re trying to send queries to it, because you can send introspection queries and there’s all sorts of nice tools for that, like GraphQL and GraphQL Playground, little tools that you can use to interact with the API’s data.

Eve: But also, if you’ve ever played around with Postman, like to ping a REST API, a lot of those, the documentation doesn’t really exist or it’s tough to find, or things like that. GraphQL really gives you that nice cohesive layer to describe everything that might be part of that API.

Drew: Practically, how do things work on the server side? I mean, I guess you need to run a GraphQL service as part of your infrastructure, but what form does that take? Is it an entire server running on its own port? Or is it just like a library you integrate into your existing Express or Apache or whatever with a route that resolves to that service? How do you implement it?

Eve: Yeah, it’s an actual server. So kind of the most popular GraphQL implementations are Node.js servers. When GraphQL as a spec was released, the team released this reference implementation in JavaScript, kind of a Node server that served as the guidelines for all these other ones who have popped up. But yeah, you can run these servers on their own instances. You can put them on Lambda. So there’s Apollo Server Express, there’s Apollo Server Lambda; all sorts of different types of implementations that you can use to actually run this thing.

Drew: So you mentioned briefly before the concept of a Schema that the server has.

Eve: Yeah.

Drew: That gives you the ability to describe your types more strictly than just, you know, mapping a name to a resolver. There’s more involved there, is there?

Eve: Yeah. There’s a full language. So I’ve referenced the spec and I didn’t describe what it is. GraphQL itself is a spec that describes the query language and the Schema definition language. So it has its own syntax. It has its own rules for defining these types.

Eve: When you’re using the Schema definition language, you basically use all of the features of that language to think about, what are the types that are part of the API? It’s also where you define the queries, the mutations, which are the verbs, like the actions, create account login, things like that. And even GraphQL subscriptions, which are another cool thing, real time GraphQL that you can define right there in the Schema.

Eve: So yeah, the Schema really is super important. And I think that it gives us this nice type enforcement across our full Stack application, because as soon as you start to deviate from those fields and from those types, you start to see errors, which is, in that case, good, because you’re following the rules of the Schema.

Drew: Is there any crossover between that and TypeScript? Is there a sort of synergy between the two there?

Eve: Absolutely. So if you’re a person who talks about GraphQL a lot, sometimes people will tell you that it’s bad, and they’ll come up to you publicly, when you could do that, and talk about how GraphQL is no good. But a lot of times they skip out on the cool stuff you get from types. So as far as synergy with TypeScript goes, absolutely, you can auto-generate types for your front end application using the types from the Schema. So that’s a huge win because you can not only generate it the first time, which gives you great interoperability with your front end application, but also, as things change, you can regenerate types and then build to reflect those changes. So yeah, I think those things fit really nicely together as types start to be kind of the defacto rule.

Eve: ... to be kind of the defacto rule in JavaScript, they fit nicely together.

Drew: It seems to be a sort of ongoing theme with the way that TypeScript has been designed ... that’s not TypeScript, sorry. GraphQL has been designed that there’s a lot of about formalizing the interaction between the front end and the back end. And it’s coming as a solution in between the just creates consistency and a formalization of what so far has been otherwise a fairly scrappy experience with rest for a lot of people. One thing that we always have to keep in mind when writing client-side apps is that the code is subject to inspection and potentially modification. And having an API where the client can just request data could be dangerous. Now, if you can specify what fields you want, maybe that could be dangerous. Where in the sort of the whole stack, would you deal with the authorization of users and making sure that the business rules around your data enforced?

Eve: You would deal with that all on the server. So, that could happen in many different ways. You don’t have to use one off strategy, but your resolvers will handle your authorization. So that could mean wrapping an existing off REST API, like a service like Auth0 or something you’ve built on your own. That could mean interacting with an OAuth, like GitHub or Facebook or Google login, those types of things that involves kind of passing tokens back and forth with resolvers. But oftentimes that will be built directly into the Schema. So the Schema will say, I don’t know, we’ll create a login mutation. And then I send that mutation with my credentials and then on the server, all of those credentials are verified. So the client doesn’t have to worry so much, maybe a little bit of passing tokens and things like that. But most of that is just built into the server.

Drew: So essentially, that doesn’t really change compared to how we’re building rest endpoints at the moment. Rest as a technology, well, it doesn’t really deal with authorization either and we have middleware and things on the server that deals with it. And it’s just the same with GraphQL. You just deal with it. Are there any conventions in GraphQL community for doing that? Are there common approaches or is it all over the place for how people choose to implement it?

Eve: It’s honestly all over the place. I think most times you’ll see folks building off into the Schema and by that I mean, representing those types and authorized users versus regular users building those types into the Schema itself. But you’ll also see a lot of folks using third-party solutions. I mentioned Auth0. A lot of folks will kind of offload their authorization on to companies who are more focused on it, particularly smaller companies, startups, things like that. But you’ll also see bigger companies starting to create solutions for this. So AWS, Amazon has AppSync, which is their flavor of GraphQL, and they have author rolls built directly into AppSync. And that’s kind of cool just to be able to, I don’t know, not have to worry about all of that stuff or at least provide an interface for working with that. So a lot of these ecosystem tools have, I think authorization is such a big topic in GraphQL. They’ve seen kind of the need, the demand for auth solutions and standard approaches to handling auth on the graph.

Drew: I guess there’s hardly a, an implementation out there that doesn’t need some sort of authorization. So yeah, it’s going to be a fairly common requirement. We’re all sort of increasingly building componentized applications, particularly when we’re using things React and View and what have you. And the principle of loose coupling leaves us with lots of components that don’t necessarily know what else is running on the page around them. Is there a danger as a result of that, you could end up with lots of components querying for the same data and making multiple requests? Or is it just an architectural problem in your app that you need to solve for that? Are there sort of well-trodden solutions for dealing with that?

Eve: Well, I think because GraphQL for the most part, not 100% of the solutions, but almost every GraphQL query is sent over HTTP. So if you want to track down where those multiple requests are happening, it’s probably a fairly familiar problem to folks who are using rest data for their applications. So there are some tools like Paulo Client Dev Tools and Urkel Dev Tools for front end developers who are like, "What’s going on? Which queries are on this page?" That gives you really clear insights into what’s happening. There’s kind of several schools of thought with that. Do we create one big, huge query for all of the data for the page? Or do we create smaller queries to load data for different parts of the app? Both as you might imagine, they have their own drawbacks, just because if you have a big query, you’re waiting for more fields.

Eve: If you have smaller queries, there may be collisions between what data you’re requiring. But I think, and not to go off on too much of a tangent, but I’m there already. So the there’s something called the Deferred Directive that’s coming to the GraphQL spec and the Deferred Directive is going to help with kind of secondarily loading content. So let’s say you have some content at the top of the page, the super important content that you want to load first. If you add that to your query and then any subsequent fields get the deferred directive on that. It’s just a little decorator that you would add to a field, that will then say, "All right, load the important data first, then hold up and load the second data second." And it kind of gives you this, it’s the appearance of kind of streaming data to your front end, so that there’s perceived performance, there’s interactivity. People are seeing data right away versus waiting for every single field to load for the page, which yeah, it could be a problem.

Drew: Yeah. I guess that enables you to architect pages where everything that’s ... we don’t like to talk too much about the viewport, but it is everything above the fold, you could prioritize, have that load in and then secondarily load in everything sort of further down. So, we’ve talked a lot about querying data. One of the main jobs of an API is sending new and modified data back to the server for persistence. You mentioned briefly mutations earlier. That’s the terminology that’s GraphQL uses for writing data back to the server?

Eve: Exactly. So any sort of changes we want to make to the data, anything we want to write back to the server, those are mutations, and those are all just like queries, they’re named operations that live on the server. So you can think about what are all the things we want our users to be able to do? Represent those with mutations. And then again on the server, write all the functions that make that stuff work.

Drew: And is that just as simple as querying for data? Calling a mutation is just as easy?

Eve: Yeah. It’s part of the query language. It looks pretty much identical. The only difference is, well, I guess queries take in filters. So mutations taken what looked like filters in the query itself. But those are responsible for actually changing data. An email and a password might get sent with a mutation, and then the server collects that and then uses that to authorize the user.

Drew: So, just as before, you’re creating a resolver on the backend to deal with that and to do whatever needs to be done. One common occurrence when writing data is that you want to commit your changes and then re-query to get the sort of current state of it. Does GraphQL have a good workflow for that?

Eve: It sort of lives in the mutation itself. So, a lot times when creating your Schema you’ll create the mutation operation. I’ll stick with log-in, takes in the email and the password. And the mutation itself returned something. So it could return something as simple as a Boolean, this went well, or this went badly, or it could return an actual type. So oftentimes you’ll see the mutation like the log-in mutation, maybe it returns a user. So you get all the information about the user once they’re logged in. Or you can create a custom object type that gives you that user plus what time the user logged in, and maybe a little more metadata about that transaction in the return object. So again, it’s kind of up to you to design that, but that pattern is really baked into GraphQL.

Drew: This all sounds pretty great, but every technical choice involves trade-offs. What are the downsides of using GraphQL? Are there any scenarios where it’d be a really poor choice?

Eve: I think that the place where a GraphQL might struggle is creating a one-to-one map of-

Eve: ... struggle is creating a one-to-one map of tabular data. So let’s say you have, I don’t know, think a database table with all sorts of different fields and, I don’t know, thousands of fields on a specific type, things like that, that type of data can be represented nicely with GraphQL, but sometimes when you run a process to generate a Schema on that data, you’re left with, in a Schema, the same problems that you had in the database, which is maybe too much data that goes beyond what the client actually requires. So I think those places, they’re potentially problems. I’ve talked to folks who have auto-generated Schemas based on their data and it’s become a million line long Schema or something like that, just thousands and thousands of lines of Schema code. And that’s where it becomes a little tricky, like how useful is this as a human readable document?

Eve: Yeah. So any sort of situation where you’re dealing with a client, it is a really nice fit as far as modeling every different type of data, it becomes a little tricky if your data sources too large.

Drew: So it sounds like anywhere where you’re going to carefully curate the responses in the fields and do it more by hand, you can get really powerful results. But if you’re auto-generating stuff because you’ve just got a massive Schema, then maybe it becomes a little unwieldy.

Eve: Yeah. And I think people are listening and disagreeing with me on that because there are good tools for that as well. But I think kind of the place where GraphQL really shines is that step of abstracting logic to the server, giving front end developers the freedom to define their components or their front ends data requirements, and really managing the Schema as a team.

Drew: Is there anything sort of built into the query language to deal with pagination of results, or is that down to a custom implementation as needed?

Eve: Yeah. Pagination, you would build first into the Schema, so you could define pagination for that. There’s a lot of guidelines that have sort of emerged in the community. A good example to look at if you’re newer to GraphQL or not, I look at this all the time, is the GitHub GraphQL API. They’ve basically recreated their API for v4 of their public facing API using GraphQL. So that’s a good spot to kind of look at how is a actual big company using this at scale. A lot of folks have big APIs running, but they don’t make it public to everybody. So pagination is built into that API really nicely and you can return, I don’t know, the first 50 repositories that you’ve ever created, or you can also use cursor based pagination for returning records based on ideas in your data. So cursor based pagination and kind of positional pagination like first, last records, that’s usually how people approach that, but there’s many techniques.

Drew: Are there any big got yous we should know going into using GraphQL? Say I’m about to deploy a new GraphQL installation for my organization, we’re going to build all our new API endpoints using GraphQL going forward. What should I know? Is there anything lurking in the bushes?

Eve: Lurking in the bushes, always with technology, right? I think one of the things that isn’t built into GraphQL, but can be implemented without too much hassle is API security. So for example, you mentioned if I have a huge query, we talked about this with authorization, but it’s also scary to open up an API where someone could just send a huge nested query, friends of friends, friends of friends, friends of friends, down and down the chain. And then you’re basically allowing people to DDoS you with these huge queries. So there’s things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it’s not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible got you with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you’ve co-written the O’Reilly ’animal’ book with Alex Banks called Learning GraphQL. But you’ve got something new that you’re launching early in 2021, is that right?

Eve: That’s right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We’re going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we’re just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We’ll talk about authorization strategies and all sorts of different things. So it’s just kind of collecting the things that I’ve learned from teaching over the past, I don’t know, three or four years GraphQL and putting it into one spot.

Drew: So it’s a video course that... Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it’s a big hefty course so you can work through it at your own pace. Absolutely.

Drew: Oh, that sounds really good. And it’s graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I’m looking forward to seeing that released because I think that’s something that I might need. So I’ve been learning all about GraphQL. What have you been learning about lately?

Eve: I’ve also been looking into Rust lately. So I’ve been building a lot of Rust Hello Worlds, and figuring out what that is. I don’t know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she’s @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Do you have any parting words?

Eve: Parting words, have fun with GraphQL, take the plunge, you’ll enjoy it, and thanks so much for having me. I appreciate it.

Posted on

Smashing Podcast Episode 29 With Leslie Cohn-Wein: How Does Netlify Dogfood The Jamstack?

In this episode, we’re asking what it looks like to dogfood the Jamstack at Netlify. Can you deploy an entire app to a CDN? Drew McLellan talks to Netlify Staff Engineer Leslie Cohn-Wein to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s an award winning frontend specialist originally from Austin, but now living in Dallas, Texas, via a stint in New York city. During that time working for agencies, she built sites for clients, such as Nintendo, WorldPride, and Jerry Seinfeld. She’s now a staff frontend engineer at Netlify, where amongst other things, she works at building out the application customers use to manage their service and deployments. So, we know she’s an accomplished frontend engineer, but did you know, when living in New York city, she served as an assistant chili cook-off judge three years in a row. And that one’s actually true. My smashing friends, please welcome Leslie Cohn-Wein. Hi, Leslie. How are you?

Leslie Cohn-Wein: I’m smashing.

Drew: I wanted to talk to you today about how Netlify sort of eats its own dog food, to use that charming expression, when it comes to building on the Jamstack. I should put this in context a little bit by saying that up until a few months ago, we worked together on the same team at Netlify. And when I got there, the development process was actually really foreign to me, even after 20 years as a developer. I thought it was just really fascinating and well worth exploring a bit, with a wider audience. I should probably point out that we’re talking about this because it makes a genuinely interesting case study and it’s not a sponsored big ad for Netlify. Everyone should check out Vercel. But I think there’s a lot of valuable things that can be learned from discussing it, particularly from a Jamstack point of view. Because Netlify is a really big proponent of the Jamstack approach and the service is sort of offered to the customer and is built around that idea of building Jamstack projects. But the service is also built using those principles itself. Isn’t it?

Leslie: It is, yeah. A lot of people sort of think of that Jamstack architecture as static sites, but we’re really dogfooding what it means to build a Jamstack app with the Netlify frontend. Because it’s a React app that is a full Jamstack app that we deploy Netlify on Netlify so... Yeah, we’re really trying it out and pushing the limits of what’s possible.

Drew: I think there’s sometimes this idea that Jamstack is great for just static sites, as you say, and the API aspect comes in if you want to send a form to an email address and you can just do something easy like that, but you can possibly build a whole web app that way. But, you are doing that aren’t you?

Leslie: Yeah, absolutely. Our app, talking specifically about what you see you if you login at app.netlify.com, is powered by... we’ve got an internal REST API, but the frontend, like I said, is pure Jamstack. So, we have our own build step, we watch the app as it builds in the app, and we deploy on our own system.

Drew: So, when there are a backend process involved, and there’s always going to be some sort of level of backend processes, you know, persisting data or, in Netlify’s case, starting off with a deployment or what have you, that backend just kind of gets built as a series of APIs that can then be consumed by the frontend?

Leslie: Yeah, so there’s a couple of different models of how you can make this work. In most cases, in our app, we use client-side fetching with React, right? So, we serve sort of a static shell of the app and then we fetch the user’s information from our internal REST API at the request time. Jamstack is interesting because there’s some things you can pre-build, and we try and rely on that when we can. And then when we’re talking about some of the more dynamic data, we’ll use that client-side fetching in order to make sure that we’re pulling in the freshest data.

Drew: I think it surprised me, when I started working on the app, just how much is being achieved in the frontend, particularly when it comes to interacting with external APIs and things. I know that when Netlify interacts with your Git provider, so it goes to GitHub and gets a list of list of repos, that’s all happening between your browser and GitHub. And apart from maybe the... going through a server-less function that’s putting some secrets on the request or something lightweight like that, most of that is just happening in a Jamstack-y sort of way. It’s not going through a Netlify sort of core backend infrastructure. So, that’s quite fascinating. That really is going so much further beyond just a static site with a few API calls to do little things. That’s that real core functionality, isn’t it, that’s being implemented in the browser?

Leslie: Absolutely. It really pushes, I think, that concept of what a frontend developer engineer is, right? And it’s something that pushes me, as a frontend engineer to be better and to think more about those sorts of... the API layer, which is not something that I’ve traditionally have been as close to. I work more in UI and colors and design systems, and so it really... I actually have found that working on a Jamstack app at scale, has pushed me to be a better developer.

Drew: Being a frontend developer isn’t knowing CSS back to front, although that’s part of it. It is not knowing HTML back to front, but though that’s part of it. It’s also straying into this territory that was traditionally the preserve of a backend engineer, which is quite interesting. Does Netlify use new server-side rendering for-

Leslie: Not that I’m aware of.

Drew: So, it’s all just literally done, as you say, you serve a shell, and then it gets populated with requests back to different API end points to sort of populate it all.

Leslie: Exactly.

Drew: And you say it’s a React app?

Leslie: Yes. Yes. React. We use React Redux right now, and right now we’re PostCSS, but we’re experimenting with our CSS architecture as well.

Drew: Aren’t we all? So, you build the app in React and then you deploy it on Netlify?

Leslie: Yes. Maybe my favorite part of that whole process is the magic of Deploy Previews, which we get through Netlify. So, what happens is, you’ll... you’re working in GitHub, you push up your PR. So, you open up your PR in GitHub, and that is going to automatically create a build of your Deploy Preview of the app. So, we actually use Deploy Previews of the app itself to test out, to make sure everything is working the way it should. We run our tests. That’s what we use to manually verify during code review. So, we have sort of all of that continuous deployment set up right from GitHub.

Leslie: And then one of the other cool things that we have set up is that we actually have a couple of different Netlify sites that are pulling from the same repository where our app lives. So, we have both our app, we’ve got an instance of Storybook that has sort of our UI components for the app. So, we have both our app itself, we’ve got the Storybook UI components, and we have basically a Netlify site that shows our Storybook UI. And then we also have a third site that runs a webpack bundle analyzer. So, it’s a visual UI that gives you a tree map, visualization of all of the apps bundles, and we can sort of gauge their size, and it’s just a reminder for us to double-check sort of. As every deploy of the app goes out, we can check and make sure we’re not doing anything weird with our bundle size there. So, all three of those sites get generated in one Pull Request of the app. So, you’ll get links to preview, your Deploy Previews essentially, of both the app Storybook and to that app profile for us to check through.

Drew: And with the Deploy Previews, that essentially kind of becomes your staging environment, does it?

Leslie: Exactly. We don’t really run a traditional staging environment, because we really trust that our Deploy Previews are essentially what is going to go live when we hit that merge button and kick off the official build of our main branch in our main app. So, I love that we can rely on Deploy Previews as the staging environment. We really trust that it’s going to match production. We’re building it with all of the production variables, everything that... environment variables, all of that stuff gets built in the Deploy Preview. So, it’s pretty much like a no worry situation. As long as your Deploy Preview is working, you know that the app is going to work as well.

Drew: And I guess, as an organization, if your Deploy Preview isn’t matching what gets put live, then that’s a service issue that Netlify wants to resolve. So, it actually works out quite nicely from that point of view. So, you’ve reviewed a Deploy Preview, everything looks great, the PR gets merged. What happens then?

Leslie: So, because Netlify runs all of our continuous deployment, essentially we have it all hooked up so that any merge into our main branch will automatically kick off an official production deploy with the app. So, typically if you’re the developer who has merged your own PR, you’ll pop into the actual... you have to make sure, double check your tabs, because if you have a Deploy Preview of the app open and the app, you got to make sure... you usually want to follow along in the real app. So, you got to check your tab. But, yeah, in the app, you usually go in, you can watch the build logs for that merge that you just kicked off, so it’s all automatic. And then as soon as those build logs complete, and the site is live, all you have to do is refresh your browser window and you’ll see whatever you had just deployed, should be updated in the app.

Drew: And let’s say you catch a problem once it’s gone live, what do you do then?

Leslie: That’s a very good question. And maybe one of my favorite things about using Netlify even before I worked at Netlify, this was like a little bit of magic to me, because Netlify has sort of baked in, what we call, rollbacks. So, essentially every deploy on Netlify... because we’re using this Jamstack architecture, every deploy is atomic. So, what that means is you have this full history of every sort of deploy you’ve ever made on a site, and you can instantly roll back to any one of those. So, if we accidentally deploy a bug or something is broken, the first thing that we usually do is we actually stop that continuous integration. So, we’ll go in and it’s just one button in the Netlify UI that you say, "Stop auto publishing," and what that will do is it stops that connection with GitHub. So, if my teammate is suddenly also merging their PR, we’re not going to re-introduce the bug, nothing like that is going to happen.

Leslie: So, we stop all those auto deployments. And then all I have to do is go back into my deploys list and find the last working deploy, hit one more button that says, "Publish this one," and it goes live. So, what that does, is it takes that pressure off to be able to really go back, look at the code, figure out what actually happened. Sometimes that means doing a Git revert on your main branch and getting the main branch back where it needed to be. And sometimes it’s a hot fix or you go off on a branch and you get it fixed and you don’t really even need to worry about reverting in Git. And then, when you’re ready to go back, you make sure everything’s working on your Deploy Preview of the app, and you can just reset all that stuff back up. So, as soon as you start those auto deployments, you’re basically back in business.

Drew: So, I’ve spotted a problem here.

Leslie: Uh oh.

Drew: You’re using Netlify to deploy changes to the Netlify app. What if the bug that you’ve deployed stops you rolling back? What do you do then?

Leslie: I have nightmares. No. Actually, we have a couple of ways that could handle that. So, if we take down the app and we can’t use the UI to go through this process, our Deploy Previews actually run against our production API. So, what that means is, even if the app isn’t working, we still have those atomic deploys. So, if you have a link from GitHub, perhaps from an old or recent PR, and you have that Deploy Preview URL, you could actually access the Deploy Preview of the app and make whatever change you need, go back and publish an older deploy from the Deploy Preview. And it’s still hitting our production API, so that will still affect the app, and then that will bring the app back up. It’s like sort of exploding brain emoji there, but it’s one way to do it. We could also publish an older deploy from some of our backend systems. We could get our backend engineers to publish that for us. Or you can always use Git to revert and try and push that up, but it’s a little bit scary because you can’t watch what you’re doing.

Drew: I guess you just need a very clear mind to manage that situation.

Leslie: Yeah.

Drew: But it’s totally recoverable from, it sounds like it.

Leslie: Yeah. Well, and once you’ve published your working deploy, all the pressure’s off. That’s really the nicest part. And I found this working in agencies as well. Being able to roll back was really a lifesaver to... It also makes you less worried about publishing new changes. If you break something, it takes a second to roll it back, which fits very nicely with the sort of move quickly and get things out model.

Drew: Definitely. I think typically this sort of whole workflow works best when you’re dealing with really small changes. I mean, ideally you want to create a branch, implement a small change, raise a PR, and then get that merged back as quickly as possible. Which obviously works fine for tweaks and bug fixes and little things, but it doesn’t work so well for major feature work when that feature might take weeks or maybe even months from it starting to it being ready to deploy. How do you manage that sort of process?

Leslie: Yeah, that’s a great question. So, we’ve recently started using feature flags a little bit more. Before I go talk a little bit more about how we do that, I’ll talk about what we used to do. So, before we were using feature flags, I think everyone’s sort of familiar with the idea of the long running feature branch. We all sort of hate them, right? But we would work on our smaller PRs. We would merge each of those individually, after code review, into this longer running feature branch. So, you would just basically have all of your new feature in one place, you could have one Deploy Preview that you can test that new feature with. Sometimes this model sort of required coordinated deployments across other teams. So, when we were ready to say, "Okay, this feature branch, we’re ready to merge it and get it live," occasionally that meant, "Okay, you got to make sure backend’s already deployed their change," so whatever API work that we’re doing in our feature is ready to go. If there are docs on our doc site that need to go live at the same time as the feature, you sort of have to coordinate and hit the buttons at the same time.

Leslie: This model is... it worked for us, but you’re right, that it wasn’t maybe the smoothest. It’s actually sort of funny, our co-founder and CEO at Netlify, Matt Biilmann, actually launched our analytics feature using this process onstage at Jamstack Conf London last year. So, he used our lock deploys feature to basically take the Deploy Preview of the new feature of analytics and publish it live on stage. So, that was pretty cool.

Leslie: But, like you said, it’s... you have a little less confidence. Everything is still sort of hidden in this Pull Request. It becomes a bit unwieldy. Someone has to approve that final Pull Request that usually is quite large. That’s a little overwhelming. So, nowadays we’re mostly using feature flags. We use a service called LaunchDarkly, which lets us basically wrap our new feature UI with these flags, so that we can keep continuously merging code, even if the UI isn’t something we want customers to see. So, you just make sure in the production environment that your feature flag is off, we can deploy the code, merge it, and no one... assuming that you’re a general user, you’re not going to see that new UI.

Drew: So, a feature flag is basically just like a switch in the code that says, "If this feature is enabled, use this new code, otherwise use this old code."

Leslie: Exactly.

Drew: Does that mean that you get sort of a messy code base with all these forks in place? How do you deal with that?

Leslie: Yeah, I think that’s... anyone who uses feature flags probably is used to this sort of battle of when do you clean up the feature flags? How long do you leave them there? We’ve sort of landed on about two weeks after a major feature gets released, is we have reminders. Luckily, LaunchDarkly actually recently set up a feature that will notify Slack. So, you can hook it up with Slack, and it’ll just tell you, "Hey, your feature flag has been... You’ve been live in production for two weeks. It’s about time to go make sure you clean up your flag in the code."

Leslie: So, we do try and, and clean it up pretty quickly, but it is, in that time in between, it is nice to know the flag is still there. Even if you’ve released the feature, it means that again, with one click, you can go in and toggle that flag back off it there is a bug, if there is something that pops up. So, we like to leave them in for a little bit, just while the feature is really baking, while people are getting used to it, to make sure there aren’t any major issues. But then we do try and go back into the code and it is a bit of cleanup, so it’s not an ideal process, but usually removing the flag doesn’t take very long, you’re just deleting a couple of lines of code.

Drew: So, I guess the simplest approach to implementing a feature flag could just be a... like a config variable in your app that says, "This feature is on or off," but then you, you need some way to make sure that it’s on for the right people and off for the right people. And I guess that’s where a service like LaunchDarkly comes in, because it takes that... I mean, it takes basically what is switching on and off a variable to an extreme level, doesn’t it?

Leslie: Yes. Yes. That’s exactly it. So, there are ways we could have, even without LaunchDarkly, basically set up a config variable ourselves that we sort of manage on our end. One of the things I love about LaunchDarkly is that there are different environments. So, what we can do is essentially turn on a feature flag for our Deploy Previews. So, anyone who’s viewing internally at Netlify, a Deploy Preview of the app can have access to the new feature, can test it out, but then again, as soon as it goes live in production, that flag is off. So, there’s very little... again, you sort of have to check your tab and make sure you’re aware of sort of what segment you’re in, because you don’t want to surprise yourself and think you’ve launched something that you didn’t, you have to be a little bit careful there. But, in general, it works quite well, and LaunchDarkly lets you also do these selective rollouts. So, you can roll out a feature to some percentage of your code base or to a specific user segment, people with a specific type of plan or a specific type of user. So, it allows you a lot more control over who you’re sort of releasing to.

Drew: Yeah. That can be really powerful, I guess, particularly with new features or features that you might be expecting to resolve an issue. Maybe you’re enhancing a feature to make it more understandable, you can maybe try it with 10% of the users and see if they’re experiencing the same problems and...

Leslie: Exactly. It’s a great way to get feedback as well, yeah.

Drew: I guess using LaunchDarkly in this way, rather than rolling your own solution, is kind of another aspect of the Jamstack approach, isn’t it? It is just using an API that gives you this functionality without having to worry about how you implement that yourselves and how to develop that and how to maintain it and keep that so that you can just outsource it, say, "Right, we’re going to use this API and everything else is taken care of."

Leslie: Yep. Yep, exactly.

Drew: So, this approach enables you to be committing small bits of new features to production essentially, but they’re just sort of hidden behind the flag. And then when everything is ready to go, you can just flip the flag and you can quickly switch it back again if something goes wrong.

Leslie: Yep, exactly. It makes our launches a little bit less exciting. It used to be you’re pressing these big buttons and there’s all this code that’s getting merged and you’re watching your build logs and it’s this moment of anticipation. And now it’s you hop on a Zoom call, you click one button, and it’s live.

Drew: Yeah. I think the last feature launch, I worked on an Netlify, we used this approach. And it had been weeks of work for a whole team of people, and we got on a Zoom call to coordinate the release, and everyone confirmed that their parts were ready. And then I flipped the feature flag and turned it on for all users, and that was it.

Leslie: Done.

Drew: And it was over in a few minutes and it was really anticlimactic.

Leslie: Yeah, it’s sort of sad.

Drew: There was no sweaty palms, there was nothing, which of course is exactly what you want, isn’t it? That’s how you know you’ve got a robust process, if turning something on for everybody is just not a big deal.

Leslie: Exactly. And if you got to roll it back, again, it’s just that simple, it’s that one click. It relieves some of that pressure, anxiety.

Drew: So, presumably, I mean, not all changes are going to be just frontend changes. Sometimes there are going to be backend changes, and presumably they have their own feature flags as well in most backend systems. So, you mentioned docs as well. Is there a way to coordinate all of this together? Does everybody just flip their flags at the same time? Or how does that work?

Leslie: Yeah. So, this is an area that we’re sort of actively working on across the teams right now at Netlify, is working towards a solution that would allow us to perhaps tie everything to one single flag in LaunchDarkly, that all of our systems are using, all of our code bases are using. So, in an ideal world, we would be able to flip a flag and say, "Okay, this is toggling on the new API end point that is also being consumed on the frontend with this new UI that is wrapped in a feature flag, as well as this portion of the doc site, that has new information about this new feature." And you flip that one flag in it impacts all of those repositories. We’re not quite there yet. We’re working through that, but I’m excited to see sort of if we’re able to get all of that coordinated and working.

Drew: Netlify, as a service is very much sort of tailored to building sites in this way. Does the work that you and your team are doing using the product, actually influenced the product development at all?

Leslie: I’d say that it definitely does. Everyone always says you are not your user, which I think is true most of the time, except sometimes when you are your user. Which is funny at Netlify because I think most of the people on the frontend team in particular, are people who have used Netlify before as a product. And certainly because we’re using Netlify to deploy Netlify we run into the same challenges that I think some of our users do. So, in some ways, if we run into a problem, we’ll try and bring it up to the rest of the company. We’ll mention it in an engineering call or we’ll pull in our CTO and say, "Hey, this is something that we’re struggling with. Is there something we could build into the product that would make this easier for us and for all of our users who are deploying similar things that we are?" So, it’s sort of a unique position to be in, but it’s fun to see how the product roadmap gets developed.

Drew: I guess there’s probably few people out there using Netlify quite as intensively as Netlify does itself.

Leslie: Yeah. Yeah. I think that’s about right. I stare at Netlify both when I’m building it and when I’m deploying it, so I’m pretty familiar with it.

Drew: And then at the weekend you work on a side project and you find yourself back in Netlify again.

Leslie: Yeah. That’s actually very true. Yeah. Yes. yes, indeed.

Drew: Do you have any examples of like how the product direction has been influenced at all by the work that the team’s done?

Leslie: Yeah. So, we’ve pretty recently launched a new sort of landing dashboard for the app that we’re calling The Team Overview. So, it used to be when you logged into Netlify you’d land on the site’s page, which would just basically be a long list of your sites. And we wanted to give people a little bit more of a mission control area where they can sort of see a lot of important information at a glance, get access to things that are going to be most useful to them. And so, that was a new feature that we built. In the initial iteration, we’re trying to get it out quickly, we have a little card on that UI that links to your latest builds. It shows you any build across your whole team, should show up in that card.

Leslie: And at first, we actually hadn’t linked those up to the build... the display log itself. So, it was just a list where you could check it out. You could click into the builds page to get a sort of similar view. But I was actually working on something over the weekend, a personal site, and I had this team overview turned on and I was annoyed because I realized I logged into Netlify and I wanted to go check out this build that was happening of my project, and I couldn’t just click on it and get right to it. I had to click into the builds page and then click again. So, the next day at work, I went in and added that change and linked up those builds because it was bothering me. So, that was one example of sort of just realizing by using the product, that there was a very small opportunity to improve it. And we took that.

Leslie: But we do have some other examples, too. Probably a little bit more impactful. One is that we sort of added this form detection feature. So, a little bit of background, if you’re not familiar, Netlify forms is a feature in Netlify that lets you build a frontend form. And Netlify sort of does all the backend work of managing submissions. It’s sort of like your database for your form that you’ve built on your frontend. It means you don’t have to write any server-side code or a whole lot of extra JavaScript to manage form submissions. Really any site that you deployed to Netlify, as your build is happening, our build bots are parsing your site’s HTML at deploy time to basically detect if you’ve got a Netlify form that Netlify needs to pay attention to and manage. And this form detection, the build bot’s looking for that, is enabled by default.

Leslie: But what that means is that, as you can imagine, that eats up a little bit of your build time because the bots have to go and look for this extra step. So, the Netlify app itself, actually, we’re not using, we don’t have any Netlify forms on the app right now. So, this is a step that basically is adding a little bit to our build time, but it doesn’t necessarily need to happen. So, Netlify actually built a new feature that allows any user to disable that form detection. What that means is you can turn that setting off in your site settings, the build bots realize that there’s nothing they need to look for, so you save that little bit of extra processing time in the builds.

Drew: I guess that’s great in terms of productivity, because things just complete a little bit quicker.

Leslie: Exactly.

Drew: But also, as a metered service, enables you to get more out of the sort of allowances that you’ve got.

Leslie: Yep. Exactly. And so, this was something that we also heard from some of our users and customers, and it was something we sort of noticed as well. It was, "Well, we don’t need this extra step in our own product. So, is there a way, something we could give to all of our users to make everyone’s life a little easier, make everyone’s build a little faster if they’re not using this feature?"

Drew: Is there a danger... I mean, you say that you’re not your user, but with Netlify you often are your user. Is there a danger that, with the intensity that you use the product, that you might overlook the sort of users who are only using it very lightly and everything might get too complex and too advanced, and it’d just become very difficult to get started with?

Leslie: That’s that’s a great question. We also have really built out our user research function at Netlify and our data science function, and I think, overall we trust them a lot more than my anecdotal experience using and deploying the app. But I think all of that data sort of comes together to allow us to get a better picture of who’s using Netlify, what type of user are we speaking to? There are people with different types of needs. We’ve got folks on our starter teams who are managing blogs and personal sites, and we’ve got huge enterprises as well, who are launching big marketing campaigns and big web apps, not so dissimilar from Netlify itself. So, it’s exciting to sort of see the user base grow and to think about all these use cases and to figure out how we can cater to all of those users. And certainly using more of our research functionality to lean on understanding who those users are, not just our internal experience.

Drew: Tell me, Leslie, about the screenshot service that Netlify has in place? Because I found that really interesting.

Leslie: Yeah. In the UI we have... when you deploy a site on Netlify, in the UI, we have a little screenshot that shows you typically what the homepage of the site you felt looks like. It’s actually funny we brought this up, because I was listening to Chris Coyier his episode on Serverless not so long ago, and he was talking about how they do screenshots in CodePen as well, which is actually not so dissimilar to how Netlify does it. But basically we run Puppeteer to capture that screenshot of the user site, and the way that it’s all run is that it’s set up with a Netlify function. So, this is again, an example of us dogfooding our own product. So, essentially we use this end point that is a Netlify function inside our own app to return the URL of that image of the screenshot, that then we can serve that up in the app.

Drew: So Netlify functions are Netlify’s implementation of a Serverless function, aren’t they? Where you basically just drop a JavaScript file into a designated folder as part of your source, and then that becomes available to be executed as a cloud function.

Leslie: Yes, exactly.

Drew: Super smart, isn’t it?

Leslie: Yeah. It’s brilliant. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you’re basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it’s exciting because there’s so much you can do, but that can make it a little intimidating also because there’s so much you can do.

Drew: I sort of find it funny how it’s like... that’s seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it’s just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Yeah.

Drew: This sounds like a really nice way to be working, and a very modern way to we’re working, but it can’t be without its challenges, can it?

Leslie: Absolutely not. I think I’ve spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there’s a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there’s probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there’s an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we’re more familiar with or more comfortable using. So, in terms of challenges, I think it’s opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there’s so many different ways on there to... with the tooling that’s available, to be able to attack a particular problem. At Smashing, we probably shouldn’t say there’s more than one way to skin a cat.

Leslie: Yikes.

Drew: What’s interesting about the workflow as well, is that it’s really intensively Git based, which I think suits... it’s really developer friendly, isn’t it? As a frontend engineer, something that’s Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I’m very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you’re talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it’s really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone’s going to have to rebase, everyone’s going to have to communicate, or at least be aware of what happened. And so, it’s not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you’re doing, then you’ve got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that’s one of the other things that Jamstack... You’re introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they’re getting. So, I always try to keep that in mind when I’m frustrated about how long something is taking to build, but certainly I think that’s an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don’t deploy a build if a test fails, but at the same time, then you’ve got to run all those tests.

Leslie: So, it’s this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you’re doing your due diligence before you actually deploy something. And we’re playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just... you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you’re then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn’t the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of... have used Netlify for side projects and other things that they’re working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we’re growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing... assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I’m just aware of who’s managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I’ve seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there’s an error that got thrown, either from Netlify or from your own code, it’d be nice to be able to link directly to that log line. So, that’s sort of a fun, small improvement that I’ve been thinking about a bit. And that’s not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I’m still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be... have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it’s really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn’t want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn’t it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it’s exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover... he covers a range of topics, but does some Jamstack specific ones as well. And it’s a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we’ve been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that’s always a big question. I mentioned Cypress before, we’ve been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I’ve been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that’s been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I’m starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and... Yeah.

Drew: That’s exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she’s @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?

Posted on

Community Resources, Weekly Newsletter, And Boosting Skills Online

Community Resources, Weekly Newsletter, And Boosting Skills Online

Community Resources, Weekly Newsletter, And Boosting Skills Online

Iris Lješnjanin

Improvement is a matter of steady, ongoing iteration. If you’ve been around for a good while, you’ll know that Smashing has been through a good number of changes in the past: a new design, a new layout, a new technical stack, and so much more. Still, it was always done with quality content in mind.

For example, we recently rearranged the navigation bar at the top of the page — have you noticed? Take a closer look, and you’ll find some neatly curated guides on major topics covered in the magazine, conference talks, and elsewhere. Each guide brings together the best we have on that subject, to help you explore and learn. And speaking of guides, we just published a comprehensive SEO guide earlier today!

Alongside our guides, printed books, eBooks and printed magazine, we’re thrilled to have yet another addition to our smashingly cherished gems: meet our brand new Interface Design Patterns Checklists. Co-founder of Smashing Magazine, Vitaly Friedman, has been collecting, curating and refining each checklist for years — we’re convinced that this deck of cards will prove to always be useful when designing and building any interface component. Really.

If you’d like to (virtually) meet Vitaly himself and dive deeper into the bits and pieces of smart interface design patterns, you can attend his upcoming online workshop on Smart Interface Design Patterns (2020 Edition) where you’ll explore hundreds of practical examples over 5×2.5h live sessions.

Please note that the cards are currently only available in PDF format — we’re doing our best to print them as soon as it’s possible to ship worldwide!

Smart Interface Design Patterns
100 checklists cards on everything from carousels to web forms — carefully curated and designed. Get the PDF →

Upcoming Online Events: See You There?

With still so many COVID-coaster emotions, we’re very sad about the ongoing situation and not being able to meet you in person, so we have decided to move all of our physical events for 2020 online in order to stay connected with our dear and valued community.

Despite the circumstances, we’re proud to have so many brilliant speakers on board, and to make the best of it all, you don’t even need to travel to meet them. So, we promise to deliver the same community feeling as much as possible, but from your very own home (office).

  • SmashingConf Live (August 20–21)
    An event full of interactive and live sessions by a line-up of inspiring and knowledgeable speakers.
  • SmashingConf Freiburg Online (Sept. 7–8)
    Our ‘hometown’ conference is now being moved online and open for everybody to join in!
  • SmashingConf Austin Online (Oct. 13–14)
    We’ve combined the initial Austin and New York events that will take place in a timezone suitable to everyone.
  • SmashingConf San Francisco Online (Nov. 10–11)
    Two full days of front-end, UX and everything else that connects us and helps us get better at what we do.
We always look forward to learning, sharing and connecting with each other. Join in the fun — we provide live captioning in English too!

For the conference experience, we’re using Hopin. It turned out to be the best option in terms of quality, reliability and accessibility, with reception and networking area, sponsor booths and breakout sessions. To join in, no installation is needed! Before the event, we’ll send you a magic link, so you can jump right into the conference.

Learning And Networking, The Smashing Way

We know everyone’s busy — and may even have homeschooling and other things to figure out on top of that — so we want to support you while not wasting any of your precious time. We’ve broken down our workshops into 2.5h-segments across days and weeks, so that you can learn at your own pace and in your own time (workshop materials and recordings included!).

Please do take a look at our bundle discounts if you want to attend more than one workshop — you can save up to US$100 and have a little more to spend on ice cream! 😉

August 17–31 Behavioral Design Susan and Guthrie Weinschenk Design & UX
Aug. 19 – Sept. 3 Front-End Testing Umar Hansa Front-end
Aug. 20 – Sept. 4 Designing For A Global Audience Yiying Lu Design & UX
September 1–16 Jamstack! Jason Lengstorf Front-end
September 10–11 The CSS Layout Masterclass Rachel Andrew Front-end
Sept. 17 – Oct. 2 Vue.js: The Practical Guide Natalia Tepluhina Front-end
Sept. 22 – Oct. 6 Smart Interface Design Patterns, 2020 Edition Vitaly Friedman Design & UX
Nov. 12 – Nov. 27 Build, Ship and Extend GraphQL APIs from Scratch Christian Nwamba Front-end
Attending a Smashing online event means that you’ll be taking part in live sessions, Q&As, discussion zones, challenges, and so much more! Join in the fun — we provide live captioning in English, too!

By the way, in case you find yourself thinking twice about joining in a Smashing workshops because you’re worried that your boss may need just a little bit of persuasion, then we’ve got your back with a neat lil’ template: Convince Your Boss. Good luck!

Bi-Weekly Podcast: Full Of Inspiration And Insights

Every second Tuesday, Drew McLellan talks to design and development experts about their work on the web. You can subscribe via your favorite app to get new episodes as soon as they’re ready.

Pssst. By the way, is there a topic that you’d love to hear and learn more about? Or perhaps you or someone you know would like to talk about a web- and design-related topic that is dear to your hearts? We’d love to hear from you! Feel free to reach out to us on Twitter and we’ll do our best to get back to you as soon as possible.

1. What Is Art Direction? 2. What’s So Great About Freelancing?
3. What Are Design Tokens? 4. What Are Inclusive Components?
5. What Are Variable Fonts? 6. What Are Micro-Frontends?
7. What Is A Government Design System? 8. What’s New In Microsoft Edge?
9. How Can I Work With UI Frameworks? 10. What Is Ethical Design?
11. What Is Sourcebit? 12. What Is Conversion Optimization?
13. What Is Online Privacy? 14. How Can I Run Online Workshops?
15. How Can I Build An App In 10 Days? 16. How Can I Optimize My Home Workspace?
17. What’s New In Drupal 9? 18. How Can I Learn React?
19. What Is CUBE CSS? 20. What Is Gatsby?
21. Are Modern Best Practices Bad For The Web? 22. What Is Serverless?
Catching up with what’s new in the web industry doesn’t mean you have to be tied up to a chair and desk! Do as Topple the Cat does it: grab your headphones and stretch those legs! You can subscribe and tune in anytime with any of your favorite apps.

Shining The Spotlight On Accessibility And Prototyping

Mark your calendars! We’ll have the great pleasure to welcome Chen Hui Jing and Adekunle Oduye to our Smashing TV virtual stage. If you’d like to attend, you’ll need to install the Zoom client for Meetings, which is available for all the main OSs. (It may take a little time to download and install, so please grab it ahead of time if you can.)

  • “Accessibility With(out) Priorities” on September 1 (14:00 London time)
    Hui Jing will touch upon the reasons why this is the case, and discuss strategies to convince clients and bosses to still ‘invest’ in accessibility.
  • “The Good, The Bad And Ugly Of Prototyping” on October 1 (19:00 London time)
    Adekunle will share techniques on how prototype efficiently and effectively, how to create a framework for prototyping that fits into your organization, and how to utilize a prototype for production.
Smashing TV is a series of webinars and live streams packed with practical tips for designers and developers. Follow @SmashingMembers on Twitter for schedules, transcripts and fancy cats.

We aim to publish a new article every single day that is dedicated to various hot topics in the web industry. You can always subscribe to our RSS feed to be among the first ones to read new content published in the magazine.

Here are some articles that our readers enjoyed most and have recommended further in the past month:

Smashing Newsletter: Weekly Best Picks And News

The Smashing NewsletterWe’ve got news! We’ll be sending out a weekly edition of the Smashing Newsletter, but aiming for shorter and topic-specific issues. These may be dedicated to accessibility, or CSS, or UX — you’ll just have to wait and see! We want to bring you useful content, and to share all the cool things that we see folks doing across communities within the web industry. No third-party mailings or hidden advertising, and your support really helps us pay the bills. ❤️

Interested in sponsoring? Feel free to check out our partnership options and get in touch with the team anytime — they’ll be sure to get back to you as soon as they can.

The State Of Things In 2020

With so much happening on the web every day, it’s difficult to keep track, but it’s even more difficult to pause for a moment, and a take a detailed look at where we actually are at the moment. Luckily, there are plenty of surveys and reports gathering some specific developments in a single place. State of CSS and State of JS highlight common trends in CSS and JavaScript. There are also studies on Design Systems in 2019, Front-End Tooling and Open Source Security.

The State Of Things In 2020

It’s good to know where you stand not only in terms of skills, but also in terms of salaries: that’s where Levels.FYI Salaries helps, as well as UX Designer Salaries and Design Census 2019. Plus, make sure to review State of Remote Work 2020, highlighting trends of how to make remote work more efficient. Word of caution: some of them might be biased due to the demographics that they are targeting, so please take the insights with a grain of doubt.

Diving Into HTML And CSS Vocabs

If you often find yourself looking up the correct word to use for that one particular thing in your CSS and HTML code, we’re sure you’ll bookmark the following resources right away. Thanks to Ville V. Vanninen, you can now learn the difference between doctypes, attribute names, tags, media features — all in an interactive way.

CSS And HTML Vocabulary

You’ll find a nice interactive list of CSS terms as well as another useful one dedicated to HTML vocabulary where you can click on any of the terms shown on the right side to highlight the relevant parts in the code sample presented on the page. The lists are also available in different languages.

Practical Tips For Rebranding A Product

Do we rebrand? And when is the right time to do so? A lot of product people are asking themselves these questions as their product becomes more mature. The team at Overflow was in the same situation a while ago.

Evolving the Overflow Brand

To reflect the evolution of their product from an easy-to-use, practical flow diagramming tool into a tool that is used for design communication and presentation workflows, they decided that it was time for a rebranding. In the article “Evolving the Overflow Brand”, they share their approach and what they learned along the way. Interesting ideas and takeaways that you can incorporate into your own redesign process. One that particularly helps make the challenge more approachable: Think of your product as a human being and imagine what they are like and how they feel to visualize your brand’s new identity.

Disabled Buttons And How To Do Better

“Disabled buttons suck.” It’s a strong statement that Hampus Sethfors makes against this widespread UI pattern. As Hampus argues, disabled buttons usually harm the user experience, causing irritation and confusion when nothing happens when a button that carries an action word like “Send” is clicked. But they do not only prevent people from completing tasks with as little effort as possible, disabled buttons also create barriers for people with disabilities — due to issues with low contrast and assistive technologies not being able to navigate to disabled buttons. Now, how can we do better?

Disabled buttons suck

Hampus suggests to keep buttons enabled by default and show an error message when a user clicks it. If you want to indicate that a button is disabled, you could use CSS to make it look a bit grayed out (considering contrast, of course) but keep it enabled and put focus on a meaningful error message. A small detail that makes a difference.

The “Back” Button UX

We often spend quite a bit of time to get a feature just right, or enhance the design with bold interactive features. We measure the impact of our decisions in A/B tests, study conversion and click-through-rates, analyze traffic and search for common funnel issues. But the data conveys just a part of the story. More often than not, customers have very different issues, often unrelated with our features or design.

The quality of an experience shows in situations when something goes unexpectedly. What happens when the customer accidentally reloads the page in the middle of a checkout, e.g. when scrolling up and down on a mobile phone? Does the payment form get cleared out as a user notices a name’s typo on a review page? What happens when a customer hits the “Back” button in a multi-step-process within our single-page-application?

Design Patterns That Violate “Back” Button Expectations

In fact, the unexpected “Back” button behavior often has severe usability issues, and some of them are highlighted in Baymard Institute’s article Design Patterns That Violate “Back” Button Expectations. It’s worth testing the “Back” button for overlays, lightboxes, anchor links and content jumps, infinite scroll and “load more” behavior, filtering and sorting, accordions, checkout and inline editing.

We can use the HTML5 History API, or specifically history.pushState() to invoke a URL change without a page reload. The article goes into detail highlighting common issues and solutions to get things just right. Worth reading and bookmarking, and coming back to every now and again.

Modern CSS Solutions For Old Problems

When it comes to layout and styling, some problems keep appearing in every other project — styling checkboxes and radio buttons, fluid type scale, custom list styles or accessible dropdown navigation.

Screenshot from the Modern CSS series by Stephanie Eckles

In her series, Modern CSS, Stephanie Eckles dives into modern CSS solutions for old CSS problems, taking a closer look into each of them, and exploring the most reliable techniques to make things work well in modern browsers. Stephanie also provides demos and ready-to-be-used code snippets. A fantastic series worth checking out and subscribing to!

Fun With Forms

Web forms are literally everywhere — from subscription forms to filters and dashboards, yet they aren’t easy to get right. How do we deal with inline validation? Where and how do we display error messages? How do we design and build autocomplete controls? No wonder that there is no shortage in resources on form design — and there are a few new ones that appeared recently.

Graphic of a checkbox box

Geri Reid has collected Form Design Guidelines, with best practices, research insights, resources and examples. In Fun With Forms, Michael Scharnagl collect a few obscure facts and fun things to do with forms. Adam Silver has been writing quite a bit about web form best practices in his blog — and release a web forms design system, too. Finally, Heydon Pickering still has some inclusive components patterns for forms in his blog. All wonderful resources to keep track of when designing or building forms — to ensure we don’t make costly mistakes down the line.

A CSS-Only, Animated, Wrapping Underline

Underlines are hard, especially if you want to do something that goes beyond the good ol’ text-decoration: underline. Inspired by a hover effect he saw in the link underline on Cassie Evans’ blog, Nicky Meulemann decided to create something similar: a colored underline with a hover effect where the line retreats and is replaced by a differently colored line.

A CSS-only, animated, wrapping underline

The twist: The lines should not touch during the animation and, most importantly, links that wrap onto new lines should have the underline beneath all lines. If you want to follow along step by step how it’s done, be sure to check out Nicky’s tutorial.

A Guide To Setting Up A Development Workflow On Mac

Setting up a development environment on a new computer can be confusing, not only if you’re new to programming. Together with contributors from the web community, Sourabh Bajaj published a comprehensive guide that helps you get the job done with ease.

macOS Setup Guide

The guide is a reference for everyone who wants to set up an environment or install new languages or libraries on a Mac. From Homebrew to Node, Python, C++, Ruby, and a lot more, it takes you step by step through everything you need to know to get things up and running. Contributions to the guide are welcome.

Smashing Editorial (cm, vf, ra)
Posted on

Designing Complex Responsive Tables In WordPress

Designing Complex Responsive Tables In WordPress

Designing Complex Responsive Tables In WordPress

Suzanne Scacca

(This is a sponsored article.) Mobile devices can be problematic for displaying complex tables and charts that would otherwise stretch the entire width of a laptop or desktop screen. This may leave some of you wondering whether it’s even worth showing tables to mobile and tablet visitors of your website.

But that doesn’t make sense. In many cases, a table isn’t some stylistic choice for displaying content on a website. Tables are critical elements for gathering, organizing and sharing large quantities of complex and valuable data. Without them, your mobile visitors’ experience will be compromised.

You can’t afford to leave out the data. So, what do you do about it?

This requires a more strategic solution. This means understanding what purpose the data serves and then designing the complex web table in a way that makes sense for mobile consumption.

A WordPress table plugin called wpDataTables has made light work of designing both desktop and mobile compatible tables, so I’ve included examples of these complex tables throughout this post. Keep reading to explore the possibilities.

The Most Common Use Cases For Tables On The Web

There’s a lot of value in presenting data in a table format on a website.

Your writers could probably find a way to tackle each data point one-by-one or to provide a high-level summary of the data as a whole. However, when data is handled this way, your visitors are left with too much work to do, which will only hinder the decision-making process.

On the other hand, tables are great for organizing large quantities of data while also giving visitors an easier way to sift through the data on their own.

As such, your visitors would greatly benefit from having complex data sets presented as tables — across a wide variety of use cases, too.

Feature Lists

There are a couple of ways to use tables to show off product features.

For e-commerce sites, the product inventory is broken up by its most pertinent features, allowing visitors to filter their results based on what’s most important to them:

e-commerce product tables
e-Commerce sites can use product tables to quickly list out all products and their key features. (Image source: wpDataTables) (Large preview)

This would be great for any large vendor that has dozens or hundreds of similar-looking products they want customers to be able to filter and sort through.

You could also use a table to compare your product’s features directly against the competition’s. This would be better for a third-party marketplace where vendors sell their goods.

Amazon includes these kinds of tables:

Side-by-side competitor tables
Marketplace sites use side-by-side competitor tables to simplify decision-making. (Image source: Amazon) (Large preview)

By displaying the data in this format, customers can quickly do a side-by-side comparison of similar products to find the one that checks off all their requirements.

Pricing Tables

If you’re designing a website where services or memberships are sold instead of products, you can still use tables to display the information.

You’ll find a good example of this on the BuzzSumo website:

Service-based companies list prices in tables
Companies that sell services, like BuzzSumo, use tables to display pricing and features. (Image source: BuzzSumo) (Large preview)

Even though there’s less data to compile, you can see how the structure of the table and the stacking of the services side-by-side really help visitors make a more well-informed and easier buying decision.

Catalogs

A catalog is useful for providing visitors with an alphabetized or numerically ordered list. You might use one to organize a physical or digital inventory as this example demonstrates:

Catalog tables
Catalog tables make it easier for users to find what they’re looking for. (Image source: wpDataTables) (Large preview)

This would be good for bookstores, libraries and websites that have their own repository of reference material or content.

You might also use a catalog to help customers improve the accuracy of their orders:

Catalogs for order accuracy
Catalog tables can be used to aid shoppers with order accuracy. (Image source: wpDataTables) (Large preview)

This type of table provides customers with key specifications of available products to ensure they’re ordering the right kinds of parts or equipment.

Best Of Lists

There are tons of resources online that provide rundowns of the “Top” winners or “Best Of” lists. Tables are a useful way to summarize the findings of the article or report before readers scroll down to learn more.

This is something that websites like PC Mag (and, really, any tech or product review site) do really well:

Best-of reviews table
PC Mag organizes a summary of best-of reviews in a table format. (Image source: PC Mag) (Large preview)

This helps readers get a sense for what’s to come. It also allows those who are short on time to make a faster decision.

Directory Tables

Directory websites have ever-growing and regularly updated lists of data. These are your real estate listing sites, travel sites, professional directories and other sites containing high volumes of complex data that really shouldn’t be consumed without a filterable table.

Case in point: this list of available apartments:

Directory website table
Directory websites that change often need tables to keep listings organized. (Image source: wpDataTables) (Large preview)

This makes it much easier for visitors to see all options in a single glance, rather than have to go one-by-one through individual entries that matched a search query.

General Data

There are other data lists that are just too complex to handle as loose text. Sports data, for instance, should always be presented in this format:

Sports statistics table
Basic statistics, like for sports teams, should never be presented as loose data. (Image source: wpDataTables) (Large preview)

You can see how this keeps all data in one place and in a searchable list. Whether visitors are looking for their home team’s stats, or want to compare the performance of different teams from their fantasy sports league, it’s all right there.

How To Design Complex Responsive Tables

Regardless of what type of data you’re tasked with presenting on a website, the goal is to do so in a clear fashion so visitors can take quicker action.

Now, it’s time to figure out how to best format this data for mobile visitors.

Delete, Delete, Delete

If your client has pulled their data from an automated report, they may not have taken time to clean up the results. So, before you start any design work on the table, I would suggest reviewing the data they’ve given you.

First, ask yourself: Is there enough data that it warrants a table?

If it’s a simple and small enough list, it might make more sense to ditch the table.

Then, go over each column: Is each of these useful?

You may find that some of the columns included aren’t necessary and can be stripped out altogether.

You may also find that some columns, while an essential part of each item’s individual specifications list, won’t help visitors make a decision within the table. This would be the case if the column contains an identical data point for every item.

Finally, talk to your writer or data manager: Is there any way to shorten the columns?

The table’s labels and data may have been written in full, but your writer may have a way to simplify the responses without compromising on comprehension.

When possible, have them work their magic to shrink up the text so that columns don’t take up as much space and more can be revealed on mobile. Don’t just do this for mobile users either. Even on desktop and tablet screens where more screen real estate is available, the shortening of labels can help conserve space.

It may be as simple as changing the word “Rank” to the number symbol (#) and abbreviating “Points” as “Pts”.

Make data smaller
Designers and writers need to work together to create smaller tables. (Image source: wpDataTables) (Large preview)

While it might not seem like one word will make much of a difference, it adds up the more complex and lengthier your tables are.

Start With Two Columns

By default, mobile tables should always start with two columns. It’s about all the screen’s width will allow for without compromising the readability of the data within, so it’s best to start with the basics.

When you contrast a full-screen table on desktop against its counterpart on mobile, you can see how easy it is to identify the two columns to include. For example, a mobile statistics table includes a column for item type and one for the profits earned from each:

Mobile table with two columns
It’s a good idea to design responsive tables with two columns to start. (Image source: wpDataTables) (Large preview)

This doesn’t mean that all other data is lost on mobile. You just need to let visitors know how they can expand the table’s view.

In this example, when visitors select the eyeball icon above the table, they have the option to add more columns to the table:

Column view options
If visitors want to scroll right, give them column view options. (Image source: wpDataTables) (Large preview)

In allowing for this option on mobile, your visitors can control how they consume data while also selecting only the data points that are most important to them.

The result will then look like this:

Mobile table with more than two columns
An example of a mobile table with additional columns. (Image source: wpDataTables) (Large preview)

While users will have to scroll right to see the rest of the table, the control they wield over column views helps keep this a reasonable task. With just one scroll right, they’ll see the rest of the table:

Horizontal scrolling on mobile
Even with more columns on mobile, horizontal scrolling is kept to a minimum. (Image source: wpDataTables) (Large preview)

This is a good option to have for lists of products where the side-by-side comparison is useful in expediting the decision-making process.

Use An Accordion For Standalone Entries

There’s another option you can include which will give visitors more control over how they view table content.

For this example, we’ll look at a list of available cryptocurrencies:

Expandable accordions for mobile tables
Data lists (as opposed to product comparison) lists can use expandable accordions. (Image source: wpDataTables) (Large preview)

As you can see, the default here is still to only show two columns. In this case, though, a click of the plus-sign (+) will reveal a new way to view the table:

Expanded row on mobile
An example of what an expanded row looks like on mobile tables. (Image source: wpDataTables) (Large preview)

When open, all of the data that would otherwise force visitors to scroll right is now visible within a single screenful.

While you can certainly include an expandable accordion in any responsive table you create, it would be best suited to ones where a direct side-by-side comparison between products or services isn’t necessary.

Keep Vertical Scrolling To A Minimum

Just as you want to prevent your visitors from having to scroll past the horizontal boundaries of the mobile website’s pages, you should limit how much vertical scrolling they have to do as well.

Data consumption, in general, isn’t always an easy task, so the more you can minimize the work they have to do to get to it, the better.

One way to limit how much vertical scrolling your visitors do is by breaking a table with dozens or hundreds of rows into pages.

A table of annual temperatures on desktop and mobile
An example of how to shrink an extra-large table down to a couple columns and multiple pages. (Image source: wpDataTables) (Large preview)

Just remember to make it easy for visitors to scroll through the pages. A well-designed set of pagination controls either at the top or bottom of the table would be useful:

Responsive table pagination
Use pagination at the bottom of tables to decrease vertical scrolling. (Image source: wpDataTables) (Large preview)

This would be especially useful for a handful of pages. Anything more than that and the pagination process may become tedious.

You can also include a table search function directly above it:

Mobile table search function
Above-the-table search helps reduce the work of scrolling on mobile. (Image source: wpDataTables) (Large preview)

This allows for a quick shortcut when your users have a good idea of what they’re looking for and want to jump straight to it.

Include Both Filtering And Sorting For Larger Data Sets

So, let’s say that you have a very extensive list of data. You don’t want to force users to scroll through dozens of table pages, but you also can’t afford to remove any of the data sets. It’s all pertinent.

In that case, you’re going to hand some of the control back to your visitors. This way, their choices will determine how much of the table they end up seeing.

Let’s use this list of mutual funds as an example:

Complex table example
An example of a complex table on mobile. (Image source: wpDataTables) (Large preview)

The image above is the default view visitors would see if they scrolled immediately to the table. However, they might find it to be intimidating and decide that filtering out bad results will improve the view:

Table filters
Filtering allows users to greatly narrow down how many rows are displayed on mobile. (Image source: wpDataTables) (Large preview)

What’s nice about including filters on mobile tables is that they function the same way your mobile contact forms do. So, visitors should have an easy time filling in and moving between fields, which will get them quicker to the results they want to see.

Another way to improve how their results are displayed is by using the sorting feature. When they click on the top label of any column, it will automatically sort the column in descending order. Another click will reverse it.

Table sorting
Sorting allows users to see results in descending/ascending order. (Image source: wpDataTables) (Large preview)

These two features are a must-have for any table you build, though they’re especially important for mobile visitors that don’t have as much time or attention to give to your tables.

Wrapping Up

You’re here because you want a better way to present complex tables to your mobile visitors.

The key to doing this right is by first familiarizing yourself with the kinds of tables you can create. Even if mobile devices limit how much can be seen at first glance, that doesn’t make it impossible to share that kind of data with them.

Next, you need to build user control into your tables, so that visitors can decide what they see and how they see it.

And, finally, you’d do well to find a tool built specifically for this complex task. For those of you building websites with WordPress, wpDataTables is a WordPress table plugin that’s able to create responsive tables and charts. It doesn’t matter how large your data set, or what use case it’s for, it will enable you to quickly and effectively organize and display responsive tables on your WordPress website.

Smashing Editorial (ms, yk, il)