Library Podcasts

Ep. #3, Designing For The Modern Web

Guests: Rafael Conde

Join Brian and Rafael Conde in episode 3 of JAMstack Radio as they share their stories of designing and coding for the modern web. The two discuss how both web design and code are evolving at an increasing rate, the proliferation of fantastic build tools, frameworks, and languages, and finally how what was once old is new again.


About the Guests

Rafael Conde is the Design Lead at Heavybit Member company Netlify. His passion is design, and he codes for fun. You can check out some of his side projects like Break This Safe and Frames on his website.

Show Notes

Transcript

00:00:00
00:00:00

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line, we've got Rafa.

Rafael Conde: Hey man, how's it going?

Brian: I didn't say your last name because I've actually never said your last name out loud. Can you tell me how to say your last name?

Rafael: My last name, in Portuguese, is pronounced "Cond." I guess you would read it as "Cond-e," so when I tell people it's like "Bond," but with a C... James Bond, but with a C. You know, because that makes me look cool.

Brian: You probably should start with that then. I had you on because you're actually my designer here at Netlify. Not only do you design, but you also do a bit of code. Do you just want to catch the listeners up with your background and what you do and what you've done up until now?

Rafael: I started studying in college. I studied computer science, actually, so that's where I started in this technology industry, I guess. I started as a coder, but I was a pretty mediocre student. I was not really into it, and then I got really into design.

I was a self-taught designer, and while still studying, I started learning design and then got a job as a designer and front-end developer. Because of my background, I was never able to decouple those two functions, mostly. So usually, all kind of work that I did was with design and some development coupled.

Before joining Netlify, I was working as an independent developer. I built my own games and apps, just out of necessity, I guess. Necessity and interest, in a way. I didn't want to call anyone, ask anyone to join me.

I was on my own and I wanted to do everything on my own. I still don't call myself a developer. I say I'm a designer who knows how to code, because that seems like it would be unfair to actual, real developers.

Brian: The design details guys, they always joke about, "Should designers know how to code?" Would you consider yourself a unicorn, then, since you can code as well as design?

Rafael: No, not really. Because

unicorns are horses with a horn. So I don't see myself as a horse. I'm more of a human.

So, no. Would we call a designer who knows how to code a unicorn? Sure.

Brian: I'm going to have Eli change your business cards to unicorn. We'll go from there.

The podcast itself, JAMstack Radio, is all about JavaScript APIs and markup, and the focus is on the way to develop on the new web. I know you have some experience with JAMstack. What's your ideal workflow of how to get a prototype, a website, whatever you're trying to get, what would you use to get that up and running?

Rafael: My ideal workflow would look like: let me create an HTML file, a CSS file, and put it somewhere magic, and it just works, right? Let me work with my text editor. Let me create my files. Let me create anything I need to, and if I want to put in Mousetrap or just some other tools, I can.

But basically, my ideal workflow would be something that I wouldn't have to deal with. Because I'm not a real web developer. I just want something as easy as possible just for me to write the code and write what I know how to write, basically.

Brian: Before we actually hit record, you were talking about a little bit about Heroku and the trouble with that. What's your aversion to actually hosting your own server and stuff like that?

Rafael: It's just because it's so much. I guess the jump that we have to do from knowing nothing about web and being able to write your own simple HTML, CSS, JavaScript pages. Then to jump to actually know about hosting, know about servers, know about all of that.

The jump is way bigger than simply learning how to write some front-end, simple web development. Because my heart wasn't into that. I was never interested in doing it. I would do it if I had to, right? So, Heroku is still way too complicated for me, for my experience and knowledge on this.

Usually I have to have some actual web developers, back-end developers, to kind of set that all up for me. And again every job or every work that I do, I need, "Whoever is in charge of that, just give me the HTML, the React app." Let me just write what I know what to write. That's basically why I never really got into it.

Brian: Which is interesting too because, I wouldn't say you're an expert in React, but you're doing some coding sessions with another one of our front-end developers. You're learning React. You're actually implementing some components in React now.

Do you find that beneficial, that you don't actually know what's actually happening? How the app's actually getting on the internet, and what is actually compiling the site and stuff like that. What's your opinion of that whole setup that we have going, currently?

Rafael: I need to trust it, right? And even though I don't know all of the things happening in the background, what actually is working, I know enough to be able to say, "All right, this seems cool. This seems great." People that are knowledgeable in the field, they seem to like it, and I'm going to trust it.

So far as to writing React, which basically is JavaScript as everyone knows, coming from writing simple HTML and some CSS and some simple JavaScript, I feel like if you're trying to replicate exactly what you are doing with just HTML, CSS, and trying to do it in React, there are no benefits, really, if you're just trying to do exactly what you were doing before.

And, because it's just an overlay of complexity, so huge on top of it that you feel like this is not worth it. It's only when you learn more about it, learn more about React, that you can see all of the benefits it actually brings when you take advantage of those benefits. That's when it makes it all worth it. But before you hit that ceiling, before you hit that turning point, it just seems daunting, right?

Brian: I don't want to speak for you, but when I approach a project, I made that little Pokemon Server Go app in maybe an hour or so. After lunch I was able to put that together and I was able to prototype it. And I have to think about, "Ooh, am I going to be using Webpack or Grunt or Gulp? Am I going to put this on Heroku or S3?"

I was able to get a site up and running and host it very quickly without much thought put into it at all, even design thought as well.

I think there's a lot of value to be able to get prototype an actual site and bootstrap something together really quickly and being able to see it live on the internet with a URL, rather quickly.

What are your thoughts?

Rafael: I agree with you. It's one of those things that, like coding in general, especially in education when you're trying to teach someone how to code, I think the visual, instant feedback, that's like gold.

That's crucial for you, to engage students, engage someone. And that's something that we still don't see that often. It's still very obscure and you still don't know exactly what's going on, especially when you're learning.

It's interesting to see Apple with a new Swift Playgrounds on the iPad. I don't know if you've had a chance to look at it.

Brian: I haven't. It's in my long list of things to get to.

Rafael: Basically it's teaching code in a very visual way. You have instant feedback, and it's more like a game, really. And that's not aimed for college students. It's aimed at children and young kinds who had zero contact with code before, and that's the way they know how things work, in a very abstract way, still.

That's still true to me after many years of experience. If I can't have some feedback, it doesn't need to be instant, but some quick feedback on what I'm writing, because code looks like nothing, right?

Code isn't anything until you see it, until it compiles into an actual product that it can use. The quickest way for you to get that feedback, I think, is crucial. So it's always like something that we should strive for.

Brian: I think the whole separation of concerns between front end, back end, design, UI, I think is actually also important to completely just focus on the design. That way, you can actually focus and get something out and prototyped and not have to worry about, "Is this going to work?"

That should be in my job as a developer, to actually connect the back end to the front end for you.

You design the mock up, design what it actually is going to look like, even perfect it. Then that way, I can perfect the actual back end of the code.

I'm actually doing a talk coming up in October about making designers happy in React. I think I've showed you the whole abstract and the rundown of it. But for the listeners sake, our workflow between you and me, developing features, I've definitely never had the actual workflow that works as good as this.

You're able to mock up, in CSS and HTML, what you think it would look like. I'm able to go and connect it, and you don't have to worry about, "Is this going to run on the server? Is this too big of an image?"

All that stuff that you don't need to really worry about to make design work really well. I can handle imperfection, and I can get that hosted pretty easily using the whole JAMstack philosophy by connecting the API and the mark-up together, which I love.

Out of all the jobs I've had doing code, this is definitely the best workflow I have had so far.

Rafael: It's been working great for us. What's it called? Storybook? The library of UI components, that's great. For me as a designer and a front-end developer, I can be pretty confident mocking up by coding this small component, these small UI elements, and not be worried that I'm going to mess with the whole app or I'm going to destroy anything. It's completely fine, and it's a good way to just focus on the small element that you are focused on.

It's funny that you mentioned that talk. I'm also working on this talk which basically is on how being a developer makes me a better designer.

Because we're now doing our whole app using React, and the whole notion of components, it changed the way I design. It's something that we still, as designers, are long overdue.

Because if we're doing like a mock-up, if we're using Sketch or Photoshop or whatever you use, for a designer a mock-up of a web page, we do this 1440 x 1280 or something. This static mock-up that doesn't change and that's not true, that's not how the web works.

Not just because of responsive design and all, but the fact that right now I'm focusing on very small components: I designed a side bar, I designed the nav bar on top, I designed the cards. And all of them had the appropriate margins and all, and then when I actually have to just put a page together, I just pick all of those components. It's kind of like Lego, like Tetris. Just putting it all in the right place. It's also very true to, to the medium, to how it's going to be, the final product.

Brian: I love this workflow. I'm really excited about it. It's funny, because I just talked to one of our support engineers about a ticket that came through with Netlify. They had mentioned that, in PHP, because these people actually come from a WordPress background and now are switching to the JAMstack philosophy, they're like, "Oh, in PHP I could just do server-side includes. I could like take a cookie from JavaScript on the front end, send it to my server, look at it on my server."

Then, if it's yes or no, let's say it was for a repeat viewing, if someone's been to the site already, they would see a different site or different elements. If they'd been there again on the server, it actually said, "Yes, this cookie has been here," then they go ahead and send that back to the front end and then do something in CSS and HTML.

I don't come from that realm, so this seems insane that someone would actually send the cookies that are built on the front end to an Apache server, to be able to tell CSS on the front end what needs to be done.

It's just mind-boggling that that's the way the web worked.

I understand like the process. You want to make sure that things are fast. Having servers loaded in PHP is fast because it's all server-side rendering. But I think we've come along so far, as far as JAMstack, and build tools and stuff like that in JavaScript.

Rafael: It's like building an app in C. It's going to be fast, sure, but do you want to deal with all the hassle?

Brian: To your point, to C as well, there are trade-offs you can make. You can make that whole question, "Should I write this entire web app in C, or should I write it in JavaScript and like be done with it in half a day?" I think the trade-offs are there, too.

Sometimes we like to architect and make sure things are as fast as possible, which is great, but I think, nowadays with JavaScript, things are already fast. We're already there. We've got LTE speeds and stuff like that for internet. I know not every country and not every mobile device is going to have that same sort of experience, but we can aim to provide that experience and have fallbacks if that's not there as well.

Rafael: I think it all comes down to how much you care and how much time and willingness you have. If you want a cup of coffee, you can get your beans and grind them and boil the water to the right temperature and spend like 15 minutes brewing you cup of coffee. Or you can just use drip coffee. Both of them are valid options. It's just how much you care about certain things, right?

Actually, coffee I really do care about and I really do grind my own beans and all. But orange juice, I like orange juice, but I don't care enough to buy my orange and then squeeze the juice myself. I'll just buy some from the supermarket and just drink that. So it's not a good or bad option. It's just like how much willingness and how much you care about it.

So, if you're building an app, if you really do care, your top priority is speed and probably security. Maybe you should write the whole thing in C or whatever. But I would say in this day and age, for the good or the bad, those usually are not the right priority.

It's a very fast-paced world and you do have to ship stuff, and maybe the priorities change.

Brian: I think that's actually a really good analogy, with the coffee and orange juice as well. Some people just don't care about certain things, which is fine. We've got instant coffee in our office, so some people enjoy that.

But then we've got also Sightglass beans that are shipped over from the East Bay. If you care about your coffee, you'll get the Sightglass coffee. If you don't, you'll just use the instant coffee. No shade to our CEO who likes the instant coffee. Sorry, Matt.

I just have a final question. Since your background's in computer science, you've been coding for a bit. What's your state of keeping up to date with things that are JavaScript and React and frameworks and Webpack and Grunt? Do you keep up, or are you just kind of this "wait and see what the flow is for other people"?

Rafael: It's kind of both, which doesn't make any sense. I'm always on top of what's new, and on top of new technologies and what the cool kids are using, but when I do need to start a new project or do something new, I just don't fall back to what I know.

When I start a new project, I like to look around. I like to ask people that I trust and I respect, "What's good? What should I use? What should I learn?" I would say most of these new technologies, I'm not really sure what they're all about. Even React. React's something that was on my radar. I heard a lot about it, but I was not, at the time, actively working as a web developer. Some of that stuff passed me on the side.

But when it was time to do a redesign or rebuild or rewrite our own app, when we sat together and said, "What should we use? What's the best option for us? What's new? Let's look at all the options." We're not afraid of trying new stuff. I'm not going to try something new just for the sake of being new. Because, again, the coffee and orange juice: I don't care enough.

Brian: I also avoided, even as a developer, React for a while just because I didn't have the time to really focus on learning this. Surprise, React didn't actually take that much time to learn. It's a built in way that you can actually, just by using it, you start learning it because all the abstractions aren't really hidden from you like in other frameworks. But I think that's a good approach. If it's useful at that time, it might be a good time to learn it, especially if time is an issue.

So the final part of this podcast, and I have the rundown, we have this thing called JAMpicks. It's basically whatever you're jamming on. It's like, food, entertainment. It's anything, could be a code thing, design thing. I'm going to ask you the question, Rafa: what are you jamming on currently?

Rafael: It can be like food, entertainment and stuff?

Brian: Anything that you're excited about.

Rafael: Let's see. Stranger Things is a great show on Netflix, but I'm not going to pick that because everyone has watched it already. Lately, I've been really into vlogging in video, as a medium.

It's nothing new. Vlogging has been around since forever, since YouTube has been a thing. But lately I was surprised by the quality of the average YouTube videos out there from people just vlogging and filming themselves. The production quality was so good, I got really into it. I've been messing with it lately. I've been recording, not daily, but almost a vlog, I guess.

Brian: I am actually jamming on a new cold-brew kit. It's not even a kit. It's actually a pitcher. I got it actually from Japan, which is weird because I didn't know that was the case. I got it on Amazon Prime, and it's a pitcher where you grind the beans and you have a filter that sits inside the pitcher. It's called Hario.

You grind the beans, set them on the counter for about half a day, 20 hours, whatever you feel like is a good, optimal peak time for your cold brew to be brewed. It's the best cold brew I have ever had.

I've been making cold brew for a couple years now, and I used to use mason jars and cheese cloth and it was really messy and not as ideal. This is like the cleanest way of making cold brew.

It's also the best cold brew I've had so far.

It's amazing and I try to put a little bit of vanilla syrup in there, and then that's all I use. Vanilla syrup and ice.

Rafael: That's cool. You have to send me a link. I mean, I know the brand. I know Hario. My kettle is Hario and scale and V60, they're from Hario. But I haven't seen that, so send me a link. I want to check that out.

M- I happened to go to a friend's house who had cold brew already made in this pitcher, and I was like, "What is this? I need to know." I got home that night and ordered it on Amazon Prime, and it's great. It's just weird that all the instruction came in Japanese.

Rafael: Yeah, I know.

Brian: I couldn't like read the instructions and know their measurements. I had to Google it. So I found the American instructions. It's 1,000 milliliters, which I think you should be familiar with the metric system, and about 80 grams of beans, ground beans. And that's all I need.

Rafael: All right. Cool, cool.

Brian: Awesome. Rafa, thanks again for coming on. I really appreciate the chat.

Rafael: Thanks for having me, Brian.

Brian: Keep spreading the JAM.

Want developer focused content in your inbox?

Join our mailing list to receive the latest Library updates. After subscribing, tell us your preferences to receive only the email you want.

Thanks for subscribing, check your inbox to confirm and choose preferences!

You've been here a while...

Are you learning something? Share it with your friends!