Tag: Episode


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
marcy-sutton-200x200-1
14 Jul

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

by TBSCategories: News

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby?

Drew McLellan

Photo of Marcy SuttonToday, we’re talking about Gatsby. What is it and how does it fit into your web development stack? Drew McLellan talks to expert Marcy Sutton to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is the lead engineer on the Developer Relations team at Gatsby. Previously, she worked on the open source axe-core accessibility testing library, and has also worked as an accessibility engineer at Adobe. She’s passionate about improving the web for people with disabilities and often speaks about it at conferences. In 2016, O’Reilly gave her web platform award for a work in accessibility.

Drew: She also co-leads the accessibility Seattle and NW Tech Women Meetups in a local region. So, we know she’s a skilled engineer and an accessibility expert. But did you know she wants to send it Angel Falls in a barrel? My smashing friends please welcome Marcy Sutton.

Marcy Sutton: Hello.

Drew: Hello. Marcy. How are you?

Marcy: I’m smashing. How are you?

Drew: I’m very good. Thank you. I wanted to talk to you today about Gatsby. Because it came up in a conversation I was having on a previous episode about learning React with Mina Markham. I realized I was in danger of doing the typical man on the internet thing of giving an opinion on something that I had no direct experience of. So that’s not how we do things at Smashing.

Drew: And I want to make sure that we properly cover Gatsby. And what better way to do it than to talk somebody who knows it inside and out. So, presuming that perhaps I’ve heard the name Gatsby. But I’ve got no idea where it fits into the stack when building website. What exactly is Gatsby.

Marcy: Gatsby is a website generator, it currently uses React. But it will create a static website for you that then will rehydrate into a full React web application. So you really get the best of both worlds with fast builds that you’re compiling HTML files that will load fast for users. And then you get all of this enhancement with JavaScript to make really interactive dynamic web apps.

Marcy: So, it’s really exciting space to be in. And I’ve been working on the learning side with documentation and now on the Devrel team, I’m focused on making it as good as it can be, knowing accessibility challenges with JavaScript and just trying to fix it from the inside out.

Drew: Many of us will be familiar, I guess, with the concept of a static site generator. And Gatsby seems to broadly fit into that role. But to me, it seems like it goes a lot further than the most SSG’s do. And most site generators are front-end code agnostic. It seems that with Gatsby, you end up with Gatsby code running as part of your site. Is that a fair assessment? And if so, what sort of things is Gatsby actually doing in your front-end?

Marcy: Yes, I’d say the biggest piece of that is client side routing. So, Gatsby right now is using reach router under the hood. It does kind of its own implementation. But that is the piece that when you load your static site for the first time, there are HTML files there. So, if the user turns JavaScript off for some reason, your site should still be there, still have content.

Marcy: But if JavaScript is enabled, that’s when this hydration step happens where, when you use links in your Gatsby site, it will go pre-fetch resources from that page, so it will load faster. So, that is all enabled with this JavaScript layer that Gatsby gives you. And so beyond that, it really depends kind of what you’re using in your site will end up in that JavaScript bundle.

Marcy: But for things that use a lot of interactivity, like accessible interfaces, that’s a good place to be. For me, I really enjoy having JavaScript available to me at all times, and having my markup just be in a good spot. I know it’s a matter of preference, whether you want your HTML and your JavaScript and your CSS all kind of neatly coupled and there’s room for variations within building Gatsby

Marcy: You don’t always have to use something like CSS and JS. But it’s really about getting the power of that dynamic JavaScript layer, available to you while you’re writing your website. It’s not like this add on in a separate file.

Drew: When I think of how a static site generator usually works, I’m thinking of content in perhaps Markdown files. And the generator runs across that content and merges it with templates and creates 10s, hundreds, thousands of HTML files, which are the pages of your website. When I think of a React site or app, I’m thinking more about single page experience where the interfaces be created by React on the fly. So, you’re saying Gatsby does both of those? It’s creating all the pages and also enhancing it with JavaScript?

Marcy: It is, yes. Gatsby will use Node.js at build time, it will go over your React components and compile them into HTML files. Which honestly, the first time I looked at Gatsby I wouldn’t turn JavaScript off and was like, “All right, are there other pages here, what is this?” And I was so happy that Gatsby works that way by default. It will create built files from your react components, which is awesome.

Marcy: I have explored more progressive enhancement approaches since it’s in JavaScript. Like what if you want to output something progressively enhanced for users, where if they do have JavaScript turned off, you don’t want all this broken code that assumes JavaScript is there. So there are some quirks with it. But you can work around that kind of thing at least for your core user flows where you want someone to still be able to buy something, you might need to add some support and for those use cases.

Marcy: But I’ve been pleasantly surprised that the way that Gatsby rolls that out by default. And so, it is a choice that they made to build sites that way, and we’re always evaluating it. Is it still the best way? What do we need to do to give our users what they’re asking for? So, we’re doing some explorations internally, ongoing just to make sure Gatsby is doing the best job it can at building a website.

Marcy: So keeping bundle sizes small, and making sure that for making trade offs for what we say is performant code with pre-fetching. Like, do we have the data to back that up? That’s the kind of thing as a developer advocate that I’m super interested in, is making sure that what we’re packaging and bundling on websites is actually needed and will really make the best Gatsby site it can make.

Drew: You mentioned performance there, and there’s a big focus on performance. It certainly seems from the way that Gatsby presents itself. Is that a true feature of Gatsby or is it just the nature of JAMstack websites?

Marcy: I think it can be a nature of JAMstack websites. Ultimately, it’s going to come down to what you’re bundling on your website. So, no matter what framework or tool you’re using, we still have to be thoughtful in what we’re putting in those bundles for end users. But Gatsby really aims to give you good defaults. Not only for performance, but for accessibility as well.

Marcy: But that always takes evaluation, we always have to make sure that if we’ve added something, that it’s still performant. But yeah, getting that initial payload of static files, they load fast. Much faster than classic WordPress site that I used to have. But then enhancing it with JavaScript. There are some trade offs there for sure.

Marcy: But it works really well, lots of people, they really like their Gatsby sites. So, it’s been fun to get to work on it full time, and learn the ins and outs of a JavaScript framework like Gatsby.

Drew: What sort of performance features just Gatsby actually put into place to speed up your sites?

Marcy: Well, with the pre-fetching for links, this client said routing stuff, I’d say that’s probably the biggest one. Making it really easy to generate a progressive web app. So, having some offline capabilities, you can sort of pick and choose what you want in terms of offline and PWA type stuff. But they really make that part of the initial experience, like a lot of the starter example sites that you might start from have examples of using a manifest, and kind of making that modern version of your website.

Marcy: Really, it’s like not shipping code that you don’t need. That’s a big part of it. Caching, that’s really the pre-fetching for links. That’s what I would say is the biggest piece of it.

Drew: So this is where the site is actually anticipating where the user is going to go. Is it as intelligent as that or does it pre-fetch everything on the page or?

Marcy: No, it’s based on user interaction. So, if the user scrolls down the View port, there’s something pre-fetching that happens there. If you hover over links, it will kind of estimate that there’s a pretty good chance that you might go to that page. We’ve been talking internally, well, I guess, open source to about whether that pre-fetching should happen on keyboard focus too, so that intersection of accessibility and performance is very interesting.

Marcy: There’s some trade offs there like should a keyboard user who can’t use the mouse and is tabbing through every link to navigate, should that really be fetching content for every single one of those because a mouse user might be a bit more selective about where they put their mouse cursor. So, those conversations I find extremely fascinating.

Marcy: And trying to think of what data do we need to validate these assumptions too. So yeah, it’s been super interesting to look at those defaults and what improvements can we make and really checking like how much data is that fetching? Is that really a good thing? Just to speed it up a little bit? Or is it fast enough without that? Are there alternative solutions that we could use as part of the fun of working on a framework because being able to evaluate all those trade offs.

Drew: This is pre-fetching something that users just get for free in their site. So do they have to do any work to implement it?

Marcy: You do get it for free using Gatsby link. So it’s a component that comes with Gatsby and when you use that, it outputs anchor tags. So your HTML is real HTML and you’ve leveraged the web platform in that way. But in your React components, you are working directly with the Gatsby link component. And that has all of those mechanisms for… It looks at whatever your future HREF will be, for that link of where you want to go to and it will go and grab resources from that link and preload them.

Marcy: And it’s only internal to your site. So it’s not going off and trying to fetch things on other websites. But it seems to work pretty well. I know some users are actively looking for ways, like you actually have to opt out of some of these things. At least routing, not using the pre-fetching. You just use regular anchor tags. And then you don’t really get that functionality. It’s pretty easy to use something else. But some of the discussions we’re having are around client side routing, and how to make that the best it can be. And so, that’s a really interesting space too.

Drew: How closely do you have to work within the Gatsby ecosystem in terms of if I wanted to have my own link component? Would that be completely fine, I wouldn’t be fighting against Gatsby to do that sort of thing?

Marcy: No, you could slot in whatever components you want, as long as they work with the React runtime. That’s really the beauty of it. Anything you could put in a React app, you could put in a Gatsby app. There’s even a pre-React plugin. So, there are some alternatives to working with Gatsby. But I love how you can pull in whatever, off the shelf components that you want to use or write your own.

Marcy: And I think that flexibility is what people really enjoy. There is the caveat of it uses the React runtime. And so, you have to be okay with using react or using this pre-React plugin. But personally, I really like react and JSX for working with accessibility and templates, especially with React hooks. So, being able to use the hut in my Gatsby site is just so cool. I really like it.

Drew: And how’s the process of building a Gatsby site that’s presumably a node module that you can just install and you would do a build like you would with any other static site generator?

Marcy: Yes. There is a CLI that you install globally. And I guess it’s whether you want to install it globally. That’s what we recommend, because then you can run it from any directory on your computer, but it will pull down whatever you need to build a Gatsby site. And then you can add on, say you wanted to use WordPress as a headless CMS or some other content source.

Marcy: You can install packages, plugins to make that work, and then integrate it with your site. There’s also some starters and themes that you can use to get up and running quicker. I’ve used those if I want to test out something or start a site rapidly for a specific integration like Drupal or prismic or whichever CMS or eCommerce solution or something I want to use.

Marcy: There’s lots of examples. So you’re not always tinkering with trial and error trying to figure it out, but it’s sort of these building blocks that you can piece together and create… It’s what we call the content mesh. And so, you can use these best in breed integrations to create a site instead of, if I had a classic WordPress site, the authoring experience and working with teams is really great.

Marcy: But there were shortcomings in the front end, like how it would work on a mobile device. What else? If I wanted an eCommerce solution? I think there’re some things that are easier to do these days, but being able to pick whichever kind of best solutions you want for authentication, or whatever that modern thing is, you’re like, “I wish I could use that.” With Gatsby, you can pull a lot of these things together and make this content mesh way of building that’s pretty refreshing.

Marcy: Especially when you can still use those integrations like WordPress and still work with teams. So, we’re pretty excited about this new way of working where you can pick all the technologies that you’ve like, or that work for your team.

Drew: One of the big features that Gatsby has tout strongly is this ability to pull in data or content from a variety of different sources. You mentioned things like WordPress and Drupal, and what have you. Traditionally, if I was using something like Jekyll or Eleventy, or something like that, I would need to wire up that myself to interact with API’s, perhaps pull content down and write it into markdown files or JSON files, and then have the generator work with those files.

Drew: So it would be a sort of two step process, could use something like source bit, which we covered on a previous episode that does that sort of thing? Do I understand rightly that Gatsby has just this native ability to consume different sources in a way that other static site generators, just don’t?

Marcy: I think what makes Gatsby really strong in this area is its GraphQL data layer, and the plugin ecosystem. So, chances are someone has already written a plugin for whatever data source you’d be looking to build. And if not, there’s probably something close. But using GraphQL, is kind of the under workings of it. The layer that makes all of these integrations possible is using GraphQL.

Marcy: And so, there’s lots of possibilities for what you could pull in and we try to make it easy to write plugins too. So it’s been really neat learning about how to write a plugin, and the AST or Abstract Syntax Tree that it creates and kind of learning about how all that works has been really cool. But yeah, I’d say, there are a lot of things off the shelf that you could pick up without having to write it all yourself, which is pretty awesome.

Marcy: And it’s nice to have the flexibility to pull in markdown. Say your developers want to write their blog content markdown, but the marketing team is really not happy with that, you could combine content sources, and source them from multiple places. I’ve seen people sourcing things from other GitHub repos, and they use a get plugin to pull in markdown content that way. Lots of flexibility.

Drew: And I guess you’ve got the option then of writing your own plugins to pull from a custom data source. Say you’ve got some legacy system and you want to put a nice, shiny new website on the front of it. You could write a plugin that would get the data out in whatever format that is needed and translate it into something that gets bigger than work with?

Marcy: You could yes. And so, plugins enable that. And then there’s this abstraction on top of that, which we call Gatsby themes. And those are not only user interface code, but they could be GraphQL queries, configurations that set up a plugin, so it’s like a plugin with usage kind of bundled together. And you can distribute those themes on NPM.

Marcy: And then, their version and you can pull them in. And that whole API is really interesting too for teams who say you have multiple repos, and you want to pull data into those, it would be very repetitive to have the same queries in all of these repos in the same code. So, to dry things up a bit and not repeat yourself so much. You can use these abstractions called themes, to sort of distribute around that logic or code that would enable that source plugin. So, there’s these kind of layers of abstractions that you can build on top of it that we’ve heard that teams are really getting a lot out of right now.

Drew: So a theme in the Gatsby world isn’t a look and feel like it would be with CMS like WordPress.

Marcy: Yeah, I mean, it can but that’s not all that it is. So, naming things is very hard. But themes I’ve really enjoyed learning about just the flexibility and being able to, yes, you could include some user interface code. But there could be some query language code that goes in there as well. But the fact that it’s kind of bundled together, makes it easy to distribute. Yeah, it’s been a really neat abstraction that it’s been cool to see what people are building and what themes they’re shipping, and all that.

Drew: Yeah, I can imagine it would lead to some fairly innovative uses of Gatsby. Have you seen anything that’s been, in particular that caught your eye that customers are doing this particularly creative?

Marcy: Yeah. Well, in terms of themes, I mean, one of the first ones I read about there’s a case study on the Gatsby blog, I think from Apollo. And they wrote a documentation site using Gatsby themes and that used a get source plugin. And so, it really kind of decouples your sourcing, and your content, making it so that teams can pull in a theme to use across multiple repos.

Marcy: I’d say that’s the most interesting to me just because of what I can envision it enabling like, past teams I was on where we had to source content, we were just so like limited and where that code could live and how repeatable it could be. And so, seeing a solution now where teams are like, “Oh, this works great.” And that was even last summer, or like that was a case study a while ago.

Marcy: So since then, API’s have been improving, and there’s a whole team working on Gatsby themes. And I know they are rolling out some big improvements in the next few weeks. So, I don’t want to steal their thunder, but there’s some neat stuff coming with themes. They’ve been overhauling some of the blog themes like the core themes that we offer from Gatsby.

Marcy: I know they’re using it internally to build some of our own product announcement, or product improvements that will be announced here in the next couple of weeks. So, lots of cool stuff going on with Gatsby themes, and people selling their own themes and starters. I think that’s really interesting too.

Drew: There’s a bit of a marketplace springing up around Gatsby.

Marcy: There is, Yeah.

Drew: Is there any sort of online training and those sorts of things if somebody wants… If somebody decided that they were really going to get into Gatsby and they needed to learn it quick? Are there run places they can go with that sort of information is available?

Marcy: A ton of it? Yes. There’s definitely the Gatsby Doc’s site, which is gatsbyjs.org/doc’s. And we have tutorials, and I’ve been doing live streams almost every week for Gatsby stuff. There are a ton of educators who have Gatsby material on YouTube and various learning platforms. Egghead, I think some of my teammates from Gatsby have egghead videos as well.

Marcy: So, there is a ton of stuff out there. I would say check the dates on it if you find something. We’re always actively updating the Gatsby Doc’s, some of the older third party videos and things that may, check the dates on those because we can’t monitor every single learning resource for update. It’s hard to keep up with our own staff.

Marcy: Because there’s just so much with how many content sourcing options and use cases. It’s a very broad space. But there’s so much learning material out there, and a ton of ways to get started that you can sort of try and find things like depending on where you are on your learning spectrum. Are you at the beginning stages, are you coming from other technologies and you just need to learn about like what is this React thing.

Marcy: You can sort of pick and choose which materials will work for you based on where you’re at. I’ve been doing a course recently through live streams called Gatsby Web Creators, where we went all the way from beginner HTML, CSS and JavaScript through to creating our first Gatsby site. We just completed that on Friday. And so, it’s been really neat to go all the way back to the beginning.

Marcy: And because a lot of materials with Gatsby, it uses React. So, it’s a pretty big jump to get started with that. So, I really wanted to go back and take the steps to get all the way through to building things with React and Gatsby. So that was really neat. And I’m excited to continue on that route, so that there is more beginner material and more things to help people understand how to build a site with Gatsby because a lot of those skills are portable to other frameworks.

Drew: One of the big questions that is going to come up for anybody who’s thinking about building sort of client project sites using Gatsby, one of the big questions that’s going to come up is about managing content and putting stuff in front of a client. You mentioned already how Gatsby can connect to different content management systems. Is that the primary method that you would put in place to deal with that question? Or does Gatsby have anything in its ecosystem that would enable people to edit content in any way?

Marcy: Yeah, I would say having a CMS or something can make those team relationships work a lot better. I’ve been in those use cases where the dev teams like, “Just learn HTML.” And you see this glaze over from the client of like, “No, I can’t believe you just said that.” So having a system where people can do their best work in whatever ways suits them best, is super, super important.

Marcy: Like you just can’t handle marketer GitHub, and might work some of the time but not all the time. And so, having like a preview and build infrastructure makes that better, and that’s where the Gatsby cloud product space kind of enters into the fray. There are ways to do preview. Without the paid cloud side and Gatsby cloud does have a free tier for personal projects, so it’s not all paid.

Marcy: But we have this, like the open source and the product ecosystem kind of come together so that Gatsby can as a founding organization, make enough money to keep the open source framework, keep that healthy, and keep our community rolling along with that. So, that’s kind of where this open source commercial side comes together, and really enabling some of these workflows that teams need.

Marcy: Some things like getting fast previews, getting builds out the door fast and deployed. And so, there are solutions on the Gatsby cloud side specifically, and then wherever there is an open source way to make Gatsby work like with a preview server or something, we try to document that and make sure our community knows what’s what and how to serve those team needs.

Marcy: Yeah, I would say like, you need some way to preview your CMS changes because it’s like that instant gratification. You don’t want to be waiting an hour for a build to see some content.

Drew: So that’s interesting. The Gatsby cloud service gives you that ability to use a headless CMS service, where you’re just working with the content, but you’ve got no visualization of what it would look like in your site enables you to get a preview of how that would work. Is that right?

Marcy: It is, yeah. And so, it’s part of the trade off of decoupling, your headless CMS, which may have had, like WordPress, you could just look up the front end, but we’re giving it a new front end, and potentially pulling in other sources and other things that WordPress doesn’t know about. And so, decoupling it in that way makes sense. But you still, as a team member, you have to be able to do your work in the speed that you’re rapidly used to.

Marcy: And so, that is where Gatsby preview, Gatsby builds come in to give that front end back to teams so they can collaborate, they can make decisions, get something shipped. So that has sprung up in the last year, getting more features and improvements in all the time and that we’ve heard from some teams that are really starting to see speed increases.

Marcy: And as we figure out like, “Okay, if this build is going slow, why is that?” It’s usually because the site is really, really big. So we’ve been focused a lot on improvements for large sites, and really improving those team, collaborative workflows. It’s a big focus of the team right now.

Drew: So Gatsby cloud is, I guess at its heart is a hosting service. Is it a CDN for deploying your Gatsby sites with a load of Gatsby specific functionality and features around it?

Marcy: I would call it more of a continuous delivery product because it’s not an actual CDN. It integrates with CDNs like Fastly, Netlify. There’s a lot of different providers that you can hook up and some of them for free. You can do a lot for free, which is pretty awesome. I just did it the other day in our last Gatsby web creators session, we use Gatsby cloud and Netlify to build our site.

Marcy: And it enables you to make Gatsby sites faster specifically, because it does have those improvements. It only has to build one type of site. So, there’re some improvements that Gatsby cloud can make, that no other platform can make because they are trying to like support all of these different types of websites and they do them all very well.

Marcy: But for Gatsby, if that’s all you’re building, and there’s quite a few agencies, who are all in on Gatsby, and they want to make it as fast as they can. So, that’s where Gatsby cloud can make some performance improvements specifically for Gatsby, because it doesn’t have to worry about any other platforms.

Drew: So, Gatsby cloud would do your build, and it would then just deploy it to something like Netlify or presumably a whole range of different places.

Marcy: Yep. Yep, it will. And so, it’s the piece of Netlify that it would be using then as it’s uploading these built packages. Built files. It’s not using their builds, so the builds are happening on Gatsby clouds infrastructure, and that’s where some a lot of speed increases can happen. And then there’s still that upload step to get it out to a CDN, whichever one you’ve chosen.

Marcy: But yeah, it seems like teams are really loving this ability to see. I mean, it’s functionality that you would have missed. And so, that’s a necessary thing to add back in, is to be able to do these collaborative previews and get sign offs and all of that.

Drew: So, Gatsby cloud is provided as a service from Gatsby the company, and there’s Gatsby the open source project as well. Is this a similar sort of relationship to like WordPress and automatic have, where you’ve got a commercial entity developing an open source product?

Marcy: I would say so yeah, like Drupal. There’s precedent in tech to have these founding organizations where it’s kind of a virtuous cycle. And we’re working on publishing some governance documentation right now to make sure that, that’s super clear to our community, how we make decisions. But the entire goal is to keep Gatsby sustainable, so that it can continue to be an open source project that people can use it with ever even getting into Gatsby cloud.

Marcy: You could use other solutions with it if you want. And so, we need like enough business to sustain, like the people working on it. And so, I’m kind of in between, like I float in between the open source and commercial side and trying to make sure that we’re prioritizing things. I mean, as you could imagine, we’re juggling a lot of things with how broad the spaces like, we all have our niche use cases that we like, feel really strongly about, we need to do for our jobs.

Marcy: That adds up to be a lot of niche use cases. So, we try to juggle and prioritize and really listen to our community about what hurts right now, what’s painful, what’s going well. And so, that’s been an interesting journey to get for me personally to get back into devREL and really be listening to the community about, how can we make us be even better?

Drew: And is there a big community around Gatsby lots and lots of people using it?

Marcy: There are a lot of people using it, a lot of contributors. So for a lot of folks, it might be their first time contributing to open source like coming over to our docks and joining us for Hacktoberfest and things like that. And so, it has been really neat to see what a big community Gatsby does have, especially with things like accessibility and trying to make sure that frameworks do all they can out of the box for free.

Marcy: And so, there’s this, I don’t know, subset or intersection of accessibility and Gatsby and that’s my happy place. But the broader community, a lot of people learn React or learn web development through Gatsby. And so, that’s really neat to see a progression through our community, and hopefully we get people to come contribute, even if it’s an issue or something of like, “Hey, this link was broken or this part of the docks was confusing to me or it’s outdated.”

Marcy: Like even just telling a framework or a project that you use, that something could be better is a great way to contribute, because you can help us gain insight into the things that could use improvement. So that’s a great way to contribute.

Drew: You mentioned accessibility and of course, people will know you as being an accessibility expert. And they might be surprised to see you working with sort of fully featured front end framework like React, thinking that perhaps the two don’t really go together. Is that always the case at JavaScript heavy front ends are worth less accessible?

Marcy: Well, I wish it weren’t the case. But I think the data has shown that a lot of websites that do use front end frameworks are less accessible than those that don’t. A project that comes to mind is the Web a Million. And actually, I have a blog post, I’m refreshing the Gatsby site to see if my blog post has launched yet. But webbing through the web a million this project, they used their automated wave tool to crawl the top 1 million home pages and evaluate them for some accessibility violations.

Marcy: And it was really depressing results. Like they’ve run it twice now I think, and I think it got worse. So, it’s not great, but I don’t think you can really point to any one framework because there’s plenty of sites that don’t use frameworks that have lots of accessibility problems. So, it’s kind of a broader industry issue, a really society.

Marcy: And so, for me working on a full featured web framework, I saw as an opportunity to try and get more accessibility awareness in the mainstream. And so, that was an intentional move on my part to go and try to make an impact on a lot of sites like working on one site is cool. You can solve some really interesting problems. For me, I wanted to advocate accessibility much more broadly and try to make frameworks the best they can be from the inside.

Marcy: So even if something is rough right now, trying to play that long game of like, “Okay, what web standards things can we talk about? What framework improvements can we make so that if this is kind of rough, like not just give up on it.” So, even if I know it’s… I don’t know, JavaScript is some folks enemy I feel like I like it. You need some JavaScript to make accessible user interfaces, you just do.

Marcy: So, I am trying to like straddle those viewpoints and do the right thing while listening to my activist colleagues and friends kind of out there like pushing us forward as an industry. And then on the inside, I can be the messenger and the person that could try and reconcile some of those huge trade offs and ethical questions about What are we building?

Marcy: So, it’s challenging, but I really like it, because I have an impact to make on the web. And so, web framework. Lots of people are building Gatsby sites. So, seems like a good place to try and make an impact.

Drew: You mentioned briefly that Gatsby uses React at the moment. Is there a possible future where Gatsby might work with other frameworks, might receive a view version of Gatsby?

Marcy: I would love that. I’ve certainly talked about it. There is a pre React plug in, as I mentioned earlier. So you can swap that out. I think a big part of what we are talking about is sustainability of projects, trying to make the right call, these aren’t easy choices to make. It’s not just like rip it out and start over. There’s a lot of concerns that go along with that. It goes deep.

Marcy: So, it’s something we’re actively talking about. And I don’t really have anything specific to share right now. But we do have some internal meetings coming up soon to talk about that sort of thing. So, it’s being discussed, and I would love to have a view flavor, that’d be amazing. But as you can imagine there’s some interesting challenges that come along with that, and we want to make sure it’s the right move so that we’re not like, I don’t know, going down a path and having it not work for whatever reason, then we’re maintaining two frameworks, like how do we make that actually realistic in terms of what we can maintain and make succeed for an open source community?

Drew: So I’ve been learning all about Gatsby. What have you been learning about lately Marcy?

Marcy: Well, I wish it was better but work life balance. I’ve been learning about, for me, unfortunately, I’m in like a burnout cycle. And so, I feel like I’m continually learning the lesson of how to be productive, especially this year in 2020. There’s just like one thing after another. So, trying to get really clear focus on where I want to go in my career, what makes me happy?

Marcy: How can I sustain, and we’re talking about sustainability. Like how can I sustain my own life after a career of really pushing hard on accessibility in particular like, “Okay, how can I kind of take a little step back and make sure that what I am putting out there, what I am doing is meaningful, worth the energy.” See, a lot of my lessons have been kind of that intersection of work and life and trying to make the most of the time that’s been… I don’t know about you, but it’s been pretty stressful for a lot of people including me.

Drew: It’s been very, very stressful. We are at very difficult times, isn’t it?

Marcy: Yeah, yeah. I mean, we have so much to be thankful for in this industry, having opportunities and skills that you can apply. Seeing a lot of layoffs in our industry, really trying to make decisions that reflect where we’re at and not just going through the motions. So that was a big motivator for Gatsby web creators was, “Wow, there’s a lot of school age kids not in school this year, it would be really cool to see an outcome of turning some kids’ eyes onto web development.”

Marcy: Like when I was in seventh grade, and someone came to a class of mine to talk about photojournalism. I was like, “I want to be a photojournalist.” So that actually did work. I got some feedback from someone that said, “My seventh grader’s learning from you, and now they’re really excited about code.” So, that was a really good thing to spend some energy on, in a time where like, that wasn’t something I would have necessarily thought of before being in these circumstances in 2020.

Marcy: So, really trying to be like nimble and make choices that kind of reflect where I want to go and what’s happening.

Drew: If you the listener would like to hear more from Marcy, you can find her on Twitter where she’s @marcysutton and find all her latest goings on, on her personal website, marcysutton.com. And of course you can find out how to get started with Gatsby from Gatsbyjs.org. Thanks for joining us today Marcy, do you have any parting words?

Marcy: Make the most of it wherever that might be.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

andy-bell-200x200-1
30 Jun

Smashing Podcast Episode 19 With Andy Bell: What Is CUBE CSS?

by TBSCategories: News

Smashing Podcast Episode 19 With Andy Bell: What Is CUBE CSS?

Smashing Podcast Episode 19 With Andy Bell: What Is CUBE CSS?

Drew McLellan

Photo of Andy BellToday, we’re talking about CUBE CSS. What is it, and how does it differ from approaches such as BEM, SMACSS, and OOCSS? I spoke to its creator, Andy Bell, to find out.

Show Notes

Note: Listeners of the Smashing Podcast can save a whopping 40% on Andy’s Learn Eleventy From Scratch course using the code SMASHINGPOD.

Weekly Update

Transcript

Drew McLellan: He is an educator and freelance web designer based in the U.K. and has worked in the designer web industries for well over a decade. In that time he’s worked with some of the largest organizations in the world, like Harley-Davidson, BSkyB, Unilever, Oracle, and the NHS. Alongside Heydon Pickering, he’s the co-author of Every Layout, as well as running Front-End Challenges Club which is focused on teaching front-end development best practice via short, fun challenges.

Drew: His latest venture is Piccalilli, a website newsletter with tutorials and courses to help you level up as a front-end developer and designer. So we know he’s an experienced developer and educator, but did you know he was the first person allowed to compete at Crufts with a panda?

Drew: My Smashing friends, please welcome, Andy Bell. Hi, Andy, how are you?

Andy Bell: I’m smashing, thanks. How are you?

Drew: I’m very good, thank you very much. Now I wanted to talk to you today about something that you posted on your site, Piccalilli, about a CSS methodology that you’ve developed for yourself over recent years. First of all, I guess we should probably explore what we mean by a CSS methodology because that could mean different things to different people. So when you think of the CSS methodology, what is it to you?

Andy: That’s a good, hard question to start with, Drew. Appreciate that, thank you!

Drew: Welcome!

Andy: It’s a tricky one. So, for context, I’ve used BEM for a long time, and that is Block Element Modifier. That’s been around for a long time. The way that I look at a CSS methodology is, it’s not a framework, it’s an organization structure. That’s how I like to see it. It’s like a process almost. It’s like you’ve got a problem that you need to solve with CSS and you use the methodology to solve it for you and keep things predictable and organized. BEM’s just legendary for that because it’s been wildly successful.

Andy: Then you could almost qualify things like the style components and that sort of thing. You can almost say that they’re methodology orientated even though they’re a bit more framework entwined, but still, it’s a methodology of breaking things into tiny molecules. So essentially that’s what I’m trying to do with CUBE CSS as well. A thinking structure, I think I described it as.

Drew: So it’s an application of process for how you architect and you write CSS, and it’s not so much anything that’s based on tools or any other sort of technology, it’s just a sort of work flow. So there’s lots of different approaches out there. You mentioned BEM. There’s SMACSS, OOCSS, Atomic CSS. And then you’ve got these sort of unusual lovechild approaches like ABEM. Have you seen that one?

Andy: Yeah.

Drew: Why publish your own?

Andy: Yeah, yeah. Why make your own? That’s a very good question. I think those who know me well know I like to sail against the tide a lot. It’s mainly because I tend to do lots of varied projects as well, in varied teams. So it’s very hard, I’ve found, to work with BEM with a traditional developer because they’re used to using CSS for what CSS is all about: the cascade, et cetera, and that’s why I sort of stole that from the language.

Andy: On the other flip side is that less structured methodologies, it’s harder to work with a programmer, JS sort of person because they like structure and organization and small components, which is understandable working with the language that they work in.

Andy: So I found myself in these positions where I was working with different types of people, different types of projects where one methodology wasn’t quite working. Over the years, I’ve just been playing around with this idea of how things go, and then there’s the stuff me and Heydon did, Every Layout, which sort of enforced the big part of it, which is the C, the composition part, and then I’ve just sort of evolved it very rapidly over the last six months.

Andy: The only reason I wrote an article about it was because I was just doing this course and I thought I’d better write some supplementary material to go with it so people understand it, and it’s absolutely blown up. So maybe we’re not over methodologies quite yet, Drew.

Drew: So the course material that you’ve been putting together actually uses CUBE CSS as its methodology, does it?

Andy: Yeah. So a good 50% of the course is actually front-end, even though it’s a course unlimited. It’s so, so deeply entwined in the way that we build the front-end that I couldn’t just say, “Oh, by the way, this is how I write a nice CSS,” and then leave it. I know people like to get into the detail, so I was like, what I’ll do is, I’ll write this post that’s really long and really detailed and then if someone wants to skill up and really understand what we’re doing, then they can do, and the rest is from there. And here we are today, Drew, sitting and chatting about it.

Drew: So if somebody already understands BEM and is maybe already using BEM, as an example, because that’s probably one of the widest adopted methodologies, isn’t it? So if they’ve already got an understanding of BEM and they’re coming to CUBE, is that something that they would find easy to adopt? Are there many similarities or is it completely different?

Andy: Yeah. I’d say going from BEM to CUBE is probably a smooth transition, especially the way I like to still write the CSS for CUBE. So the majority of stuff’s happening at a higher level. So it’s happening at the cascade level and it’s happening global CSS, using the utilities to do a lot of the stuff. But when you come into the nuts and bolts of it, it’s very BEM-like components, blocks and elements. The only thing that’s sort of different from BEM is, instead of having modifiers, we use this thing called exceptions instead which is, instead of using CSS classes, it turns to data attributes, which I think gives a nice bit of separation and a real exception, which is what a modifier should be.

Andy: Part of the reason why I’ve sort of sailed away from BEM was because I found the way I was working with it, especially in design systems, was modifiers were dominated and it became a problem because it was like, what is the role of my block at this point? Because if I’m modifying it to the point where it’s unrecognizable regularly, then is this methodology still working how it’s supposed to work?

Andy: Then there’s the whole design token stuff, the stuff that Jina did with the Lightning Design System which we’ve all started adopting now. The utility class stuff really started to make sense with that approach. So I just sort of smushed all the things I like about other people’s work and slotted into my own instead.

Drew: You talk about with BEM, the sort of modifier approach kind of getting out of control. Was that one of the main pain points with BEM that CUBE tries to address?

Andy: Yeah, absolutely. I do like the modifier approach with BEM, it does make sense. What I like about BEM is something that I still do, is the double underscore for an element, and then there’s the double dash for a modifier. I like that way of organizing things. It was just a case of okay, well, a lot of the modifiers I can actually account for with utility classes and then the other bits…

Andy: So the example I use in the article is, imagine you’ve got a card and then the card is flipped, so the content appears before the image. So then that makes sense, to see display: flex and then you reverse it, reverse the order. That makes sense, to have an exception rule for that because it’s an exception of the card’s default state, and that’s how I like to see it. It’s like an affected state on that component, is what an exception is, and that makes sense.

Andy: With a lot of the stuff that I’ve done more recently, the modern front-end stack with reactive JavaScript, there’s a lot of state changing and it’s makes sense to handle it appropriately between CSS and JavaScript because they are becoming more and more entwined with each other, whether you like it or not. It’s a common language for them. As you can see by my face, very much not, but there you go. You’re probably thinking, “Actually, I’ve been working with react quite a lot recently, so I’m the other way round.” So I can see that as well.

Drew: So let’s get into CUBE then. So CUBE stands for Composition Utility Block Exception. Is that right?

Andy: Yeah. That’s the one.

Drew: What on Earth does that mean?

Andy: Oh, mate, you should have heard it before! I was doing a talk last year. I did a talk, and it was called Keeping it Simple with CSS that scales, and in there I sort of introduced an earlier version of it called CBEUT, which was Cascade Block Element Utility Token. It was rubbish. I hated the name of it. I did it a couple of times, this talk last year, and I really didn’t like the name. Then when I came to doing this stuff this year, I thought, “I really need to think about what it actually is and what it’s called.” I think CUBE is a little less rubbish. I think that’s the best way I can describe it.

Andy: But then, names are always rubbish for these things, aren’t they? I mean, like BEM, what a rubbish name that is! But we all do it. Look at Jamstack: that’s a terrible name as well, isn’t it?

Drew: My lips are sealed!

Andy: Your boss is going, “What?” It’s true. It’s just the way it is, isn’t it, in our industry.

Drew: It seems that a lot of the CSS methodologies try and work around some of the features of CSS, things like the cascade. My understanding from what I read is, CUBE tries to make use of those sort of features and properties of CSS.

Andy: Yeah. A good analogy for it is SCSS, like Sass, is an extension of the natural CSS language, isn’t it? You’re pretty much right in CSS still. So CUBE CSS is like that. So it’s an extension of CSS. So we should still write CSS, as CSS should… well, it’s supposed to be written. Let’s be honest, that how it’s supposed to be written, is the name gives it away: Cascading Style Sheets. So it’s embracing that again because what I’ve found is that I’ve gone all the way down to the micro-optimization level. I’ve been down the path that I see a lot of people going down recently where… and I’ve mentioned this in the article as well, where I can see… there’s some evidence of it recently. I’ve spotted people have been creating spacer components and stuff like that, and I understand that problem, I’ve been in that situation.

Andy: The way I fixed it was, instead of drilling down and trying to micro-optimize, I actually started thinking about things on a compositional level instead because it doesn’t matter how small your components are, at some point they’re going to be pages, they’re going to be views. You cannot avoid that, that’s how it’s going to be. So instead of trying to say, “Right, I need these tiny little helpers to do this layout,” you say, “Right, I’ve got a contact page view, or a product page view, and that’s a skeletal layout composition. Then inside of that I can slot whatever components I want in there.” We’ve got things like Grid and Flexbox now which make that much more achievable, and you can essentially put whatever you want inside of the skeletal layout, it doesn’t matter. Then the components should, at that point, behave how you want them to behave, with or without container queries.

Drew: This is the composition part of CUBE where you’re looking at things at more of a macro level, looking at how components can be composed into a view to create the sort of pages that you need to create for a site or an app or what have you.

Andy: So it’s creating rules, essentially. It’s like guidance. It’s trying to get guidelines for something. It’s not like a strict rules, like, you should do this, you should do that. That’s essentially what you’re doing with the browser, with this methodology, is you’re saying… you’re not forcing it to do anything. You’re saying, “Look, ideally, if you could lay it out like this, that would be great, but I understand that that might not be the case so here’s some bounds and some upper and lower levels that we can work with. Do what you can, and cheers.” Then you just chuck some components at it and let it just do what it does. You add enough control in there for it to not look rubbish.

Andy: So a good example would see… we do a layout in Every Layout called the switcher, which essentially will in-line items until a certain point where the calculation that works out how wide it should will just stack them on top of each other. But because we add margin to the in-line and the block, it works, regardless of what the state of it is, it still looks fine. That’s the idea, is that we’re not telling the browser to say, “You must layer this three column grid out.” We’re saying, “If you can layer a three column grid out, do it. Otherwise, just stack and space instead.” So it’s that sort of methodology, of letting the browser do its job really.

Drew: Many of the different approaches that have come along for CSS over the last few years have very much focused on the component level of dealing with everything like it’s a component. CUBE doesn’t downplay that component aspect so much, it just gives this extra concept over the top of taking those components and composing them into bigger layouts, rather than just saying the layout’s just another component.

Andy: Yeah, that’s a good point, yeah. I think the thing to say about components is they’re important, especially in modern front-end stuff. We do a lot of component stuff, system stuff. But the way I see a component is, it’s a collection of rules that extend what’s already been done.

Andy: The point I make in the article is, by the time you get down to the block level, most of your styling has actually been done, and really what your component is doing is dotting the Is and crossing the Ts and it’s saying, “Right, in this context…” So for a card, for example, make the image have a minimum height of X, and add a bit of padding here. Do this, that and the other. Put a button here. It’s just sort of additional rules on top of what’s already been inherited from the rest of the CSS. I think that’s probably the best way to describe it.

Andy: Whereas in BEM, the component is the source of truth. Until you put that class on the element, nothing has been applied at that point, and that method works. I just found I wrote more CSS by doing that, and more repetitive CSS, which I don’t like doing.

Drew: Would you consider the typography and the colors and the vertical rhythms, spacing, and all of that, is all that part of the idea of composition in this model?

Andy: Yeah. In a global CSS, yeah, absolutely. The vertical rhythm especially, and the flow. We did an article on that at 24 ways, didn’t we, a couple of years ago, the flow and rhythm component. That was a sort of abstract from this approach as well, where you set a base component which essentially uses the lobotomized owl selector. I don’t know how I’m going to describe that on the radio, but we will. We’ll just put, I think, in the show notes about the Heydon article or something. But essentially that, it selects child elements… sorry, sibling elements.

Andy: So it says, “Right, every element that follows element X have margin top of CSS costs and property value,” and then the beauty of that is then you can set that CSS custom property value on a compositional context as well. So you can say, “Right, in this component, if there’s some flow on the go, we’ll set flow space to actually be two rem because we want it to be nice and beefy, the wide space.” Then in another one you might say, “Actually, I want flow space to be half a rem because I want it to be tight.” This is all happening, all the control is coming from a higher level and then what you’re doing is, you’re adding contextual overrides rather than reinventing it each time, reinventing the same thing over and over again.

Drew: So that’s the C, Composition. Next we’ve got U, which is Utility. So what do we mean by utility?

Andy: So it’s a class that does one job, and it does it really well. That could be an implementation of a design token which… it’s an abstract of properties. Usually it’s colors or typography styles, sizing, and rules like that. The idea is you generate utility classes that apply those. So you’ve got a utility that will apply background primary, which is like the primary color, and then color primary, which is the text color. Then you might generate some spacing tokens for marginal padding, and all those sorts of things. They just do one job. They just add that one spacing rule, that one color rule, and that’s it.

Andy: But then you’ve got other utilities as well. So a good example is a wrapper utility. What that will do is, it will put a maximum width on an element and then it will put left and right auto margin to sit it in the middle of the thing. So it’s just got one job, and it’s just doing it efficiently and well.

Andy: So you’ve got your global styles, you’ve done a lot of your typography settings and a lot of your flooring space. Your composition’s then giving context and layout. Then utilities are applying tokens directly to elements to give them those styling that you need. So like a heading, for example, you’re saying, “I want this to be this size and I want it to have this lead in, and I want it to have this measure.” Then at that point… this is what I was saying about the blocks… then you go further down the stack, and you’ve already done most of the work at the point.

Andy: So they give you this really efficient way of working, and because HTML sort of streams down the pipe as well, it’s really nice to abstract the workload onto HTML rather than CSS as well, I’ve found. I used to really get into utility classes, like in this sort of old curmudgeon style of, “Oh, separation of concerns,” but I actually think it’s a really decent way of working. I mention in the article that I actually like Tailwind CSS. I think it does work, and I really like using it for product typing because I can really put something out really quick. But I think it just goes a little bit too far, does Tailwind, whereas I like to rain it in when it goes beyond just applying a single rule on a class. So that’s it, I think. Do you?

Drew: So, yeah, you talk in the article a lot about design tokens, which is something that we’ve talked about on the Smashing Podcast with Jina Anne back in episode three, I think it was. So it sounds like design tokens are a really fundamental aspect.

Andy: Yeah. Oh, God, yeah. I remember so vividly when Jina was doing the Lightning Design System stuff because I was building a design system at the time, or something that resembled a design system, and we were struggling to get executive approval of it. When the Lightning Design System came out, I literally just sent them link after link and I said, “This is what we’re doing. We’re building a design system. This is what Salesforce are currently using it for.” I remember her work at the time actually helped me to get stuff through the door.

Andy: Then the design token stuff has always stuck with me as being a really good way of applying these rules. Because I’m a designer by trade, so I can just sort of see that organization and the ability to organize and create a single source of truth being really useful because it’s something we’ve not really had in digital design, especially in the Adobe era of working with Photoshop and stuff, we just didn’t have that luxury. We had it in print with the Pantone Book but we didn’t have it in digital with random hex codes all over the shop.

Andy: So it’s just great. I love that level of control. Actually, I think it aids in creativity because you’re not thinking about unimportant stuff anymore, you’re just thinking about what you’re doing with it.

Drew: Does the implementation of those design tokens matter particularly with the approach? Is it always CSS custom properties?

Andy: I think that’s a really important point with CUBE. Some of the responses I’ve had, people have struggled with this a little bit. There’s no mention of technology in it whatsoever. The only technology that’s consistent is CSS. You can do it however you want. You could do all this with whatever CSS and JS things people are doing now, or you could it with just Vanilla CSS. You could do it with Sass. I do it with Sass. Less, if that’s what you’re still doing. All these available technologies, post CSS, all these things. You can do however you want to do it, it doesn’t matter.

Andy: The idea is that if you follow those sort of constructs, you’ll be fine. That’s the idea behind it. It’s a very loose and not strict as some of the methodologies are. I’ve seen it with BEM especially, people get really ingrained in the principles of BEM to the point where it’s like you’re not even solving the problem anymore. I think that you’ve got to be flexible. I said it in this talk last year. I was like, “If you stick to your guns too tightly, you can actually cause problems for yourself in the long run because you try and follow a certain path, and you know it’s not working anymore.” You should always be flexible and work with a system rather than working to the letter to it.

Drew: So the B, the B is Block. You’ve talked about this idea, that by the time you get down to the block level, most of everything should be in place, and then the block level styling is only really concerned with the actual very detail of a particular component. Generally, is the concept of a block similar to what people will be familiar with?

Andy: Oh, absolutely, yeah. So imagine your BEM component and take all the visual stuff out of it, and that’s what you’re left with, essentially, the block. This is what I struggled to articulate when I first started thinking of this methodology. A block is actually really a C, it’s a composition, but that makes it really difficult because you’re into recursive territory there and I think people’s brains would explode. But really that’s what a block is, it’s actually another compositional layer but more of a sort of strict context, so like your card, your button, your carousel, if that’s what you like doing still, and all that sort of stuff.

Andy: It’s like a specific thing, a component, and then inside of there you’re setting specific rules for it to follow, really ignoring the rest so you’re not… You might apply tokens in the blocks, and I do do that still, but really it’s more layout orientated, is a block, as far as I work with them, or at least taking the token and applying it in a specific way, like a button hover status, stuff like that. So really your block should be tiny by the time you get down to them, they shouldn’t be really doing much at all.

Drew: So it could be as small as a hyperlink.

Andy: Yeah.

Drew: But it could also be a compound collection of other blocks?

Andy: Yeah. Like a module sort of thing. You could definitely do that. Because, again, that goes back to the sort of compositional aspect of it, is that whatever goes in it shouldn’t matter. The good example of that is like the card. So the content of a card is, say, like a heading, a summary and a button. You shouldn’t really be specifically targeting those three elements. You should be saying, “Look, anything that happens to find itself in content, have some flow rules in there and have some sort of compositional layout rules,” and then it doesn’t matter what you put in there. You might decide that you want to put an image in that content thing and it should just work, it should just look fine.

Andy: That’s the whole point of working with CSS. It’s a very forgiving way of working with CSS. You’re making your life a lot easier by being less rigid because when stuff accidentally finds itself in something, which it will, it doesn’t look horrific as it could do if you were being more specific about things, is what I’ve found.

Drew: I definitely need a lot of forgiveness around my CSS!

Andy: I know you do!

Drew: Cheers! So that’s the B. The last thing is E: E is Exception. Now we’re not talking about error messages, are we?

Andy: No, no. It’s a sort of-

Drew: We’re not talking about JavaScript exceptions.

Andy: Yeah, yeah. There should be none of that at this point. I should hope not anyway, otherwise you really are in the woods at that point: I don’t think I’m going to be able to help you! The whole idea of this is… so you’ve created the context with your block, and an exception is exactly that, it’s like an exception to the rule: so a flipped card, or it might be a ghost button. So you know those buttons that have just got a border and a transparent background? That would be an exception because a button has probably got a solid background color and then the label color. So it’s creating a sort of distinct state of variation.

Andy: The reason why I do this with data attributes instead of classes, and the reason why that is is because a) I think it’s nice to have a distinction. So when you’re scanning through lots of HTML, you can see data, hyphen something, you’re like, “Right, okay, something has definitely changed on this element.” The other thing is that it’s very nice to give JavaScript access to that state, and vice versa as well. So I really like applying state with data attributes in JavaScript. I think that is essentially what they’re for, a sort of communication layer. The harmony between them seems to work really well.

Andy: So a good example is, say you’ve got a status message and then JavaScript will add data state is either success, error or information, or something. You can then hook into that with your exception styles in CSS. So you know that’s an exception of the status component and it’s going against its default state. So it’s just a really handy way of working with things. It’s predictable on both ends: it’s predictable on the CSS end, and it’s predictable on the JavaScript end as well.

Drew: I guess it’s quite nice that something that class names don’t give you is a property and value. So if you want to have something like that which is the state, and it can either be success or failure or warning or what have you, you can specifically address that state property and flip its value. Whereas with a big long list of class names, if you’re manipulating that in JavaScript, for example, you’re going to have to look at each one of them and add that business logic in there that says, “I can only set one of these,” and what happens if two of those classes are applied to the same element? You can’t get that with a data attribute, it only has one value.

Andy: Yeah. That’s a good way of saying that, yeah. It is very helpful, I’ve found, to work like that.

Drew: That’s quite interesting. I don’t think I’ve seen any other methodologies that take that approach. Is that completely unique to CUBE, doing that?

Andy: It might be. I don’t really pay much attention to other stuff, which I should do. Someone else is probably doing that. I’ll tell you now, it’s been the most controversial aspect of it. Some people really did not like the idea of using data attributes. The thing is as well, and how I respond, is, do what you want. We’re not telling you to do things in a certain way, it’s just suggestions. If you want to do exceptions to CSS classes, like modifiers, then knock yourself out. The CUBE police aren’t going to come knocking at your door. It’s absolutely fine.

Andy: The CUBE thing is a thinking thing, it’s a structure. You apply that structure however you want to apply it, with what tooling you want, or whatever technology you want. As long as you keep things consistent, that’s the important thing.

Drew: So there’s no such thing as pure CUBE?

Andy: The way I write it is pure CUBE, Drew. Everyone else is just a fake, it’s just a weak immitation.

Drew: Apart from to you, no-one can say, “That isn’t textbook CUBE.”

Andy: No, that’s it. No-one can dispute that really, can they? So, yeah, I’ll go with that. Gives you a bit of clout or something, I think, something like that.

Drew: Can you mix and match a CUBE approach with other methodologies? Can you use bits of BEM?

Andy: Yeah, I reckon so. I’ve been thinking about it a little bit because I’m going to do some more stuff on it soon because it’s become quite popular, so people will want more work. One thing I’m going to look at is how to approach using the CUBE methodology with something existing.

Andy: So there’s two opposite ends of the scale. A good question that people have asked is: “How does this work with every layout, the other stuff?” I’m like, basically, every layout is the C. That’s what every layout is, it’s the compositional layer. Then someone else asked, “Well, how would this work with something like Atomic Web Design, like their stuff that Brad Frost did? It’s like, well, you could break those pieces up and apply them at each level. Atomic Design goes all the way down into the micro detail. It’s abstracting that into using, right, okay, well I can apply this with utilities, so the molecules, I think. I can apply that with the utilities, and it’s translating what you know already into this slightly different structure of working.

Andy: Really, it’s a renaming for a lot of things. I’ve not invented anything here, I’ve just sort of, like I say, I’ve just stolen things that I like. I love the way that some of the Atomic Design stuff is thought about. That’s really some smart work. And BEM. The stuff Harry did, the Inverted Triangle CSS, I thought that was really cool. So I’ve just sort of nicked bits that I like from each one of them and sort of stitched them all together into this other hybrid thing, approach. More to come, I think.

Drew: Can the CUBE approach be applied to existing projects that already have CSS in place or is it something you really need to start on a fresh project with?

Andy: That very much depends. So if you’ve got like a bootstrap job and it’s just got thousands of lines of custom CSS, that I’ve definitely been involved in before, then I think you might be trying to put a fire out with a bottle of water at that point. But if you… say, for instance, if you’ve got a rough BEM setup and it’s gone a bit layer-y, you could use CUBE to refactor and actually pull it back into shape again.

Andy: It depends, the answer to that one. But it’s doable, as with everything. If you really want it to work, Drew, you can do it if you want, can’t you? The world is our oyster!

Drew: Especially if your BEM site’s gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I’ve noticed in the examples that you’ve given… and I’ve got an eagle eye, I’ve seen you’ve been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? What is that about?

Andy: I’ll tell you what, if there’s ever one thing that I’ve done in my whole career that’s just been absolutely outrageously controversial… and you follow me on Twitter, you’ve seen what comes out of my mouth… it’s those bloody brackets! My, God! People either love them or hate them. They’re Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they’re structured, the way I do it is, block at the start and then I’ll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we’ll go back to the card again. But then say that there’s a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you’ve got three groups of stuff.

Andy: When you come to it, if you’ve got that order in your head each time, you know, okay, right, this first group’s blocks. Oh, that’s looks like another block. I’ve got that one. Then it’s like, right, they’re definitely utility classes. Then what I might even do is, if there’s a lot of design token implementation, have that in a separate group. So it’s just very clear what each group is doing, and there’s a separation inside of the classes there as well. I’ve found it really helpful. Some people find it incredibly offensive. It’s definitely a do it if you want to do it. Definitely you don’t have to do it.

Andy: It’s quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there’s a big section at the end where it explains exactly what they’re doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I’ll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I’ve worked on really, really complex front-ends… and we did a little bit of stuff together, didn’t we, last year?

Drew: Yeah.

Andy: You’ve seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there’s just so much going on at the time, there’s so much different stuff happening. I’ve just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what’s with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that’s just come out? They’ve bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you’ll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I’d definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I’ve used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn’t have a clue what was happening.

Andy: I think that’s one problem I’ve found with these sort of over-engineered approaches, which I think it’s fair to say Tailwind is, is that there’s a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there’s still people that are just getting into the game that we need to accommodate, and I think having stuff that’s closer to the language itself is more helpful in those situations because they’re probably learning material that is the language as it is. So I think it’s just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you’re going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I’ve seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That’s not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there’s a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we’ve got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I’ve never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What’s the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that’s all I expected it to be, and it’s just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There’s definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I’ll expand on this post and actually make some documentation.” I’ve got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there’s stuff to go. It’s how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you’re aware of to using CUBE? Are there problems that it doesn’t attempt to solve?

Andy: Yeah. This accent, Drew, it just won’t go way, no matter what I do! In all seriousness, I think CUBE’s got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I’ll probably be struggling with this and trying something else. I think that’s the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won’t work for everyone as well, I know that for a fact. I know that from my comments. I don’t expect it to work for everyone. I don’t expect anything to work for everyone. It’s the same with JavaScript stuff: some people like the reactive stuff and some people don’t. It is what it is. We’re all people at the end of the day, we all have different tastes. It’s all about communicating with your teammates at the end of the day, that’s the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you’re just working on real projects all day, every day. But you’ve recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn’t it? What’s it all about?

Andy: Very kind of you to say, Drew. You’ve actually worked with me, so that’s high praise. But the Piccalilli thing is an evolution. So I’m a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It’s something that I’ve been doing it for so long now, 10 years… well, 12 years now actually.

Andy: I fancied doing something a bit different and applying the knowledge that I’ve got and actually sharing it with people. I’ve always been very open and sharing, and I wanted to formalize that. So I created Piccalilli to write tutorials, but mainly for courses that I’m producing: that’s the main meat and potatoes. And then there’s the newsletter which is… people are really enjoying the newsletter because I share cool things I’ve found on the internet every week. That’s the backbone of it. It’s just going really well. That’s essentially where I want to see myself doing more and more full-time, as the years go on, I think.

Drew: So what’s coming next for Piccalilli? Have you got anything that you’ve got coming out?

Andy: Thanks for the door open there, Drew! By the time this recording goes out, the first course will be live: Learn Eleventy From Scratch, and that’s where we learn how to build a Gatsby website! No, you learn how to build an Eleventy site. So you start off with a completely empty directory, there’s nothing in it, it’s empty, and then at the end of it you’ll finish up with this really nice-looking agency site. We learn all sorts in it. You learn how to really go to town with Eleventy. We pull remote data in from places. We use CUBE CSS to build a really nice front-end for it.

Andy: If you want to get into the Jamstack and you want to get into static site generators, or just how to build a nice website, it’s just a really handy course, I hope, for that. It’s currently being edited within an inch of its life as we’re talking. It’s going to be cool, I hope, and useful. But that’s an accumulation of a lot of stuff I’ve been doing over the last couple of years. So it should be fun.

Andy: So buy it, and I’ll do a discount code, do like smashingpod for 40% off, and you can get it when it comes out.

Drew: Amazing. We’ll link that up. Have you figured out how to spell Piccalilli reliably yet?

Andy: I was on with Chris and Dave with the ShopTalk Show and I said on there, “If there’s ever one thing you want to hire me for it’s to write Piccalilli by hand first time without even thinking about it,” because I’ve written that word so many times that I just know exactly how to spell it off by heart. So the answer to your question is yes.

Drew: Well, I’m still struggling, I’ll tell you that much!

Andy: It is hard. Oh, God. I totally empathize. It took me a long time to learn how to spell it but it’s one of those words in our vocabulary. This year I’m trying to spell necessary without making a spelling mistake!

Drew: So I’ve been learning all about CUBE CSS. What have you been learning about lately, Andy?

Andy: Do you know what? This is going to surprise you, Drew. MySQL is what I’ve been learning about recently. So, basically, Piccalilli is totally self-published. It’s an Eleventy site but it’s got an API behind it, and that’s got a MySQL database behind it. The stuff that gives people content that they’ve purchased requires some pretty hefty querying. So I’ve just actually properly invested in some MySQL… especially the difference between joins, which I didn’t actually realize there was a difference between each type of join. So that’s been really useful and it’s resulted in some pretty speedy interactions with the database.

Andy: I used to run this thing called Front-End Challenges Club and when I first launched it it just collapsed and died on itself because MySQL was shoddy to say the least. So I’ve really been learning how to do that because I’m not a backend person at all, I’m a pixel-pusher. So it’s definitely not in my remit. That’s more your neck of the woods, isn’t it? I find it really cool, MySQL. I actually really like writing it. It’s a really nice, instructional language, isn’t it?

Drew: It is, it’s great. I learnt SQL at school.

Andy: Wow!

Drew: We’re talking like 20 years ago now.

Andy: Did they have computers in those days?

Drew: They did, yeah. We had to wind-

Andy: Did you have to write it by hand?

Drew: We had to wind them up! We did. But, I tell you, for a developer, it’s akin to learning your times tables: one of those things that seems like a bit of a chore but once you’re fluent, it just becomes useful time and time again.

Andy: Yeah. For sure. There’s really tangible differences as well. You really see the difference in speed. I really like working with Node because that’s really fast but Node and MySQL is just… not a very common choice, but I think it’s a pretty good choice. I think it works really, really well. So I’m happy with that. As you know, I don’t like writing PHP. So that’s never going to be an option.

Drew: If you, dear listener, would like to hear more from Andy, you can follow him on Twitter where he’s at hankchizljaw. You can find Piccalilli at piccalil.li, where you’ll also find the article describing CUBE CSS, and we’ll also add links to all of those in the show notes, of course.

Drew: Thanks for joining us today, Andy. Did you have any parting words?

Andy: Stay safe, and wear your mask.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
mina-markham-200x200-1
16 Jun

Smashing Podcast Episode 18 With Mina Markham: How Can I Learn React?

by TBSCategories: News

Smashing Podcast Episode 18 With Mina Markham: How Can I Learn React?

Smashing Podcast Episode 18 With Mina Markham: How Can I Learn React?

Drew McLellan

Photo of Mina MarkhamIn this episode of the Smashing Podcast, we’re talking about learning React. What’s React like to work with, and how can experienced developers get started? I spoke to Mina Markham to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is a front-end architect, conference speaker and organizer, and lover of design systems. Her work on the Pantsuit patent library for Hillary Clinton’s Hillary for America presidential campaign marked a watershed for design systems within the industry and was featured on publications, such as Wired, Fast Company, and Communication Arts. Like many of us, she writes code for a living, currently as a senior engineer at Slack. So we know she’s a talented and forward thinking developer, but did you know she was once mistaken for Patrick Swayze? My smashing friends, please welcome Mina Markham. Hi Mina. How are you?

Mina Markham: I’m smashing.

Drew: Good to hear. Now, sometimes on the Smashing Podcast, we talk to people about the subject that they’re best known for. And sometimes it’s fun just to talk about something a bit tangential. Now, I could chat to you all day about pattern libraries, design systems, the amazing work you’ve done in that particular area, and I could talk to you about subjects that you’ve perhaps spoken about, events, such as the Event Apart, things like art direction. And we could obviously talk about CSS until the cows come home. But you tweeted a few days ago, and I realized that we’re actually both in the same boat in that we’re both experienced front-end engineers and we’re both recently started working with React. So before we get onto React itself, where were you coming to up to this point? Had you been working with other libraries and frameworks for JavaScript development?

Mina: No, actually I’ve been doing mostly vanilla JavaScript for a while. And before that, of course I got into JavaScript. Let me rephrase that. I started working with Java script using jQuery because it made the most sense to me. It was something that was very easily for me to parse to figure out what was happening. And then from there I backtracked to doing just vanilla, plain JavaScript, ESX, and I hadn’t really gotten too much into the framework wars. I had no, like I had no favorite. I had no dog in the fight. I was like, “For you, React, whatever. I don’t really care.” But times change.

Drew: And in this sort of way of working with vanilla JavaScript, because I’ve done a lot of that myself as well. I’ve worked with various frameworks. I’ve done a lot with jQuery back in the day. I worked with YUI, Yahoo User Interface Library. Had you felt many of the pain points that something like React’s architecture tries to address?

Mina: I don’t think I ever had. I spent most of my career making websites versus web apps and things like that. So everything I did was pretty static up to a certain extent. So I never really had to deal with state management, things like that. So the pain points that React attempts to solve I had never really applied to the kind of work that I did.

Drew: Generally speaking, what’s the sort of nature of the projects that you’ve with React so far?

Mina: It was actually only been the one project, which I’m currently working on and I can’t give away too many details because public company and all that good stuff.

Drew: Of course.

Mina: But essentially what I’m trying to do is I’m trying to use React to, it’s a very interactive sort of product where I need people to be able to enter in and save data at a certain state and then manipulate it and generate something else with said data. And that’s just something that it’s not simple DOM manipulation at that point. It really is a lot of more complex, front-end manage of data and managing the state of said data. So there really was no other alternative but to use some kind of library that attempts to solve that problem. I knew I wouldn’t be able to get past with just plain JavaScript. I contemplated maybe handling somethings on the server side, but again, due to the very interactive nature of what I’m working with, it need to be in the client. And so we already use React at Slack for various other things. And so I was like, “Okay, well we just should go ahead and adopt the same thing that the rest of the parent the companies are using and go from there.”

Drew: One of the things that I’m always seems to be a pain point with people picking up React is getting to grips with the tool chain that’s needed to get things working, Webpack being an obvious elephant in the room. Have you had to do much configuration of the tool chain or like me if you had the luxury of teammates doing it for you?

Mina: Oh, I love the infrastructure team at Slack the data. The front-end infrastructure team at Slack, they handled all of that. I didn’t have to think about it. It was great. Because I tried to learn React before in the past. Usually the way I learn best is by actually working and implementing on things. And we use React to build a lot of hillaryclinton.com back in 2016. So it’s not like I’ve never worked with people who use it. It’s just my work never directly needed me to get involved. But that code base was very complex and very sophisticated, and there was so much happening that there’s such a barrier to entry to try to learn anything in there if you didn’t already know how React and Redux and all of that works, which I didn’t. So I wasn’t really effective in learning in that environment.

Mina: Luckily, here I do have people to like take away a little bit more of the complex bits of it. I don’t have to worry about the Webpack config at all. That’s been set up. That’s been tried and tested and ready to go. I am in a similar boat where we also use Redux in addition to React, which I didn’t realize were two different things. I didn’t know which part handled which. Dropping into a code base like that, it was a little disorienting because I didn’t realize that they were all the same thing. I had people who were seasoned React developers telling me, “Oh, we also are using Redux, which makes it a little bit harder for you to really learn what React all can do if you’re starting from scratch.” And I never quite knew what they meant by that because I didn’t know what they were talking about.

Mina: To answer your original question, I am still having a little bit more of a little bit barrier to entry, because it’s not just learning React. I’m having to learn React and also how to use the Redux store. So those two things at the same time can be a little much.

Drew: Yeah, I’ve found exactly the same thing coming into an existing code base as my first React project that uses Redux. And I think as is the nature of any of these sort of technologies when they’re young, they iterate really quickly, and what’s best practice at one point, 6 months later has moved on and there’s a different way of doing things. And when you have a code base that spans many years, you can sometimes have different styles of implementing things in there. It doesn’t always keep sync. And of course, if you’re following a tutorial or whatever to learn, you’re reading books, you’re using resources, they will be in the most modern version of how to do things. And that doesn’t necessarily nit to what you see when you look at an existing, mature product. Is that something you’d experienced at all, or have you managed to keep your code base really up to date?

Mina: I think that is something that I definitely have been experiencing. When I tried to learn how to do React on my own, I looked at various tutorials and things like that. And I noticed, or at least people have told me who have worked who have been working with me that some of the things that we do or kind of anti-pattern or not quite how things work now, because this code base is slightly, well mature us relative, but it’s a few years old. And so there are some ways that I guess are easier to do things than the way we’re doing them currently because this was written years ago. So it’s a little bit of a treadmill trying to keep up with current times and make sure I want to do things the best way, but also I don’t want to break an established code base because I want to play around with stuff.

Drew: Obviously, one of the things with React that people like you and I are coming to it, it can feel a bit jarring as this whole thing with JSX. Are you using JSX in your project?

Mina: We are. I am using JSX.

Drew: Have you made peace with that?

Mina: I fell like a little small piece of me dies every time I open one of those files. It still feels sacrilege to put my HTML in the JavaScript file. I know that’s kind of revolutionary and the whole point, but it just feels off to me that I’m writing my markup in a JavaScript file. I’ve made peace with it, but every time I do it, I’m just like, “…” Separation concerns, it is a thing. I’d like it back, please.

Drew: It’s a valid point, isn’t it? My background when I was starting to work more seriously with JavaScript, and this was probably when I was back at Yahoo, things were very much on the model of server rendered HTML pages and then taking a progressive enhancement approach, layering JavaScript on top to enhance the interface. And if the state of something in the interface needed to change, your code had to know about all the parts of the interface that it needed to update, which obviously leads you to a tightly coupled approach with these big monolithic views where the code you write needs to know about all the other code around it. And I guess that doesn’t really lend itself to a componentized approach which you would take when working with a pattern library or a design system, which is more to your area of particular expertise. I guess, React lends itself more to that approach, does it?

Mina: I think it does, especially with the being able to couple the very specific CSS to one JSX or one React component. And so that way it makes it much easier to separate or only take what you need for the library and leave the rest, whereas a pattern library or design system that attempts to do something more monolithic with just one big style CSS file or something like that, it does make it a lot difficult. You kind of have to take it all or nothing. So I do appreciate that React allows us to do more individualized, more componentized way of development, even if I still wish there was a way for me to do truly separate my presentation layer and my content layer from my interactivity layer. But maybe that’s just me being a little bit old school in that sense.

Drew: I definitely feel the pain there. The idea is that, come and correct me if I’m wrong, my understanding is that rather than separating the technologies, the CSS, and the JavaScript, and the HTML, it’s separating the functionality. So everything that is one component all exist together-

Mina: Yeah.

Drew: … which I guess is useful if that component then is no longer needed. You can just delete it, and it’s gone, and it doesn’t leave a footprint around your app. That’s not always the case with CSS though. How are you working with CSS with React? Have You looked at things like styled-components or anything like that?

Mina: No, we haven’t. I’ve heard of styled-components, but I’ve never quite really investigated them very fully to be perfectly honest. So the way that we’re working with CSS with React is we write Less, and we just have a Less file attached to each individual component that gets imported into that component. And then it gets bonded up via Webpack and served to the client.

Drew: Are you using a system like BEM or something to turn namespace?

Mina: Yeah. We’re using BEM for namespacing, although the adherence to it is kind of varied depending on who’s writing what. But we try to use a BEM namespacing pattern to make it a little bit clearer what the purpose of each individual class and component is.

Drew: And does that seem to be working successfully for you?

Mina: I think so. Occasionally it kind of has the same old problem of I sometimes don’t know how to name something. After a while daily things has always and will always be a difficult thing for master. So that’s the only issue I have with is I occasionally I have no idea what I should call a particular component.

Drew: Definitely. That’s a constant battle, isn’t it, how to out the name things?

Mina: Yeah.

Drew: I always end up when working on a new feature or something like that, you give a component and all the classes and everything the name that the feature has got at the moment. And then by the time you come to launch, it’s been renamed something else. So you have references to the old name in the code and the interface has the new name. And …

Mina: I try to always name things based on the function or the purpose of it versus things that are a little bit more ephemeral, because it’s less likely that the actual purpose of this component will change. I forgot to mention, but in addition to using BEM, I guess we use BEMITs if you’re familiar with that. It’s basically the ITCSS plus BEM, both of which were created by Harry Roberts. So I use Hungarian notation to denote whether or not something is a component, versus a layout object, versus like a larger pattern comprised of multiple components. And then from there we use the BEM convention to signify like the block element and all that.

Drew: And have you had to do much refactoring and deleting of components and things in your code base and had to deal with the issue of CSS getting left behind?

Mina: Yeah. So the non-React part of my job, of maintaining slack.com is that’s all just a bunch of Less files that are being compiled for CSS. And I guarantee you, there’s a lot of zombie code in there, because we definitely iterate above things a lot in the time I’ve been there. And we don’t always have time to go back and do the cleanup versus when we redesign a page or something. So it’s overdue for an audit, I’ll say that.

Drew: This is something that we’ve just been looking at in our React project, looking at how we approach CSS. At the moment, we have a few big, global CSS files for the whole of the app, and we do get this situation where our bundle size is just growing, and growing, and growing and never gets any smaller, even though things do get removed. So we’ve been looking at things like styled-components, Tailwind as well is another option that we’re really seriously considering. Have you looked at tailwind much?

Mina: I haven’t looked at it a lot. I’ve been curious about it, but again, I’ve never really had time to dig in to actually see if it’s something that I want to try to bring into our code base.

Drew: I was actually quite surprised, because like you, I’m a bit old school with how to do these things. I like nice separation of concerns. And I like to write my CSS in CSS, and of course the approach with Tailwind is you have all these class names, which feel a bit like inline styles that you’re applying. And if it feels dirty.

Mina: Yeah.

Drew: And I volunteered within the team, we each which took a technology to investigate if they’d be a good fit for our problems, and I volunteered to look at Tailwind because I was absolutely certain I was going to hate it.

Mina: No, no.

Drew: But it turns out I actually think it solves a lot of problems. I was quite impressed.

Mina: Yeah. I’ve sort of come around to a similar way of thinking, because I in the past would much prefer to have one class comprise all of the styles I needed for a particular component and not do a class per property, as I believe Tailwind does or languages like it do. For the similar reasons, it felt very much like, “Well, I’m just running inline CSS at this point. Why would I do this?” But as I’ve been developing more and more, inside of our Slack design system, I created a bunch of what I call utility classes that do things like add a bit of margin with a pattern. I’ve noticed that more and more, I’m using those classes in addition to the component classes. So I’m like, “Okay, well maybe I should revisit this whole to doing a CSS as a one declaration at a time.” I don’t know if I’d go that far, but it’s definitely worth considering.

Drew: Computing seems to flip flop in terms of trends between thin clients and fat clients solutions. We started with mainframes with terminals, and then the PC era with windows and office and all these sort of big applications. And they were all getting really slow, and than the web came along, and that was just a browser, and all the work was being done on the server. And it was all fast and snappy again. And now we’ve gone back to putting all that work back in the browser with everything being done with JavaScript, things like React and the JAMstack approach where we’re back to a sort of fat client. I sometimes worry that we’re asking too much of the browser. Is this a mistake? Are we asking too much of the browser trying to do all this stuff in React?

Mina: I want to say yes with the caveat of, again, my experience is very much contained to mostly static websites. I don’t do a lot of product development. So maybe in that realm, this makes more sense. But from my perspective, I feel like we’re a lot of the times using a hatchet when we just need a butter knife. I don’t know why we need put all this in the browser, put so much work and so much pressure on the client. I feel like we could do this much simpler. One of the things that always made me a little hesitant to use React, or I say hesitant, but what I mean when it made me viscerally angry and I actively opposed, was when I would go to a website and literally nothing would render because there was one error or something, Like, “Really? The entire page is broken because one function broke down?”

Mina: It just kind of annoyed me that a lot of times it was an all or nothing approach. One of the talks that I gave at AEA in the past and other places in the past was talking about how to include progressive enhancement and not just your development, but also of art direction and design of sites. And I would point out specifically examples of websites that didn’t do progressive enhancement or any kind of graceful degradation. It was like either you have the JavaScript running in the browser or you get absolutely nothing. And it would be like just a simple site that represent information about the history of web design, which was one of the sites actually talked about, the history of web design from like 1990 until now. It was a beautiful website with lots of timelines, animation of things. But it also could have been rendered statically with just a list. There were steps in between showing nothing and showing that beautifully enhanced experience that I think got lost because of the way we’ve been approaching modern web development now.

Drew: So would you say there are absolutely some categories of projects that suit a solution like React and some where it really shouldn’t be used and you should be using more traditional methods?

Mina: I think that if your site particularly is mostly static, it was just serving up information, I guess I don’t understand why you need a project like React to render something that doesn’t have a lot of interaction beyond just DOM manipulation. I guess I don’t see what benefit you get from that. Again, I may not be working on the appropriate projects. I may not just have seen or found that use case, but I’m having a hard time seeing if it’s just mostly static site, presenting content, not a lot interaction, not a lot of interaction beyond manipulated DOM and doing animations. I don’t see how having a React library helps you accomplish that goal.

Drew: It’s interesting because I’m not bad talking it because I haven’t actually used it, but I see a lot of Gatsby projects and Gatsby being a static site generator that uses a React front-end in it. And I see all the examples of the themes and things they have available are all content based sites, or blogs, and a recipe site, and a portfolio, and these sort of things. And there’s something I think actually that this isn’t necessarily the right fit for something like React. Why isn’t this being statically rendered and then progressively enhance?

Mina: Yeah.

Drew: It’s not software.

Mina: Yeah. I haven’t actually used Gatsby either. I’ve heard plenty of great things about it, but that’s probably one of the examples I would think of where I’m like, “Okay, I guess I’m just not seeing why that tool is necessary to do that particular job.” Again, I don’t know. Maybe it’s just because more people are comfortable writing in React when they are writing new something else, and it’s just providing a tool that meets people where they are. I’ve heard great things about static site generators that use React for people who have used them and love them, but it’s not a use case that I would have immediately been like, “Oh, that makes sense.”

Drew: It seems like there’s always been this battle between what we would call a website and what you might call a web app. And the chasm between the two seems to be getting wider, and wider, and wider, whereas a progressive enhancement approach tries to bridge the gap by taking something static and adding JavaScript and adding interactivity. It seems that things like React are ideally suited for software that you’re running in the browser. Would you agree with that?

Mina: I would definitely agree with that because it feels like it’s was built for that type of environment; it was built for running software. It was built by Facebook for Facebook. So it was built for a product. It was built for running whatever you call a web app in the browser and not necessarily for the type of work that, as I mentioned, I’m used to doing. So I think in those scenarios, it definitely makes a lot of sense to use it if you’re building a more complex, more sophisticated piece of software that’s meant to run inside of a browser. But if you’re building a marketing site or whatever, I guess I would still struggle to see why it will be necessary there.

Drew: So are we giving people permission to still build decent, statically rendered websites?

Mina: I would love to see more of that happen. I feel like that’s kind of gotten lost and it’s sort of lost its, if it ever was cool or whatever. I feel like we’ve lost that part of web development. It’s so funny: you and I both said that we’re kind of old school, and I laugh at that because I’ve actually been doing web development for, what, six years now? How am I old school? It hasn’t been that long for me. And yet somehow I’m part of the old guard who doesn’t like new and shiny things. I don’t get it.

Drew: So in fact React has actually existed for the whole time that you’ve been a web developer.

Mina: Maybe I just have an old soul. I don’t know.

Drew: I think that’s probably the case. I’ve not looked personally at, there are service side rendered approaches you can take with React apps. Have you experienced any of those?

Mina: I haven’t experienced any them. I briefly looked into them for the project I’m currently working on, because I feel like there’s parts of the operation that would work better on a server versus in the clients. But I think because of my limited knowledge and the fact that the code base is a little more complicated than I can understand, I wasn’t quite able to figure out how to make that part work. I would love to figure it out eventually, but I spent a day digging into it. I was like, “You know what? I’m not grokking this away I need to be. So I’m just going to back up and take a different route.”

Drew: Yeah. I think we’ve all been there.

Mina: Yeah. I went down a path. I was like, “Oh, this is dark and scary. Let’s reverse. Let’s reverse.”

Drew: Step away from the code.

Mina: Yes.

Drew: So you’ve been very diplomatic and polite about React so far. I sense that there’s some tension bubbling under the surface a bit. Come on. Tell us what you really feel.

Mina: I have been polite and diplomatic, mostly because the Reacts fan base can be a little mean sometimes, and I would rather not have them come for me. So please, React is great. It’s wonderful. Use it for what you want to use it for. I kid, but even that tweet that you mentioned at the beginning of this podcast where I think what you said is that I don’t hate it. I don’t love it, but I don’t hate it. Even that statement, I got people, there was no vitriol, but it was more they where ready to leap to the defense and say, “Well, I love it because X, Y, Z.” I’m like, “I didn’t say it was bad. I just said that I’m meh about the whole thing.” But apparently being meh is not okay. I have to love it.

Mina: So that’s why I probably have been a bit more diplomatic than I would ordinarily be, just because I don’t want people to think that I’m bad mouthing it, because I’m not. It has a place in more web development. It serves a function. It does its job well. People love it. It’s just not a tool that I’ve ever had or wanted to use until now.

Drew: Yeah. Things can get very tribal, can’t they, with people feeling like they have to take one side or another, and you’re either absolutely for something or absolutely against something? And I’m not sure it serves a good purpose, and I don’t think it really moves us forward as an industry and as a community to do that.

Mina: Yeah. It’s really odd. It’s fascinating to watch from just a sociological standpoint, but it’s often just really like weird to observe. It’s like I’m not allowed to just be, like I said, neutral about certain things. I have to have a strong opinion, which is I don’t think healthy. What’s the term, “Strong opinions, loosely held?” That’s kind of the way I go about things. I feel strongly about certain things, but it’s not like you can’t change my mind. Where I feel like some people, their identity gets wrapped up into certain aspects of it ,that if you are not for whatever they’ve chosen to identify with, it’s a personal slight versus just, I don’t care about this particular topic, or tool, or whatever.

Drew: Yes. I don’t know if it’s made worse by the fact that we all are sort of tending to specialize a lot more in particular parts of the stack. And I know there are people who are React developers. They would call themselves a React developer because that’s what they work in. And they wouldn’t necessarily write any vanilla Java script or wouldn’t use Vue or whatever. React is their world. So I guess it almost feels like an attack on their entire career to say, “I don’t like React.” Well, they’re really invested in making you like React or whatever the technology may be.

Mina: I will admit to being one of those people in the past. Actually, probably it was mostly about SASS, I believe. I was very much on the team of doing SASS as a preprocessor and all other preprocessors are trash. I don’t want to talk about them. I don’t want to deal with them. And I realized that was a very narrow way to look at things. Use the appropriate tool for the job. Whatever makes you more productive, that’s the right tool. It doesn’t really matter what it is.

Drew: Are there any technologies that we work with that don’t have that sort of tribal feel? Is there anything that people are just happy to use or not use? I can’t think of anything.

Mina: Wow. No one has opinions about markup, actually.

Drew: No.

Mina: I feel like no one has opinions about like actual HTML and just markup, just like, “It’s there.” They use it. But people have strong opinions about CSS and how it’s either terrible or wonderful, and the preprocessor wars that don’t really happen all that much anymore, and then of course, all of the tribalism within the various JavaScript libraries.

Drew: So you would say your journey so far with React is still just, “It’s a tool. It does its job?”

Mina: It went from a curiosity to active and visceral dislike because of how prevalent it was and how I unnecessary I thought that that prevalence was to meh. I’m now with meh, which again does not mean I hate it. It just means …

Drew: I think that’s a good place to be. I think we’re probably all sort of stronger as technologists if we understand the value of a particular technology for its purpose. We can evaluate what is good for what circumstance and pick the right tool for the job.

Mina: Yeah. And that’s kind of where I’ve arrived at this point in my career where I don’t get really invested in any particular language, or technology, or whatever, because it’s like, “Just whatever tool is most appropriate for what you’re trying to do, then use that.” I’ve learned that there’s a place for everything; there’s a time and a place to do everything. And up until recently, there was no real time or place for me to use this React librarian, and now there is.

Drew: I think that’s a good place to be. So I’ve been learning all about React lately as you have in the day job. Is there anything else that you’ve been learning about lately?

Mina: I’ve actually learned ironically, which is I think another language that has originated at Facebook, I’ve been doing a lot of Hack development, mostly because that’s what I use at Slack, at my day job. Learning Hack paved the way for me to get more comfortable using React because they follow very similar patterns, except one is server side and one’s not. So that, along with just in general, I’ve been learning more about the back-end and how that works for various different reasons. And I’ve been stretching myself for the past couple years and getting more and more outside of my comfortable zone. Design systems, libraries, that’s very much my world, and I feel very good and comfortable in that world. But I’m stepping outside of it and doing a lot more server side logic, and API development, and data modeling, and all of that. I’ve been doing a lot on that for the past year as well.

Drew: I find that the more I understand about the whole stack about back-end stuff in front-end stuff, each one helps my knowledge of the other. I find I write better front-end code by having written back-end code and understanding-

Mina: Yeah. I think I feel the same way. Now that I have a better idea of, like we said, the whole stack of how we get from the data to the end client. I find that I’m thinking about the entire pipeline no matter what part I’m actually working in. I’m thinking about what’s the best way to structure this API so that when I get to the template, I don’t have to do so much manipulating of the data that I receive on that end of it. It’s definitely made me overall a better engineer, I feel like it

Drew: If you, dear listener, would like to hear more from Mina, you can follow her on Twitter where she’s @MinaMarkham and find her personal site at mina.codes. Thanks for joining us today, Mina. Do you have any parting words?

Mina: Have a smashing night?

Drew: Great.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
angela-byron-200x200-1
02 Jun

Smashing Podcast Episode 17 With Angie Byron: What’s New In Drupal 9?

by TBSCategories: News

Smashing Podcast Episode 17 With Angie Byron: What’s New In Drupal 9?

Smashing Podcast Episode 17 With Angie Byron: What’s New In Drupal 9?

Drew McLellan

Photo of Angie ByronIn this episode of the Smashing Podcast, we’re taking a look at what’s new in Drupal 9. What are the major upcoming changes to this nearly 20-year-old open-source project? Drew McLellan talks to Drupal core committer Angie Byron to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is Senior Director of Product and Community Development at Acquia, a company you’ll know from their software and services built around the Drupal ecosystem. She’s been a Drupal core maintainer for nearly 12 years, as well as being an author for O’Reilly and an open-source evangelist who just lives and breathes Drupal. Joining us from near Vancouver, British Columbia. She’s passionate about getting new people, especially women into open source. We know she’s a longstanding Drupal expert, but did you know she once taught a dolphin to make marmalade? My smashing friends, please welcome Angie Byron.

Drew: Hi Angie. How are you?

Angie Byron: I’m smashing, Drew. How are you?

Drew: I’m very good. Thank you. I wanted to talk to you today about something we’ve certainly not covered on the podcast before. And I’ve rarely actually touched on Smashing Magazine articles over the years, despite it being a hugely popular open-source project with a massive community. And that of course is Drupal. Now, I’ve deliberately not described what Drupal is in my introduction because I feel like there could be a whole generation of web designers and developers who’ve never really come across it. And there are those who might think, that we know what Drupal is all about, but that could be based off of a view formed 10, 15, 20 years ago almost. What is Drupal as it stands today?

Angie: We call Drupal a content management framework. And what that means is it’s a generalized framework that you can use to make websites, you can use it to make mobile apps, you can use it to make just about anything you can imagine. But it’s very content structured, content based central system. It’s used to power one in 35 websites in the world. It’s out there and people use it. It’s been used a lot for government websites, media websites, just about everything that you can imagine. It’s even been used to power say, the princess cruise ship schedules and things like that. It’s used in a lot of different capacities.

Drew: How does it differ from other content management systems that people might have used in the past, such as WordPress or static publishing tools like Hugo and Jekyll?

Angie: I like to say that if you know what you want is a blog or another thing that WordPress is really good at, WordPress is a great choice. Similarly, if you know that you need some highly customized software that can only work with one particular backend system or things like that, a custom CMF framework like Symfony or something might be a better choice. Drupal is great because it spans both. It has a user interface, so you can create content just by clicking and filling out forms. And you can extend it with its API, but it’s built to actually allow you to do a tremendously amount of powerful stuff just by being in your browser, clicking around forms and buttons.

Angie: I use it a lot because I often have customers who don’t really know what they want. And so, they think that they want to blog and then it turns out that, “Oh, but we also want an ecommerce component with this blog. Oh, and we also need like a forum with five star ratings and reviews and these kinds of things.” And with Drupal, that’s just a check boxes to start adding new functionality like that versus with WordPress, it might mean, putting a couple of different solutions together that you then have to integrate. And with custom code, that’s obviously custom codes what’s going to be a lot of work for you.

Angie: Drupal has a whole library of contributed modules. There are something like 10,000 to 12,000 of these add-on modules that can do additional features. And then out of the box, especially if you haven’t used Drupal in 20 years, Drupal is actually a really full featured CMS these days as well, where it shifts with media layout support, all kinds of different things.

Drew: You briefly mentioned some projects before that are using Drupal. What is the ideal project where somebody would reach for it over something else? Where does Drupal really excel?

Angie: I would say that Drupal is great if you have, let’s say a website or a web presence where there’s a lot of different sub-components and you all want them to maintain a consistent look and feel. Universities use it a lot, for example, because they want to have the consistent university branding across all of the different sub sites. However, they also want to give individual departments freedom to set up their own, say content types. So, say the art department might want to track artists and musicians and things like that. And tying those to works that they’ve produced versus the IT department might want to be contracting like these are the different people we do IT internships for, and these are the different people that work for them.

Angie: And Drupal allows you to model all of that content together and create a dynamic views of it and forms that you can just click together out of the box.

Drew: One of the reasons I wanted to chat to you about Drupal at this point in time is that there’s a major release around the corner. Isn’t there?

Angie: There is. Next, well, I don’t know when this will go out, but it’s June 3rd. So, currently a week from today.

Drew: And that’s Drupal 9.

Angie: That’s correct.

Drew: Now, a big new version of a mature software product always brings with it, big new features. Doesn’t it? What are the headline changes that someone would really notice about Drupal 9?

Angie: If you’re using Drupal 8 currently, the big news for you is that Drupal 9 is really not much has changed. And that’s a big deal for our community because in the past, when you want to move from say six to seven or seven to eight, it was a, I wouldn’t call it a harrowing process, but you could call it something like that where we used to have a philosophy that we’re going to break your code and not your data. We would always be on the cutting edge of the latest things and any major version upgrade would come with it. The needs, support modules and the underlying code with Drupal, and you’d always get the latest, greatest stuff, but it would come at an expensive, costly upgrade process.

Angie: From Drupal 8 to nine, what we’ve been doing is building Drupal 9 in Drupal 8 effectively. And so, Drupal 8, the whole way along has gotten the new APIs, the new features, all these kinds of things in a backwards compatible way. What Drupal 9 is going to do is cut out the backwards compatible stuff and put us all on the latest version of say, Symfony, PHP, MySQL all the newest stuff there so that we have security support for those things for the next three to five years to come. From eight to nine, not much, if you last looked at Drupal though from say Drupal 7, a tremendous amount has changed, because you not only get the innovations that have into Drupal 8, things like mobile experience, out of the box configuration, management, the views module, which allows you to dynamically assemble lists of things available out of the box.

Angie: But you also get the features that have come within the Drupal 8 cycles. Those are things like a media library, workflow management, layout building capabilities, better automated testing and all kinds of other things.

Drew: One aspect I am particularly interested in because there’s something that’s either lacking or patched on messily to many content management systems, is this concept of structured data. What do we mean when we say structured content? And what does Drupal 9 bring us in that regard?

Angie: Structured content is a really fascinating concept and it’s been built into Drupal from the early days. In a CMS like WordPress or Squarespace, something like that, you would say, I want to download the photo gallery feature and I’m going to enable the photo gallery feature, I’m going to get the photo gallery as the person who created it, envisioned it. In Drupal, you go at it a different way. What you do is you create your photo gallery feature from base components. And what I mean by that is you will create a content type called photo. You will add an image field to it for the picture. You will add maybe a caption field, you’ll maybe have attributes to the image and all these other tenets, number fields for the attributes, or sorry for the heightened width text fields for the old attributes, there’s many different kinds of things you can do.

Angie: And then you’ll create a view of photos and you can choose if that photo view is, say it lays everything out in a six by nine grid, or maybe it does it in two columns or whatever, and you can have full customizability over how, and in what way it’s produced. Structured content is interesting because not only can you make your website look like how you want it, but because the content is structured in a generic way through entities and fields, you can also say, for example, create a decoupled react application that talks to Drupal as a backend.

Angie: And have full control over how that’s done, and then take the same backend, make it your website, the same backend make it say a kiosk in the mall where people can select different items. A lot of people make use of Drupal as this general content store that can then be talked to by anything. And the way we can do that is because all the data that the CMS manages is abstracted. It’s not built into the presentation layer. If you use a Wiziwig editor to answer in your content, you’re going to get the images embedded in the body field, and that’s never any good if you want to then take part that body field and display it in a sidebar block.

Angie: Drupal by structuring everything into discrete fields and entities on the backend, makes it so the concept can be mixed and matched really easy.

Drew: That means you could use a Drupal as a headless CMS essentially?

Angie: Yeah.

Drew: That’s pretty much what you’re describing there, isn’t it?

Angie: Yes, absolutely.

Drew: If you’re working in the Jamstack say, or you’ve got a single page app, or you’re building mobile apps or have other less conventional ways of consuming content, you could use Drupal as a content management system just to literally manage the content and then to expose it to those other things via an API or something like JSON.

Angie: Exactly. Yep. JSON:API support is built in and this comes with its… everything about Drupal is modular. If you don’t want the theme layer, you don’t need to have it. Theme layer is what we call like the HTML presentation layer that’s generally generated by PHP. But you can throw that out and say, “I just want JSON:API output of all of my content.” You also get certain features that are built into Drupal built into your app. For example, Drupal has a really robust users, permissions and roles system. You can set up different roles with discrete permissions to do different things on the site or see different pages on the site even.

Angie: And those things will be respected by Drupal and will be enforced by Drupal so that by the time someone actually loads the application at a certain URL, you know that the person who is there is meant to have access to it. It’s really interesting. It’s a cool product to work on because, on the one end, it’s a product made by developers for developers. We started building it because we wanted an easier way to… We didn’t want to have to get called by somebody to change the copyright field at the bottom of the page every year or whatever.

Angie: We just make a box so that they can fill it out. But it’s also a tool made for a carving out a whole new area of people, which is like site builders. They’re like technical, but not necessarily know how to write all the backend code, but they know for example, how to click together these different concepts in order to make these really powerful sites. And so, at any point, when you’re developing a feature such as a media library, you have to not only think about how do we make this really easy to use for a marketer or a content author persona, who’s going to use it every day, but also how do we make it infinitely extensible from the developer side, how do we make sure we have automated tests that cover everything?

Angie: How do we make sure that the output is accessible so it can be translated by screen readers? And all these kinds of considerations. So, Drupal’s really interesting and kind of stands out in its field in that a lot of times you have to pick between a really easy to use front end that doesn’t have decoupled content or a very technical decoupled content thing that you need a fleet of JavaScript developers to work on. And Drupal sits in a middle and a sweet spot where it can be both.

Drew: Because Drupal is essentially traditionally a themed CMS, isn’t it? If you’re looking to build a site, a more traditional site where you’re using a theme to output HTML pages, CSS, a nice responsive web design is going serve your mobile devices, desktop devices, and so on. What templating capabilities would you be looking at in Drupal? What have you got available to use?

Angie: Drupal uses a Symfony library called Twig, and it’s effectively HTML templates with little special characters to do branching, basic branching logic, print variables, that kind of thing. That’s a default output that Drupal does. You have a callback that generates the output and that’s stored into an array. The array is passed to whichever output layer. It could be JSON:API, as I mentioned before, and just put big drop of JSON, or it could be passed to the theme layer, which will then translate those arrays into, this is the header, this is that and it’ll print it into the CSS and HTML variables like that. I don’t know if that answered your question though. Sorry.

Drew: No, you did.

Angie: Okay, great.

Drew: I think last time I used Drupal, it was using maybe Smarty. Is that right?

Angie: Oh, Smarty, yeah. Well, that’s like Drupal 6 days.

Drew: Yeah, it’s Drupal 6 or Drupal 5 even.

Angie: Yeah. Oh, that’s fantastic. Twig is a similar concept to Smarty, but the nice thing about Twig is it better enforces the separation between your business logic and your presentation logic. Twig is not really, you can do it, but it’s not set up as a best practice for you to sit there and start putting a whole bunch of functions and objects and classes and all that stuff in your actual HTML files. Your HTML files, more or less stay HTML files with just the little special placeholders in them. And then your business logical happens behind the scenes in a module or in a pre-process function or something like that.

Drew: That separation actually makes things a little bit more straightforward and safer for developers who aren’t so used to working in the backend world maybe be even more comfortable with doing front end development, but a lot of the hard logic is separated from the HTML and CSS?

Angie: That’s right. And the other thing that you get as a benefit out of that is Twig is really good about auto XSS vulnerability escaping. A common thing that can happen when you’re writing your own theme from scratch is you start printing variables directly. And then someone creates a username like ‘Little Bobby Tables or whatever, that kind of thing and messes your whole site up. Twig is great because it has auto escaping of variables like that. As long as you’re sticking to the APIs and you’re using them directly, you won’t accidentally introduce either a JavaScript or SQL vulnerability in your site just by trying to make your theme look nice.

Drew: And in terms of the content authoring experience, I know a lot of people in the web design industry have seen some of their business go away, particularly at the lower end to these extremely user friendly services, things like Squarespace. How does Drupal compete with that authoring experience that people get from these very polished and sleek services?

Angie: I will say we’ve come a long way. We’re definitely not at a Squarespace level. I’ll just say that flat out. Squarespace has the advantage where they are not building structured content in that round or they’re building pages. And so, the pages are self contained and they can have full control over the HTML in there and use nice front end tools to get at them. Drupal by nature being structured content, I mentioned the benefits are that the content could be mixed and matched. It’s easy to output the content of variety of different fashions. But the disadvantage is that, our front end tools are not, they respect that structured content nature. So, you don’t see like a take over the page in place editing experience with Drupal as it stands.

Angie: However, I will say that there’s a bunch of people doing a lot of work. And so, core itself shifts with in place editing, which is the ability to click on a field and edit it right in place without having to go to the backend. There’s also the settings tray, which if you want to make a quick configuration change to say the site name or the location of a block or something like that, that’s built in there. The layout builder has some drag and drop capabilities in there as well. We’ve really made a concerted effort to improve the content authoring experience in Drupal. We did user testing back in, we started in 2008, Drupal is an old project that you mentioned it’s been around awhile, but we started in 2008 and 2012, 2015.

Angie: We keep doing these every few years, we sit down and the University of Minnesota has helped us with this. We sit down and we go to a real life usability lab with one way glass and eye tracking the whole thing. And through that process really saw that while the backend of Drupal is amazing and people love it because it’s flexible, it’s well documented, it’s architected amazingly, all these kinds of things. People really did struggle with the front end. I made it my personal mission. I know that Dree has made it his personal mission, the project lead, as well as the community as a whole to really bring that quality of Drupal to the front end as well.

Angie: And so, we’ve added a whole bunch of capabilities since then, like a backend admin theme. Some of these content author friendly features like workflows, media, that kind of stuff, and putting it first and foremost in people’s hands so that they don’t have to hand write HTML tags or this kind of thing, which was like the case many years ago.

Drew: One of the things that often attracts developers to simple publishing systems rather than the full stack CMSs is this concept of having everything managed in a gate repo. So, the changes to a life site can be atomically deployed and that gate repo is a single source of truth for the project. You don’t have multiple copies of a database representing different versions of a system gets around this issue of developing a new site feature in one environment, and then trying to figure out how to build that up and deploy it to the live environment, which goals may have changed since they started working on the feature. Does Drupal offer any way to manage that particularly difficult process?

Angie: Yes, starting with Drupal 7, in fact, we had a concept called the features module and what features were, where the ability to combine both module functionality as well as configuration changes and deploy those as one chunk of logical code between environments. In Drupal 8 and nine, we’ve improved upon that ability by building it right into the core system. There’s something called the configuration management system. And what it does is every bit of configuration that you do. For example, what is my site name called, what’s the email template that I’m making, these kinds of things. All get stored into a centralized system and that system has everything else and Drupal is infinitely flexible.

Angie: It can be exported as YAML files, for example, that can just be migrated back and forth between environments. And then it’s really easy to also do a get, diff and find out, “Oh, okay. There’s been changes between the last time that I saw that and I can look them over and make sure they look okay, great import them in.” And there’s both gooey tools for doing that as well as command line tools for doing that because again, Drupal’s always trying to serve both of those audiences.

Drew: There’s always this great opportunity when you make a new major version of a mature software project to deprecate and remove pieces that have had their day maybe features that never caught on in the way that you hope they would and to resolve tech debt and that sort of thing. What changes have been made in Drupal 9 in terms of cleaning house?

Angie: Yeah, we did take the major version bump as an opportunity to really clean house. What we’ve been doing throughout the Drupal 8 cycle is envisioning new ways of doing things. Better, clearer APIs, for example, managing entities or configuration or that kind of thing, or like a more modern JavaScript library for handling drag and drop or that kind of stuff. And during Drupal 8, what we did is we left all the old stuff in place because we didn’t want to break anyone’s site between 2015 and today. But Drupal 9 gave us the opportunity to say, “Okay, as we went along the way, we just marked all these things as like at deprecated.”

Angie: And so, we could find them later and be like, “That’s the stuff we need to clean up.” And so, Drupal 9 went through wholesale and got rid of all of the deprecated functionality. And then there’s a Drupal 8.9 version that’s coming out at the same time as Drupal 9, which has all the BC layers in there, but it’s fully compatible with Drupal 9 to give people a release to move everything up to where it needs to be. But yeah, among the things we did was we updated to the latest versions of all of our dependencies. We have a bunch of JavaScript dependency, some PHP dependencies.

Angie: Those are all on the latest sort of LTS releases. So, we stay on that for a long time. We also took the opportunity to raise the system requirements, which I know people are like, “Oh my God, why my Eskimo 5.7.” But the advantage is that a lot of these older versions of PHP, particularly at PHP 5, there has still hanging around, haven’t been security supported in ages. And so, we’re trying to make sure that our users that are on Drupal 9 are staying secure, not only today, but going forward into the future. We’ve updated those and then we’ve gotten rid of any deprecated APIs that we’ve created along the way. When you start a site with Drupal 9, you’re starting with a fresh slate, no deprecated code on the latest stuff and should serve you for many years to come.

Drew: That sounds like quite a complex development workflow. The fact that you’ve been working on a Drupal 9 compatible version of Drupal 8 and working on Drupal 9 at the same time, getting them ready to release together. How did that work in practice?

Angie: Yeah, it’s worked well because we effectively write Drupal 9 in Drupal 8 over the past five years, starting at Drupal 8, we use a concept called semantic versioning. In the past, when we released Drupal 7, for example, we just left it alone more or less, except for a few bug fixes and maybe keeping it up-to date with the latest versions of PHP that come out and that sort of thing. With Drupal 8, we made the shift to semantic versioning. And what that means is that every six months, we have what’s called a minor release of Drupal and that’d be like an 8.1 and 8.2, as opposed to an 8.1.6 or something, which would just be a bug fix release.

Angie: And every time we do one of these minor releases, we have the opportunity to add new APIs, to add new features and to change the way that Drupal works with the caveat that we always need to leave a backwards compatibility shim in there so that existing sites don’t stop working. All the way along, we’ve been improving Drupal 8 since its initial release. And so, we’ve added features, we’ve deprecated APIs, that kind of thing. So, when we get to Drupal 9, it was a lot of work. I don’t want to mitigate the word there or deprecate that word that the team has been doing because there’s like this whole burn-down chart of all the deprecated things that we needed to get through and all of these contributed modules that needed to update their stuff too.

Angie: But the effort was much lower than prepping for any other major release, because it really was just honing in on those deprecated things, the libraries that are no longer supported that we need to find alternatives for and making sure we’re on the latest versions of stuff and all this stuff works with it. And so, that’s the Delta between 8.9 and nine will be, I think it’s something like 12% reduction in code or something like that is what we managed to do, but otherwise they’re identical because they’re all using the same stuff.

Drew: Wow. It’s just like Drupal 8, but the shackles have come off.

Angie: Yes. That’s a great… I’m going to quote you on that. That’s great, I love it. Have you thought about joining our marketing team? No, I’m just kidding.

Drew: Historically, and Drupal is certainly not alone in this, but there has historically been quite a lot of pain in moving sites from old major versions to newer major versions of Drupal. It sounds like maybe with process of developing a Drupal 9 inside Drupal 8, maybe that has been resolved slightly. So, should moving from Drupal 8 to Drupal 9, actually be fairly straightforward?

Angie: That’s right. Yeah. I think there’s basically three scenarios, so one is if you were running Drupal 8 and every time a new minor release of Drupal 8 came out, you upgraded it to a right away and you started making use of the new stuff. Your path is going to be basically nothing like you’ve already been doing all the work and you’re fine. If you moved to Drupal 8 awhile back and you haven’t been keeping up with the BC changes, there is a little bit of work for you. It’s definitely the easiest upgrade in over a decade of our software anyway. And we have a ton of different tools to help you with it. There’s a dashboard that shows all of the contributed modules and what their Drupal 9 situation is, there’s automated tools for going through and checking your code and flagging any deprecated functions that you have.

Angie: And there’s tools for automatically, going up and finding, “Oh, this is the latest version of your module and it’s Drupal 9 ready? You should go download it,” that kind of stuff. From Drupal 8 to 9, I would say that that part’s pretty well covered. If you’re coming from a prior version of Drupal, say Drupal 7 or below to Drupal 9, that does start to look a little bit trickier, like among the changes that we made in Drupal 8, where for example, we moved entirely to object-oriented PHP and we started utilizing design patterns that were found in other software project, which is a really smart thing to do architecturally, but it does mean that if you had a ton of custom code in your old life, that in Drupal 9, you’re going to need to find alternatives for that.

Angie: Acquia is a product and development called Acquia migration accelerator which is aiming to solve that problem where we’re creating like a nice, react to find application, which reads in your old Drupal 7 data creates equivalent Drupal 8 data for you along with all the modules that you’re going to need that mapped to your old Drupal 7 modules where possible to try and expedite that process quite a bit because we want to make sure that everybody who’s on older versions can still make it over to the new world order where everyone’s on the same version and we’re all working together.

Angie: And then in addition, we’ve also extended the Drupal 7… The community like the opensource community of Drupal their end of life in Drupal 7 as of November of next year. Currently, anyway, we need to discuss whether COVID impacts that or not. But there’s a number of different companies and Acquia is one of them that offers extended support for Drupal 7 beyond that, to 2024 at least. And so, that makes it so that people who have an easy upgrade have a year and a half to get it done. People have a less easy upgrade, have potentially like three and a half years to get it done or longer if they need to. And we’re trying really hard to make it possible for everybody to move over and then building tools like Acquia migrate accelerator to help speed up the process.

Drew: I’m intrigued by the sound of this functionality to scan your code and find out if it’s going to be Drupal 9 compatible. Is that essentially a static analysis tool?

Angie: It is. Static analysis has its limitations. We’ve built a little bit… It’s a library called Rector PHP and you can use on any generic PHP code. It’s not specific to Drupal, but we’ve built a wrapper around it called Drupal Rector, which my understanding is that it adds a little bit of extra things where… There’s certain stuff that we know when something’s dynamically loaded up in the argument that it’s looking for might not be present at that wouldn’t be necessarily addressable, when it’s just in static codings reading dollar signs and stuff like that. And so, there’s been a little bit of extra wrappers to look for some of the most common issues that we find there. And the other cool thing I’m sorry, I got those two confused.

Angie: PHP scan is the thing that scans the code. Rector is the thing that can automatically apply changes to code. And so, we’ve been using those in tandem. PHP standard do the static analysis, plus a wrapper for some Drupal specific things to catch some of the dynamically loaded problems. And then rector is a thing that’s used to say, used to be Drupal_set_message of procedural function. And now it’s this arrow Drupal message or whatever it is and it automatically can make those changes for you so that you’re really only honing in on a couple of tricky your API bits that can’t be automated for you, but we have a dashboard on dev.acquia.com that goes through all of the contributed modules.

Angie: And I’m going to get the numbers wrong, but it was something like 50% of projects are either done already for Drupal 9, or they just need like one or two line changes that can be done with this automated tool. And then there’ll be good to go. The two of those tools together in tandem have been excellent. What I’d like to see is when we make API changes going forward in Drupal 9.1 and 9.2. and so on that we actually couple them with a rector room that will automatically fix them in modules going forward, because then we can cut this transition period down even further in future releases.

Drew: That sounds really smart. Is this something that users with Drupal 8 sites currently can start using in preparation for Drupal 9?

Angie: Yep, absolutely. We’ve been recommending people start doing this since beta, which was a couple of months ago. Yeah, there’s a couple of I don’t know if it’s the best to send you links or something like that, but there’s a project on drupal.org called upgrade status and that’s a nice jumping off point. That’s the thing that gets you the dashboard overview, it looks at all your modules tells you a red, yellow, green, whether or not it’s ready for Drupal 9 and can point you off to the tools that either can help upgrade your site for you or help you upgrade your own code in cases where you’ve extended Drupal beyond its normal capabilities.

Drew: So, say somebody listening to this has got a WordPress site, which they’ve built over the years. They’ve got maybe multiple themes and child themes, dozens of add-ons, it’s draining, it’s bursting at the seams, it’s beginning to sweat and they’re looking at Drupal, they’re thinking, “I like the sound of this. This sounds like it’s built for more of the project that I’ve got here.” What would the process of moving a site on something like WordPress over to Drupal look like?

Angie: One of the features of Drupal 8 is the migrate API, which is something we’re making use of an Acquia migrate accelerator as well. And the migrate API is generic. It doesn’t care what you’re moving to or from, we happen to use it to move from Drupal 7 to Drupal 9, but you could also use it to move from WordPress to Drupal or from Drupal to WordPress for that matter. Please don’t but you could. There are a bunch of plugins for the migrate system and one of them does add WordPress specific knowledge to the migrate system. And so, it sets up WordPress as a source, Drupal as a destination, and it moves things over there. That worked for the data of your site, the actual functionality of your site, you’d have to do some research to figure out if you say I was using this plugin and WordPress that maps to this module in Drupal.

Angie: One future plan we have for Acquia migrate accelerator actually is, once we got the seven to nine problem leaked to try and open it up so we can move people from anything to Drupal because it’s the same basic problem where you’re doing a major upgrade from an external system to another external system. There’s no reason we couldn’t theoretically throw in WordPress, Adobe experience manager, Sycor those kinds of things into this as well and work on migration tools for those because yeah, the more on the Drupal boat, the merrier.

Drew: Drupal has been a project for nearly 20 years at this point, it’s obviously got a healthy ecosystem loads of committers, loads of support. It’s got companies built around it. But obviously a project this big has to keep evolving and keep bringing in new blood. Are there any initiatives to bring new developers into the Drupal family?

Angie: There is. There’s a couple of those. I would say the one that I’m the most excited about that is very ambitious and so we didn’t get it done in Drupal 8, but we’re calling it, the admin UI initiative would be probably need to split that up into several smaller initiatives, but effectively it’s an initiative to modernize the JavaScript of Drupal. And that means a number of different things. Number one, we’re using jQuery because that was the hottest thing back in 2006 or whenever we made that decision. And moving it more to like generic ES 6 or I don’t even know, I’m sorry, I’m not a JavaScript person, so I don’t know what there is to list there, but whatever the latest ECMAScript is, we’d be using that.

Angie: But it also means, drilling down… Drupal 8 in particular already went a long way to making Drupal really accessible for decoupled builds. Having a JSON:API output, there’s a distribution called Contenta that is get you up and running on a Drupal site, catered to headless, if that’s what you want. There’s a bunch of stuff in that area, but I would love to do even more. Knowing that that is more or less a best practice now, it’s like, sort of build this decoupled front end to a backend and really honed Drupal for that purpose.

Angie: I think that’s part of the JavaScript modernization. And then the other part is a lot of our admin experience tools are still in that PHP client server model, or like a person who clicks a button, there’s a request to the server or something churns, and then you get output. I would love to bring in more of the dynamic instant feedback, that react view angular, some of those libraries make possible. I would love to get some of that in the actual admin interface, both just so the code interface looks nice, but also because if we could develop a set of components, say react components or something like that.

Angie: All of the Drupal modules that plug into Drupal could also make use of those. And it wouldn’t be like reinventing the wheel every time. I think that’s going to be a major focus for Drupal 9 is modernizing the JavaScript and the whole overall developer experience of Drupal for JavaScript developers. And then in addition to that, we’re also trying to minimize the amount of work that people who are developers and already know Drupal have to do through the automatic updates initiative is another big one that I’m excited about where right now, if you want to update your modules, that’s pretty straightforward, but updating core requires some manual work.

Angie: And we would like to get rid of that so that everybody can stay on the most secure version and that kind of thing. If it hasn’t come across, Drupal’s very concerned about security. We run some major governments in the world. We are running the Grammy’s or whatever. A lot of people depend on Drupal for being rock solid. And so, we spend a lot of time being very concerned about the security of the software, making sure the security team is responsive, not only to core issues, but anything that happens in our contributed module space. We take a lot of care about accessibility. We make sure that any change that goes into core goes through a series of gates and make sure that it’s WK compatible and uses the correct Aria attributes and all that kind of stuff.

Angie: We really have spent a lot of time making sure that things are good. And now I think the next phase of things where he’s going to be opening up all of that effort that we’ve put in to make it more accessible to more people.

Drew: It sounds like Drupal takes longterm support very seriously.

Angie: That’s correct.

Drew: How do you balance having a modern code base, you mentioned updating the style of JavaScript using having something that’s attractive to developers yet still having something that’s stable and isn’t following fads, isn’t bringing in dependencies that are going to quickly go away, that you can rely on and it’s going to be a bit boring and keep running and be supportable?

Angie: That is a fair question. I think a couple of different ways. As I mentioned, Drupal is very modular. One thing that has led to success in the past, so JSON:API is a good example. There was a lot of contention about what format are we going to standardize on for Drupal itself to output. And we settled on JSON:API for a number of reasons. It’s an open protocol. It’s not backed by one particular company, blah, blah, blah. There’s a bunch of stuff. When we did that, we actually prototyped that in contrib first. We created a contributed module, which can iterate very fast and easily.

Angie: And we can even just say, “Oh, that didn’t work out, delete it.” We were able to innovate really fast out in sort of this contributed module space. We started there and saw that, “Hey, this thing has some legs. Like people are actually making use of it. They’re providing really great developer feedback. We’ve got Drupal people on the JSON:API spec writing team, like this is actually really good. Let’s bring that thing that we already know works into core.” And then we did so, but it’s still just a module. Let’s say that, next year XMLRPC comes back from the dead and that becomes the thing that everybody uses.

Angie: It’s still possible that we would just leave the JSON:API module in there. We would get a new XMLRPC module. We would enable that by default, but still leave the old thing in there. And then when Drupal 10 came out, we’d take the old JSON:API module, move it back to contrib and people could still use it. But what shifts in the core software itself would just be following the latest trends. This way we get the best of all worlds because we’re able to innovate quickly. We’re able to make the best decisions possible for what the default Drupal user experience will be and developer experience. But then we’re also able to backtrack on decisions if necessary to do different things instead.

Angie: I think what would be get really tricky would be like, if we wanted to throw out the entire theme system and replace it with angular, for example, that would be hard. It’s really hard to make… All of the modules have to write four different ways that they could do their templates and that kind of stuff. That one, we would need to think through more, but that general approach of figuring out a way to plug into the system, leaving the old way in there as a crutch for the people who still need it. And then when we retire things, we retire them gracefully, so they’re still available to people, but just not part of the core product, I think that’s generally how this goes.

Drew: And I guess it’s that continuing process that’s brought you to this point where you’ve got Drupal 8 with all the backwards compatibility, I’ll call it baggage, baggage that you’re now shedding and moving forward with Drupal 9.

Angie: That’s right. Yep. And we’ll do it again in Drupal 10.

Drew: It sounds like a very important release for Drupal. Is there anything else we should know about it? And when is it landing?

Angie: It lands on June 3rd. You heard it here first, or maybe you didn’t hear it here first. We’re going to be doing some kind of like… It’s a little sad that it’s happening during COVID times because when Drupal 7 and eight came out, for example, were user groups all over the world doing like Drupal parties with cakes and all this kind of stuff. And so, we’re going to try and do a virtual version of that, but it won’t quite be the same. But what’s really cute is people bake little Drupal cupcakes and stuff like that, or showing the Drupal can on the side of a building or these kinds of things. And so, it’s a really creative and innovative community, so I’m sure they’ll figure it out some of the cool stuff.

Angie: But no, in terms of things to cover, I think we covered a lot of it, I think, if you’ve looked at Drupal before and held your nose at it, I would say, please give it another look. We’ve done a lot of work and over the past years to really, really hone in on that user feedback, really hone in on the usability piece, make it much easier for marketers. And also much easier to maintain for developers too. We have done that and we’ve managed to do those feature changes without horribly breaking things for the Drupal 8 people because we kept the backwards compatibility stuff in place. But it means if you haven’t looked at Drupal, even in five years has changed significantly as well because we’ve kept adding features, including API headless stuff, workflow, layout builder, all this kind of stuff.

Angie: And I’d say it’s a great way to build, it’s future-proof, there’s structured data under the hood, so you can… Whatever the new front end trend that ends up being you’re well positioned to jump on that. It’s got a great community full of awesome people. I hang out at open-source communities a lot and some of them are like, “Oh, you don’t know about blah, blah, blah?” Well, whatever, kind of thing. And Drupal is more like, “Oh, you don’t know about blah, blah, blah? Well, let me tell you about it because it’s awesome.” It’s just like a really welcoming cool community, I think, because we come from all different backgrounds and we’re just here to make the web rock.

Angie: So, yeah. Anyway, I hope something in there was helpful. And thank you very much for the opportunity to speak with you.

Drew: It would be remiss of me not to ask you about your involvement in open-source more generally, and especially the hurdles that are very real for getting more women to participate in open source. That’s something that you’re very passionate about, isn’t it?

Angie: Yeah. My background is, I was an open-source zealot back when I was even a teenager, I heard about opensource. I was like, “That is so cool. Everything should be open source.” But I always had this vision that you had to be a genius to work on open source because the people who were big names and open source back then was like Linus Torvalds and Eric S. Raymond and I don’t know. For some reason they carry this glow of like, “Oh, those guys are so smart.”

Angie: And so, I was self taught, I was going to community college at the time. And so, I just figured out this is not for me. But then Google announced a program called Google Summer of Code, which was where you get paid over the summer to work on an opensource project. And I was like, “Well, that’s really interesting because if they know we’re students, they know we don’t know everything yet. Maybe I’ll and just see what happens.” And I picked Drupal because I’m one of those people that just use source on every website I visit, just because I’m curious about what’s happening. And back in the day, there was a website called Spread Firefox that was built on Drupal. And it was really interesting. It was basically the community site where anyone could upload like a Firefox installed Fest or event having their campus, or they could upload a poster that they made or like whatever.

Angie: And I was just like, “That’s really neat. That’s cool. I’ll just file that away for later.” Because I long since given up using actual CMSs because I use PHP nuke and I was like, “No, I’m never doing anything like it. My cat could write better code than this anyway, I’m sorry. Sorry, PHB nuke.” But anyway, I had filed that away and I saw Drupal on listers and I was like, “All right, sure. I’ll give it a go.” And then it was amazing because from this side of things, once I got in the community and was actually contributing, I realized like, “Wow. A, first of all, the people that I thought knew all these things don’t actually know that much. You know what I mean?” They do. But like everyone has strengths and weaknesses. And what I saw happening was there’s people who are really good at certain aspects of the code.

Angie: People who are really good at documentation, people who are good at design. People who are good at explaining things to people, whatever, all of these people collaborating on these changes and all contributing the little bit that they know. And I was like, “Man, if I had known that like 10 years earlier, I would have gotten hit on this, I could have had a whole decade of software experience by now.” And so, I made it my mission to try and break down that barrier, particularly for women because women are socialized from a very young age to not get into tech, to begin with. And then once they get into tech, there’s a lot of like, “Oh my God, it’s a girl,” kind of thing. And it’s just like, if you’re in tech, you’re already dealing with a certain amount of crap.

Angie: And it’s like, why don’t we cut the crap and show people how awesome this is. I love talking to anybody who wants to get involved in open source, but particularly the women because I ran a group called Drupal Chicks for a few years there, which was women in Drupal to get together and talk. And the meetings were so funny because a girl would be like, “Well, I’m not a developer but,” and then she’d go on to like describe all this complex CSS stuff that she does or whatever. And I’m like, “You know that’s development, right?” I see women in particular though, everybody can struggle with this, but women in particular struggling with that feeling that even if I’m a perfectly capable person, that I’m just not as good as everyone else and so yeah.

Angie: I tried really hard to break down that barrier. I also tried to break down the… For my own self like people go, “Who Is Web Chick?” And I’m like, “No, I’m just like a moron.” I was like, “I did the stupid thing last week.” It was hilarious. And just to kind of break down that rockstar idolatry stuff, because we’re all just humans and we’re all just here trying to make it work and yeah. I am passionate about it because I just feel like if there’s someone out there who genuinely loves open source and the ethos of open source and the idea of it, that they shouldn’t be held back just because they think they’re not as good as other people because I can tell you right now, you’re good enough and you should just do it.

Drew: That’s so, so important. I’ve been learning about Drupal 9. What have you been learning about lately, Angie?

Angie: At the beginning of the whole pandemic thing, a friend of mine who teaches guitar, posted like, “Crap, my music school closed. Does anybody want to do Zoom lessons?” And I was like, “Yeah, I have a guitar. Just been hanging out here.” And just because I collect musical instruments just in case of the off chance my daughter wants to get into music. I’m like, “Great, I have all the things.” But I have no idea how to play it. I play drums. And so, I was like, “Sure, I’ll try that.” Actually, for the past two months I’ve been taking guitar lessons online from a friend of mine and I’m learning like take it easy by the eagles and stuff like that and a little bit of blues stuff and I’m so far very terrible, but I’m trying and it’s fun.

Angie: It’s just a completely different thing that it wouldn’t otherwise do. And yeah, it’s been really fun.

Drew: Incredible. If your dear listener would like to hear more from Angie. You can follow her on Twitter where she’s @Webchick, find her personal site at webchick.net. And of course, find out all about the current and upcoming versions of Drupal at drupal.org. Thanks for joining us today, Angie, do you have any parting words?

Angie: No, I’m really grateful to have the opportunity to speak with you. You’ve been around the block like, “Holy cow.” I was looking at your resume. It’s like, “Oh my gosh.” Speaking of people that are up on pedestals, but honestly, that’s amazing. I really appreciate the opportunity to talk with you, especially about the little open-source project that could. And hope that people take the chance to try it out.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

ben-frain-200x200-1
19 May

Smashing Podcast Episode 16 With Ben Frain: How Can I Optimize My Home Workspace?

by TBSCategories: News

Smashing Podcast Episode 16 With Ben Frain: How Can I Optimize My Home Workspace?

Smashing Podcast Episode 16 With Ben Frain: How Can I Optimize My Home Workspace?

Drew McLellan

Photo of Ben FrainIn this episode of the Smashing Podcast, we’re talking about shaping our physical spaces when working from home. What can you do to take a step up from working at your kitchen table? I spoke to workspace geek Ben Frain to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He is a web developer, author, and public speaker who specializes in CSS architecture, methodology, and training. Hailing from the UK, he currently works as a UI UX design technical lead at Bet365, but you might know him better from his books such as Responsive Web Design With HTML5 and CSS, and Enduring CSS, both from Packt publishing. He also writes for Smashing Magazine, and you may remember his series last year on building progressive web apps without a framework. We know he knows his way around the bottom web development landscape, but did you know he owns more trousers than socks? My Smashing friends, please welcome, Ben Frane. Hi Ben, how are you?

Ben Frain: I’m smashing, Drew.

Drew: I wanted to talk to you today about something slightly different from your usual specialism of CSS architecture. With social distancing measures in effect, many of us are finding ourselves needing to spend some serious time working from home. And in a quest to be productive, we might quickly find that our home workspaces aren’t necessarily the best equipped or configured to help us to work well and remain healthy. So, I wanted to talk to you a little bit about workspaces, and generally the things people might want to think about when they find themselves working from home. This is something of an interest of yours, isn’t it?

Ben: It is a little bit. I’m what you might describe as a mechanical keyboard aficionado, but I’m also tend to get myself quite obsessed about getting a physical workspace right. Obviously, a great, many of us, myself included, have been dumped in our home offices or whatever we deem to be our home offices for the foreseeable. And so, you’re continually making that trade off of trying to decide what do I invest in to make myself comfortable and get work done without wanting to spend thousands and thousands of pounds, dollars on stuff that potentially you’re not going to use for a long time. So, I think everybody or a lot of people are making these decisions about what stuff they can grab from somewhere else and what things it’s worth investing in to make things more comfortable. The old adage is always spend your money on your chair and not your desk, and I think things like that are good advice.

Drew: I mean, transitioning to working from home, I think many of us find ourselves working from a sofa or hunched over a laptop at the kitchen table. That’s not really the best way to work, is it?

Ben: No, it isn’t. I mean, I can remember the old house where I used to live, because I had a day job, like a lot of other people and then I’m writing books in the evening, and I can remember spending months at a time where I would put a bread board on my desk hub and my laptop on top of that, and that was my standing desk in the evenings, which actually wasn’t so bad because it did force me to be up right for decent portions of the day. I was looking at before the whole COVID thing came about, because I’d started to write another book in the evenings. I’d made the deal with myself that I would buy one of these electronically adjustable standing desks which I found great utility in. It was a lot of money at the time for a desk because … I mean, obviously, people decide what they want to spend the money on differently, but it always felt like a bit of an indulgence.

Ben: But having had it now, I think it’s worth every penny and I really enjoy the fact that I can sit for a bit and then stand for a bit, and there’s not … You can get the manual ones where you crank a handle like an old 1920s car to get the desk up and down. I went for the electronic one even though it’s quite a bit extra, but I’m glad I did because I’m lazy and I probably would never use that handle.

Drew: So, if we’re looking to move off our kitchen table and think about getting some sort of desk, sit stand is one thing to bear in mind, are there other considerations we should make with a desk?

Ben: Yeah, I mean, I think the actual sort of the desk top itself, you can get very inexpensively, even places like Ikea, which have obviously been thrashed with everybody trying to get hold of an inexpensive desk at the moment, but you can still get a slab of wood fairly inexpensively. I mean, chair is obviously the big one. I mean, I’m lucky in that touch wood, I’ve never had any problems with back or any of that thing that is typical of people that work at computers all day. But I think even things like a popular one that you see is like the Herman Miller Aeron, is one of the very popular maker chair, but really quite expensive. But you can pick them up around $ 300, something like that refurbished, which is probably when you’re trying to decide where to put your money to be comfortable for a whole day’s work, it perhaps isn’t as bad as it sounds. And then obviously the same, I know some people struggle with RSI, so I know a lot of colleagues of mine have got the vertical mice which is they’re relatively popular to prevent that, which again, more expensive than your typical mouse, but people don’t always consider the fact that.

Ben: I know trades people who work as builders and that they will think nothing of spending a few thousand pounds on a particular piece of kit. And yet often we will just use whatever comes stocked with a computer that we have and we’ll bulk at the idea of spending a hundred dollars on a mouse or $ 200 on a keyboard. And yet really we have a relatively low entry point in terms of cost in order to do what we do. I think we have a tendency to be a little bit perhaps cheapskate in that regard. But if you find yourself getting physical problems or you’re not as comfortable as you may be, it perhaps is worth thinking about those things before buying other things I guess.

Drew: I guess preventative expenditure on decent chair for example, will save you an awful lot when it comes to medical bills and physiotherapy or anything like that that is required to put the problem right.

Ben: Yeah. And I suppose it’s all conducive to you being good at what you do or being the best that you can at what you do. If your limitation is a kit that you use, and you can alleviate that limit, then it seems sensible to do so.

Drew: So if we’re thinking about spending money on our work environment, if we’re currently sat at the kitchen table on a wooden chair or whatever, you’d reckon a chair is the best place to start?

Ben: That would be my advice. Yeah. I mean, I can’t profess to be an authority on these things, but it seems it’s a sensible, it’s probably the single most important thing you could do to make yourself comfortable throughout the day. You can start with something fairly expensive. I made the same mistake and I ended up getting a 45 pound office chair from Amazon and I didn’t realize that it didn’t have a tilt forward, whatever the right word for that thing is, on the axis. So what I found is it was digging into the underside of my thighs, behind my knees and I was thinking, why are my legs going dead after 45 minutes of sitting in that thing? And you just don’t, I think particularly if you work for a company that provides decent office chairs, you just take them for granted and it isn’t until you look at that particular make and brand that you go, “Oh my God, this is a $ 700 chair.” When you realize that crikey, people have thought about this and done a lot for you and then obviously you come to your home environment and you think, “Why not spending X hundred dollars on a chair?” But maybe it is worth it. Particularly if you’re here for the long haul.

Drew: And we talk a lot as developers, don’t we? About this productivity consideration of being in the zone and being able to get in the flow of writing code or working on a thing and time just seems to pass by and you can be super productive. Well, one thing I’ve found that can pull you out of that zone quite quickly is needing to stop and stretch because your legs have gone dead or your back’s aching. That can really disrupt your productivity as well as the longer health implications of that.

Ben: I mean, what have you found true in your situation? What have you done? What have you found the most effective?

Drew: So at the moment during lockdown I am staying with my parents, so I’m on my mother’s desk, which has a filing cabinet on one end and a bookcase on the other. So it’s all a bit makeshift. But at home normally, I do just have a couple of the cheapest Ikea desks organized in an L shape. So I tend to work with a couple of computers, and I have one on one and one on the other and spin between them. I used to have a lower back complaint quite regularly in my twenties where I would be sat on my desk for long periods and occasionally every few months I would find I couldn’t get out of bed in the morning because something in my back had gone. And the thing that immediately helped with that was, as you were saying, the tip forward seat angle on a chair. So having a chair that did that immediately helped because I think it resolved my posture.

Drew: So that helped immediately, but longterm what has helped and what means I don’t have any back problems at all now is just improving my personal level of fitness and activity. And that just having a bit more core strength and being just a bit more fitter and a bit more active has meant that I can actually, I can sit in some fairly bad chairs and things for a while and survive it. Yes, very much immediately having a chair that would tilt forward just to bring my back up and get me into a good posture, that was a definite, definite improvement for my back immediately.

Ben: Yeah. I mean, that’s interesting because it’s another thing that I guess a lot of us are missing now is, I mean, I’m by no means a gym rat at all. I just go because I don’t want to die essentially. But things like good barbells with plate weights, I naively thought, well, I’ll just go to my local shop. I’ll be able to get some of those maybe a hundred pounds and then you realize that a decent barbell itself is $ 200 at least. But obviously stuff like that and keeping yourself in a decent physical shape whilst you’re a couch potato is quite important as well. So much to think about for the people that have not been working from home and all these things become apparent very quickly.

Drew: Definitely. And in terms of working from home, one of the things I find that I’m doing a lot lately is spending time in virtual meetings via Zoom or Skype or whatever. Are there any things, any considerations you’ve made in terms of making the environment better for being on calls?

Ben: I suppose. I mean, obviously putting your screen away from all your socks and pants, that’s probably quite important. I mean, I’ve found as well that perhaps try and be conscious of the fact that at first I was raising the desk because I’ve got this desk that will raise up and a couple of people said to me, it looks like you’re about to tell me off because I was looming over them because the … long story short, I suppose making sure that when you take calls, it’s quite nice to be looking directly into the webcam. I always tend to ask people if possible, if we can do a face to face call because I think one of the things we’re incredibly lucky in this situation about is that speaking on a video call now is so much better or even when you didn’t even have it 20 years ago. And being able to see this nuance in people’s expressions is so much more useful on a remote call than just hearing the voice. And so if you’re going to do that obviously, being able to look straight down the camera or so that they can see you not at some weird awkward angle and there’s some okay lighting in the room, I say this as I look at myself half and dark in this situation, but those sorts of things are worth thinking about I think.

Drew: One thing I’ve found has really helped with my setup is I’ve got a big LED panel light. It’s called an Elgato key light, which is on a big stand.

Ben: Oh, like a big uplighter sort of thing?

Drew: It clamps onto the desk and is on a big pole and then sits above the monitor and shines a blanket of light down on there.

Ben: Oh, that’s pretty good. So it’s more like a daylight kind of light I take it?

Drew: Well, yes. You can actually adjust the color temperature and the brightness of it from software on your desktop.

Ben: How can you tell a difference if you use that light? Does it feel better?

Drew: It makes a big difference. Yes, especially you get often with webcams. You get the situation where the background is more lit by the windows in the room than you are and the camera doesn’t expose for the right thing. So making sure that you as the subject and nice and bright in the frame really helps the camera to get good focus and therefore your facial features are clearer and you can communicate well that way.

Ben: These are like Hollywood techniques, truths. Incredible. I mean, does that help as well with things like glare on your screen because you get in a more even diffused light in the room? Or have you not noticed?

Drew: It’s not particularly lighting the screen. No.

Ben: Okay.

Drew: I mean, glare on the screen is a definite thing that we should really think about in terms of workspaces. Where I am here, I’ve got conservatory windows at the end of the rooms. There’s a lot of light flooding in there.

Ben: I was just going to say, just what you need.

Drew: First thing in the morning, it can be very, very difficult. I have my editor set on a dark theme usually. My code editor. And so then I often find that I’m not using the left hand side of my screen, which is slightly washed out by the windows and I move everything over to the right side.

Ben: And do you think that’s a subconscious thing? Just because I just can’t see it so I’ll concentrate my efforts elsewhere.

Drew: But actually probably what I should be doing is switching to the opposite color scheme in my editor. I should be switching to dark text on a light background perhaps during the day.

Ben: They’re not cool anymore though Drew. Or didn’t you get that memo?

Drew: It’s not cool, no. But neither is failing eyesight.

Ben: No, no, definitely not.

Drew: One of the sorts of things in people’s workspaces that perhaps they don’t think of so readily when you think about optimizing how you work is perhaps one of the most common input devices, which is the keyboard. You wrote recently for Smashing Magazine on the subject of mechanical keyboards, which are seeing something of a Renaissance, aren’t they?

Ben: Yes, that’s right. It is funny because I always say to people, I get… because in my circles, people that I know, people are aware of my minor obsession with these things. And so I get asked quite a lot about them. And over the months and months of this, I thought, it’s one of these sorts of areas, which is because it is quite niche you tend to end up on a particular forum for this topic and you very quickly feel like, “Oh my God, this is a level of geekery beyond something that I’m comfortable with.” And that comes from somebody who’s relatively geeky. But I think there’s definite merit in them in terms of, I would never say to somebody, this is something you absolutely need to make you better at what you do. It more falls into the camp of, because you can get a mechanical keyboard, which makes you feel productive and in some weird pseudo way that makes you more productive. So many of us take the keyboard that comes with our system.

Ben: I never think about it any more than that. And just off we go. But I was surprised once I started looking at all the plethora of different layouts that you can get because I just wasn’t aware of the fact you can get these tiny little 40% size ones, you can get 65% ones which do have the arrow keys and some of the others, but lose the function keys. And it was only when I really started to analyze what I did with a keyboard and the keys that I pressed that I realized there was whole areas of keyboard, which is taking up often a substantial portion of your free desk space where you might prefer to jot stuff down and all the rest of it. And I realized that this big desk commander that I was using with a dedicated number pad was just an indulgence really. And I thought I needed those keys and it turns out I actually didn’t.

Ben: So, aside from the physical considerations, there’s just a very nice, I mean, mechanical keyboards often, you put one in front of somebody who’s not seen one before and they just laugh and think that it’s something out of war games from the 1980s. But once you overcome the fact that it isn’t a sleek, minimal thing like that and you actually use it and you get a feel for the key travel and stuff, you actually realize that there’s a rhythm that you can get with them, which you can’t get with these very shallow chiclet keys that we’re used to on keyboards nowadays and often things like iMac and the light ship with these very, very slim keyboards with very minimal travel on the keys, which are fine but this is obviously, we’re talking about keyboards that are the other end of the scale.

Ben: So I always say to people, let’s be clear, this isn’t an exercise in good economics because they’re very expensive when you can go and get a 15 pound keyboard from your Tesco’s, Walmart, et cetera. But it is an investment in your own sort of, I mean, the joke I allude to in the Smashing Magazine article is the Rifleman’s Creed, which is a soldiers tool as it’s rifle. And for us more than anything else, it’s the keyboard. And so it’s finding something that particularly suits your needs and you enjoy using and you take care of and get the most out of as you can.

Drew: As you say, I think of mechanical keyboards a bit like using the keyboards that were on computers when I was growing up in the 1980s, A really retro style of technology. Hasn’t technology moved on, on the keyboards, that ship with modern computers just better than that old technology?

Ben: Well, I think the funny thing is, better is a subjective term. And so typically we have become accustomed to these very, taking the ones that ship with an iMac for example, which are incredible pieces of design, very slim, very elegant looking, but in terms of actual feedback to the user, the key travel that you get, I’ve just found it’s incomparable “proper keyboard”. And so once you kind of, if you eliminate, if you can embrace that aesthetic of the retro keyboard if you like and get over that and actually just use one for a little bit, I don’t know many people, well, I don’t know anybody that’s gone down that path and then backed back out and gone, “Actually I prefer the really shallow travel, I like the really cramped arrow key set up.” Because for what we do, whilst it’s lovely on a laptop because it lets you have a lovely sleek laptop that you can take different places, if you’re sat in front of a machine and you’re using that, and code is more than anyone else because we tend to have less reliance on the mouse.

Ben: Those keys are doing stuff for you. They’re working for you. So I don’t think you want a tiny little arrow key cluster. I don’t think you want a page up and page down doubled up on another key. These are the sorts of things that once you try and analyze how you work with your keyboard, it opens your eyes a little bit. So it’s a bit of an undoing of the aesthetic norm and the, what society tells you your keyboard should look at and how it actually works for you. I don’t know if that makes much sense?

Drew: Is it just for programmers that the mechanical keyboards are useful or do they have wider appeal than that?

Ben: Oh, I mean, the writers are the big proponents of them I suppose. I know for example, I think there was an anecdote of Terry Pratchett. He famously, once he found the keyboard that he liked, he bought 10 of them just because he never wanted to not have that keyboard because it was like you’re saying it’s about you don’t want that friction. You don’t want something to throw you out of your zone. It’s basically anybody who types on a keyboard for a long period of time rather than just casual use I think. Whether you’d go the route, if you’re somebody that’s jotting about to lots of different locations, you can get fairly compact mechanical keyboards as well that have got Bluetooth. I mean what keyboard do you use at the minute Drew? What’s your sort of-

Drew: Up until very recently, I’ve been using the iMac flat.

Ben: Yeah, the chiclet key one.

Drew: But after reading your article on Smashing and chatting to some colleagues at Netlify, a lot of them are very big mechanical keyboard nerds.

Ben: Oh, Okay.

Drew: I’ve decided to dip my toe in and I’ve got a mechanical keyboard on my main development machine. I’ve been using it about four weeks, I think about four weeks. And I’m finding that I’m very slow and making a lot of typos because it is so different from the very flat. I mean, the keyboard that I’m used to is basically like what comes with a laptop, just so flat, very low travel. And I’ve been using a keyboard of that style for maybe 10 years since Apple first started doing those as external keyboards. So then moving to something with much further travel and finding a keyboard with an angle to the keys is quite strange. I’ve had to prop it up quite a lot at the back to bring the keys forward to me a bit because I was finding that the whole angle was very strange and that has helped. But I’m finding I’m very slow, but I am getting faster and I am making fewer mistakes. I’m getting used to it. But I’m actually enjoying a lot of utility. The particular keyboard I’ve got has got a screenshot button.

Ben: Never knew you needed.

Drew: No, I know. There’s a key combination to activate during the screen capture, but this keyboard has got a button that does it. Actually, it’s something I do multiple times a day. In pull requests we tend to include a screenshot. This is what it looked like before, this is what it looked like after.

Ben: Right. Okay.

Drew: So it’s something I’m doing all the time. So having a dedicated key for it I found is actually incredibly useful and I’m feeling the benefit of that.

Ben: I think one of the other things that’s really good in some of the modern mechanical keyboards as well is they often have, they’re entirely re mappable so that you can put macros onto keys and you can, like for example, I have the shift key on mine set so that if I just tap it, it gives me a right bracket or parentheses and U S terminology, which in itself is quite useful for functions and all the rest of it. But if you’re using them and you want to skip along in normal mode through sentences, it’s that key that you do, which would normally be a hold on the shift and press the bracket key. So again, it’s about trying to analyze what you’re pressing day to day and thinking around that.

Drew: Mechanical keyboards in my experience tend to be a bit noisier.

Ben: They can be.

Drew: Is that a consideration? And if you’re working in a shared workspace, are all mechanical keyboards loud by definition?

Ben: No, they’re certainly not. And I think like all of us, when you first think of mechanical keyboards, if you have any idea of what they are, you think of these giant clicky clucky. When you’ve got the keyboard warrior that you’re speaking to on a screen share and you can barely hear the voice because all you can hear is this machine gun of keys. However, the main switch types or the clicky ones, which are the ones that we’re talking about there.

Ben: There’s then tactile switches, which give you the same travel, but you don’t get the physical and audible click as you push a key down. But then there’s also linear keys, which are just straight up and down, but you can also get silent variants of nearly all of them. If you are somebody who needs to sit in an office next to somebody, they’re probably the sort of one that you should go for. And then they’re no less, they’re physically just as nice to use I would say. I know that some people say they actually, the rhythm of the sound helps them to feel productive. Which I do understand that, but obviously if you’re working amongst other people, your productive might be somebody else’s disruptive.

Drew: What are the things that somebody should look for in terms of mechanical keyboard? I mean, it all starts with the keys, the bits you actually touch. And they can vary quite a lot.

Ben: Absolutely. So there’s the aesthetic side of it, which typically we developers and designers, we have opinions about what we like and every conceivable color and the way even that the legends are printed on the keys. You get some hot shots that just do away with the legends altogether and they just like some blind magician know which buttons to press. I’m not one of those. You also get people that can put the legends on the front side of the keys. And there’s also little things that for the longest time, looking at this keyboard, I’ve got on the J key and the F key, a little hump, which I assumed that was something to do with the manufacturing process.

Ben: But it turns out they’re homing keys so that you can rest your fingers on them and feel where you are on the keyboard. And then there’s also different sorts of plastic. There’s different angles to the keys themselves. I suppose if I was speaking to somebody who’d never had of mechanical keyboard before, although it sounds like a copout, I would probably just say, pick one you like the look of to begin with because the chances are you don’t really know what you like until you try it and try a few and sadly that’s where the cost of this obsession comes into play because you might find yourself going through three or four keyboards until you find one that you feel really suits not just the key switch type but the key cut material, the layout size, how customizable it is or isn’t. And a bit like the code editors, you have to be conscious of the fact that I could quite easily spend two days just messing around, setting my code editor up. Whereas really I should myself a big slap around the face and after a very limited amount of time, just get on with using it.

Ben: So it’s like all of these things you do have to be conscious of the fact that you can indulge yourself too much into these things. So I would say get one, use it. The primary concern that, as you alluded to before, should probably be whether you want a silent one or a clicky one to begin with because that’s the thing you can’t easily undo. A lot of them these days also have what’s called hot swap sockets, so that if you get yourself a keyboard and decide you actually hate the feel of these switches, you can pull them all out and put a different set of switches in, which is not necessarily cheap, but it’s a lot cheaper than getting a whole new keyboard. But the resale value in these things is typically very good anyway. So if you spend a couple hundred dollars on a keyboard, you probably get 150 back, even like six, eight months down the line if you needed to.

Drew: As you mentioned, there are all sorts of different types of switches that can exist under these keys. They’re called key caps, aren’t they on the top? Which is the bit that you actually touch. But then underneath those you’ve got different switches.

Ben: Yes.

Drew: I found personally that I had no way of being able to comprehend what switches I might want without being able to try them out. And of course at the moment in particular, it’s very difficult to try out anything. You can’t go into a store. I mean, even if you could find one. Is there any default switch you’d recommend for somebody if they didn’t know where to start?

Ben: Yeah, I think I would say that if the idea of a clicky one appeals, what you should be looking for, it is a slightly confusing thing. There’s basically colors which … so Cherry MX who were the original makers of the majority of keyboard switches that you get in mechanical keyboards, they designated MX Blue as the clicky switches. And what you get now is even though other companies are now making what’s called MX compatible switches, which is a different company creating the same style of switches, they follow on that coloring convention. So typically blue switches, whether it’s Kaihl or Cherry or somebody else, or your clicky sort, a brown will be tactile, what’s called a tactile switch, which is you get that same resistance at the top of the key press, but without the click sound.

Ben: If you like the idea of a key which doesn’t have any resistance and it just travels up and down in a linear fashion, a linear switch, you’d be looking for something which is called an MX Red or equivalent. And then something which is more silent, they’re typically designated as quiet switches or silent switches. There’s a whole different camp of keyboard switches by a company called Topre, which is based in Japan. But that’s probably something I would say not to worry about for now because they tend to be both more expensive, harder to come by and I would probably try and rule out by saying go for one of the easier to come by MX variants first.

Drew: I chose MX Brown for my first keyboard.

Ben: Yes, I think I did the same as well.

Drew: I’ve no idea whether I like them or not because the whole thing is so new. The one thing we need to keep in mind I guess is different layouts of keyboards. I mean, I work with MX and obviously lots of people got PCs and various other things. Is that something to bear in mind when choosing a keyboard?

Ben: It’s almost a non problem these days. It used to be that some of the manufacturers, Filco for example, which they’re a good manufacturer of mechanical keyboards, but they used to have problems with Mac compatibility. Which you could work around with software for the Mac. It was a tool that used to be called Key Remap or something like that. It’s now called Karabiner, it’s a freeware piece of software which gets around the problem, but it was just an extra little bit of faff that you had to do. But typically nowadays with either dip switches on the bat, which are little tiny physical switches or the keyboard will have their own way of pressing certain key combos to program where the super key is so if you’re on Lenox it’s super key or we have the Mac key or the Windows key and you can typically swap all those sorts of things around with no problem at all. So it’s really more a case of … I mean, the example I gave in the article was there was a freeway piece of software which lets you, you stick it on to record and it logs your key process, which obviously you need to be sure that you’re comfortable with that to begin with.

Ben: But you can leave that thing running and it will produce a heat map of which keys you press and how often you’ve pressed them and all the rest of it. And often you’ll find that your expectation doesn’t match with the actual data. And that can therefore influence whether you want a keyboard that’s got a big number pad. If you’re somebody that works with Excel all the time, you more than likely going to make use of that. But if not, you might find that actually you just don’t need that whole section of the keyboard and you can go for something more compact. Also, the other thing going back to comfort is ergonomic keyboards, which most of us at some point have seen somebody with one other Microsoft natural keyboards where you’ve got the slightly turned sets of keys for left and right hand.

Ben: In the mechanical world there’s a few different ergonomic keyboards. The big one being the Ergodox EZ which again we mentioned in the article, but that’s not only two separate keyboard panels, but it also lets you adjust the rake of the key panel as well. So you can very easily change exactly the shape of those key pads and where they are. So again, although they’re not cheap, if you’re somebody that suffers with RSI and the light doing a lot of keyboard work, it’s perhaps worth looking at one of those.

Drew: Now, when I was looking at mechanical keyboards, I discovered that there were lots and lots of options I could build that came pre-assembled, ready to go, just plug in an and off we go. But there were also lots that seemed to come essentially as kits or as just a board and you could buy just switches and you could buy just key caps and you assemble it all yourself. That sounds pretty daunting.

Ben: Yeah, I mean it is and I would certainly say if it’s your first mechanical keyboard, don’t go there. It’s too much to take on at once. If you do find yourself enjoying keyboards as it were, it’s a bit like a Lego or a Meccano set. I recently did the first keyboard build of my own, having had them for four or five years. And that involves soldiering the switches onto the board and all sorts, which is not a level of geekery that I would suggest for the casual use. Just get a keyboard and make use of it and see how you like it first. But because they are getting more and more popular, gaming in particular is where they’re really starting to find a market now because you’ve got gamers who are obsessed with the shortest possible input lag of them pressing the space bar or whatever they’re pressing to nuke somebody or whatever it is that kids these days do. I’m out of that loop now. But that’s where they’re gaining notoriety and popularity and you’re getting the big peripheral brands like Logitech getting involved and Corsair that now make mechanical keyboards. So you’re getting more and more of this stuff is more easily accessible and easy to get a hold of.

Drew: Moving on from keyboards slightly or I mean perhaps, maybe not. Earlier in the year, you had an accident didn’t you? And lost most your finger, is that right?

Ben: Yeah. So I’ll give you the short, your notes version of it because it’s quite a story. I was essentially, it was early February and it was one of the first days in the UK, we had snow that year. And as is typical in the UK, if a snowflake falls, the entire infrastructure grinds to a halt. And so we were stuck in traffic having come back from the gym at lunch, it was five of us in the car. And we said, well, we’ve got a meeting at three o’clock and it was like five to three, we weren’t far from the office. Let’s just take a shortcut through this bit of land, which we’ve done many times before and we’ll get back to the office. And as we went through the other lads went one way. Three of them went one way and I carried on the way that I already knew and got to a bit and a new fence had been installed, but it wasn’t a sketchy walking fence, it was an every day, brand new, no sharp, edgy bits, nothing like that. Lots of footholds. It was maybe six foot tall, this sort of fence is an average person.

Ben: You’ve probably been over a hundred times before and would’ve thought nothing of it. So I climbed at one side, hung on the other and then I was maybe three or four inches from the floor and dropped off. I felt a bit of a weird twang in my hand, so I wondered, “Oh, I caught my wedding ring there on the fence, I wonder if I put a mark on it?” Glanced down and there was very little of my finger left. So it turned out that on the side of the fence I couldn’t see there was, where the crosses terminate, I had caught my wedding ring on it and it essentially yeah, removed the biggest part on my finger. And so very, very bizarre set of circumstances as it was then trying not bleed everywhere. At the same time find the other part of my finger and hopefully could stick it back on. In my naivety, I thought, “Well, as long as I can find the finger, this is easy these days, they’ll just few stitches, I’ll be back in the game.” But it turns out when you do it’s called a ring avulsion. And I don’t know, it’s actually quite common.

Ben: They told me up at the hospital that I went to that they get at least one a weekend, which I was crikey, I really would’ve liked to receive that memo. I perhaps would have thought twice about wearing a wedding ring. But because it’s sort of, without being too grim about it because it’s torn away from your hand, the ligaments get pulled from down in the palm of your hand as well. So it’s almost impossible for them to put it back. So long story short, it’s by no means fixed now, but it’s on the way. It’s probably going to be 12 months until it feels, I wouldn’t say painful. It’s uncomfortable more than anything. And obviously getting used to the fact every day you wake up in the morning and like look and “Oh my God.” Mentally, it’s quite a hard adjustment to make. But very quickly I was able to use the keyboard. But it’s funny because your mind still thinks you’re at the end of your finger as where it used to be.

Ben: And so you’re missing a lot of keys as you type and you have to make that adjustment that Oh, actually that finger’s not there anymore. So these particular key combos that I’m used to doing and have been ingrained in my mind for years and years and years, you have to unpick and redo. But I guess the human mind has an incredible capacity to work around these problems. And I don’t feel now even just … so that was 10th of February. Here we are beginning of May, I don’t feel now like it’s a hindrance, particularly on the keyboard. Things like lifting waits or rowing or something like that, you can certainly still tell a difference. And I think it’ll take a while for my hand to get stronger again.

Drew: Were there any adaptations that you needed to make other than the mental adaptations when it comes to typing? Is there anything else about your workspace or anything that you’ve noticed you needed to change?

Ben: I don’t think there has been really, I mean, in an odd way I’ve been very lucky because that particular finger is probably the weakest finger that you have anyway. And it’s on for me, my nondominant hand. I didn’t realize at the time, but apparently your little finger is 40% of your lifting ability. It comes from your little finger. So they said, “If you’d had lost your little finger, it would have been far greater implications.” And obviously your thumb is a really big deal. So in a weird way they said, “If you were going to lose a finger, that’s the one to go for.” Great. But the funny thing is in terms of actually your typing speed or whatever, your brain almost didn’t have to consciously do anything at all. It just remapped over maybe three or four weeks. I was away from work for two weeks, but I still had a book to finish. And so I was using that as my practice. Trying to get back up to speed as soon as I could. But yeah, a very bizarre set of circumstances. You always arrogantly assume these kinds of things out into other people and then one day it happens to you.

Drew: Exactly. Yeah, I think so many people who note the fact that they are suddenly needing to benefit from what we consider to be accessibility features of the work that we do. It’s not because they’ve had an incredibly traumatic life changing incident or there’s not that they were born in a particular way, but just something smaller, a minor break of an arm or a losing a finger or any of these things. Failing eyesight can just bring home the need that actually, accessibility is something that we all rely on even just as we age.

Ben: Yeah, absolutely. I mean, it’s funny because I’ve always been mindful of accessibility for sure. But I don’t think I was perhaps as acutely aware as you say of just the fact that you can become that same situation yourself like you say, it’s my own arrogance that you think you can go on forever feeling just fine. But yeah, I suppose it’s not a bad thing to get a slap in the face from time to time and makes you reappraise things.

Drew: Definitely. Yeah. So I’ve been learning all about optimizing my workspace. What have you been learning about lately?

Ben: Well I’ve got a book that I wrote the first edition of in 2012, the one that you mentioned at the start of the show. And the publishers hassled me every three or four years to do it. Another version of it, which I always grumble and roll my eyes about and I think this is done, like there’s nothing new to add here. But it turns out things move on quite a lot. And I think the majority of my time at the minute has been, I’ve learned a hell of a lot about CSS Grid, which I know Rachel of this parish is a big proponent and has been heavily involved in. And I think the sort of thing that I’ve said to people is that it’s probably, getting a good handle on CSS Grid is probably the biggest upgrade to your CSS skills you can do if you don’t already know Grid. That’s been fantastic.

Ben: And then for the last sort of, I started out like a lot of people my age, I didn’t go into web development as an intention. I find myself there. And so for the longest time I stayed away from what we’d call real programming languages, and it’s only in the last two or three years that I’ve got into JavaScript and TypeScript and so classes and things like that in JavaScript, which I’ve just tried to steer away from the longest time. That’s the stuff I’ve been looking at and trying to really wrap my head around destructuring and all this stuff. There’s no end in sight for learning in web dev world, that’s for sure.

Drew: That is definitely for sure. If you, dear listener, would like to hear more from Ben, you can follow him on Twitter where he’s at. Ben Frane, and find his personal website at benfrane.com. Thanks for joining us today. Ben, do you have any parting words?

Ben: No, just if you wear a wedding ring, maybe think about perhaps not.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

rachel-andrew-tw-profile
21 Apr

Smashing Podcast Episode 14 With Rachel Andrew: How Can I Run Online Workshops?

by TBSCategories: News

Smashing Podcast Episode 14 With Rachel Andrew: How Can I Run Online Workshops?

Smashing Podcast Episode 14 With Rachel Andrew: How Can I Run Online Workshops?

Drew McLellan

Photo of Rachel AndrewIn this episode of the Smashing Podcast, we’re talking about running online workshops. How can a traditional event adapt when participants can’t attend in person? Drew McLellan talks to Rachel Andrew to find out.

Show Notes

This episode of the Smashing Podcast is dedicated to the memory of Christopher Schmitt, who sadly passed away last week. A familiar name to many of us over the years as an active contributor to both the Web Standards and Accessibility communities, Christopher, along with his partner Ari, was also a pioneer in conducting online workshops and conferences, which is the subject of this podcast.

Christopher was a skilled web practitioner, a generous educator, and a wonderful person to spend time with. His contributions to our industry were numerous and valued, and he will be missed by us all.

If you have memories of Christopher you’d like to share publicly, you can do so via this community site.

Weekly Update

Transcript

Drew McLellan: She is editor-in-chief of Smashing Magazine as well as being a web developer, writer and public speaker. She’s the founder of web development consultancy, edgeofmyseat.com, responsible for products such as Perch CMS and the slide sharing and public speaking portfolio platform, Notist. She’s a member of the CSS Working Group, and many will know her for her prolific writing and teaching on modern CSS layout techniques, such as CSS grid.

Drew: So we know she’s an expert in CSS and in teaching, but did you know she’s a recognized authority on carving turnip lanterns? My Smashing friends, please welcome Rachel Andrew. Hi Rachel, how are you?

Rachel Andrew: I’m smashing.

Drew: So I could talk to you all day about any number of interesting CSS topics, but you write and you speak so much about these sort of subjects, that there’s a plentiful supply of resources that people can reference. And not least of which being things like your Grid By Example site or you CSS Layout Workshop video course. And of course, there’s plenty right here on Smashing Magazine. But what I wanted to talk to you today was something that was almost a byproduct of your expertise, isn’t it? That you have to end up getting up on stage and communicating what you know with other people. You do an awful lot of speaking at conferences and teaching in person workshops, don’t you?

Rachel: Yes. Yeah, I do. I have to done for about, I don’t know, the last six or seven years. And the last few years I’ve spent about half of the year on the road speaking and yeah, doing workshops. In particular for Smashing Magazine, did a bunch of workshops every year For Smashing. So that’s the something I’ve been doing quite a lot of.

Drew: So what does the shape of your year usually look like with conferences and workshops?

Rachel: Ah pretty much, I’m springing out in particularly. I’m generally just on the road quite often for three or four weeks at a time, go for one thing to the other. I try and link these things up, so I’m not sort of constantly flying back and forth over the Atlantic corridor for you. But yeah, so spending a lot of time either on stage talking to people about CSS or in workshops, and then going to see this working group meetings and sitting with a bunch of other people who really, really likes CSS and talking about CSS. So that’s mainly what I’ve been doing, and in between that actually trying to… Well, spending a lot of time writing these talks and workshops while I’m not giving them. And then then getting back on the road again. So that’s been life for, yeah, several years

Drew: As we speak, we’re in the thick of the Coronavirus pandemic. So this year isn’t really shaping up like a typical year for you or for any of us. So what’s the situation with your conference season looking like at the moment?

Rachel: Yeah, empty. It’s really bizarre looking at my calendar and not having it full of flights and hotel bookings. I’ve spent quite a lot of time in the last few weeks getting flights refunded and getting vouchers to use because I had all of my spring travel booked. I’ve been organized. So it’s been really strange then remove all those things from the calendar and be looking at not going anywhere. It’s very, very unusual for me. So yeah, it’s been quite a shock because it’s not happened for so long. And every year after, I’m not going to do so much travel this year. And of course, the diary fills up and off you go. So for this to happen and to happen so dramatically, and in a way that I don’t actually know when it’s going to start again. I’m looking at things in, say two months time, and thinking, well, will I be able to do those?

Rachel: I don’t personally have any health issues that… if it is okay to travel, I probably feel okay to travel. But I don’t know if it’s going to be okay to travel. I don’t know if it’s going to be sensible to travel because you might go somewhere and then them cause a lockdown and you get stuck there or get stuck in quarantine. So it’s very, very strange to not have this quite rigid plan, which is what I’ve had for the last few years where everything has been planned around me getting on a plane and going to speak somewhere.

Drew: So lots of conferences, probably in conferences and workshops, have been either canceled or postponed. I’m including the rescheduling of our own Smashingconf events and the workshops that go alongside that. Now hopefully, we can look forward to rescheduled Smashingconfs later in the year, but the workshops are also going online, is that right?

Rachel: That’s right, yeah. We’ve very, very quickly… Once we realized we were going to have to postpone San Francisco, we have… See we have workshops, both myself and Vitaly run workshops at Smashingconf, and they were sold out in San Francisco, both of our workshops. And obviously, we have lots of other people who come and run workshops for us, people who we’ve worked with for a long time. And they were finding that all their workshops… And for those of us who do workshops they’re actually a key part of our income. Public speaking, you don’t earn a lot of money typically going and public speaking. Most people aren’t paid a lot, not when you consider the amount of time it takes to write talks and so on. Workshops tend to be quite a nice way for people who are good at teaching this stuff to earn some money.

Rachel: And so they represent people’s income. And so, not only did myself and Vitaly had lost our workshops early this year. We also realized that a lot of our Smashing speakers also, were reliance on those workshops. And so we thought, well, why not just take them online? And very, very quickly, really, within days of that happening, we decided that me and Vitaly would be the first to stick our heads over the parapet, given it’s us. And we could figure out how to do it. And we also have very different workshops. Vitaly is much more collaborative. He has group activities and things. I teach classroom style. So between us we thought, well we kind of covering all the bases. So that was really… We thought, let’s just do it, let’s see if it works. So we advertise them, we figured out how long did each take. And then we sat down and said, well what does an online workshop really look like? What is this?

Drew: I think from a technical perspective, as web developers, we immediately think, how on earth are we going to deliver something like that? There must be lots of different platforms that you looked at. What were the different things you looked at and what Smashing eventually come with?

Rachel: So we’ve had a look at all sorts of things, and we’re still kind of in the process of doing that. We’re using Zoom at the moment, and the reason we’re using Zoom is accessibility. It was the most accessible of the platforms. Obviously, we don’t want to cut people out because of the platform we’ve chosen. And I think the platforms are getting better and people are… I think that a lot of platforms have had people come to them and say, yeah, you look great, but you know, we need you to be accessible. And so, so Zoom is the easiest for people to use at the moment. And so, that’s why we’ve ended up using them.

Rachel: I don’t know whether we will do forever, but that’s what we’re using at the moment, and it’s worked pretty well as a way to do this stuff. And it gives us the flexibility we need. We’re able to do breakout sessions for Vitaly’s workshop and things. And yeah, so platform-wise, it seems to work. We didn’t really have any major issues across the days. And say we’ve run my workshop and Vitaly’s workshop now… Are the two that we’ve actually done, and then we didn’t really have any technical problems as it were. So that was really helpful. Yeah, because it’s always a bit of a worry thinking everyone’s silent in all these different locations, and this has got the work.

Drew: As you say, you’ve run two workshops so far, and there’s an awful lot more scheduled to come up in the future.

Rachel: Yeah, we’ve got a whole bunch of them. So the upcoming stuff, I’m just having a look at the list, we’ve got Brad Frost doing his Design Systems. We’ve got Psychology for UX with Joe Leech, Advanced CSS and Sass with Miriam Suzanne. Vitaly’s doing his Smart Interface Design Patterns again. I’m doing my CSS Layouts Masterclass again in June, and we’ve got a Front-End Accessibility Masterclass with Marty Sutton. So those are the ones lined up until June now.

Drew: That’s quite a big undertaking, isn’t it? All those different instructors as they were, with different styles of teaching and different requirements from the platform.

Rachel: Yeah, I think so. That’s why we started with Vitaly and I because we have this different way of teaching We thought that would be a good start. We could iron out some of the things, and then we’re going to then write up the stuff that we figured out. To hand that over to other instructors. Because we were very keen that they didn’t just become… we didn’t want it to be a second-rate experience. It wasn’t like, Oh well, you can’t come and see us in San Francisco, and so this’ll do. We actually wanted to see, how can we make an online workshop a really cool thing. Because actually, there’s a whole bunch of people who, even if we could all travel around the world… there’s a whole bunch of people who can’t.

Rachel: There’s plenty of people who, they don’t have the budget to fly places, or they’ve got family, or they just don’t like doing that sort of travel, or they’re concerned about spending a lot of time on airplanes. And I think actually, this is something that, that can work very well as a thing, and we’ve been forced into it to some degree. And we’ve had to figure out how to do it, but it’s certainly not a lesser thing. It’s a different thing and we’re figuring out how to make that happen. But it doesn’t have to be a second best from an in person.

Drew: So what does the experience of attending an online workshop feel like for a participant, where obviously it’s can be very different from the in-person experience?

Rachel: I think we looked at what people really say they get from coming to an in-person workshop. And a lot of that isn’t really just the teaching because all of that stuff, you can get lots of ways. You can read things on Smashing Magazine, you can watch video tutorials. Here there’s lots of ways to get this information. Both Vitaly and I are incredibly prolific in all this output that we do in sharing. But actually, what people tend to put on their feedback forms and stuff, from in-person workshops is, they got their questions answered. They were able to spend time talking to the person leading the workshop or with each other as well, with the other attendees, and have questions answered. That kind of interactivity was important. And so that was the thing we wanted to bring.

Rachel: And so, during the workshop there’s a few ways we’re doing that. There is a chat in Zoom itself, so people can chat while the workshop’s going on. So they do that and they introduce each other over and talk about where they are and what time it is because we’ve got people from all over the world. So that’s going on. Both of us had Google Docs open, which anyone could edit. And we tend to do that actually at Smashingconf, anyway, have these collaborative docs that people… people do amazing things. They completely live blog the entire event and put all the resources and so on. So we had those, and it was really interesting to see the attendees, which they would put the questions in there.

Rachel: And they would so much help each other out. Someone would write a question that I hadn’t got to, and someone else would have answered it, and people were clarifying things, and putting links to code pins in. And so, that was really interesting, that there was this collaboration going on while I was teaching. This sort of with other people. And I inadvertently had the same experience, people were helping each other out in terms of making comments and so on. So I think that that was the thing that it did feel like an interaction. It didn’t feel… so I’ve done a lot of presenting online where you just feel like you shout at your computer for an hour and then go away, and you’ve got no idea if anyone enjoyed it. It’s like, all right, there we go. I’ll go and I’ll drink now. But this actually felt like I was with people as an instructor, and the feedback… people were saying, it felt very intimate and that they were talking to me rather than just having something presented at them. Yeah, so that was interesting.

Drew: I guess as you say, the danger of running a workshop online is that it just becomes impersonal and the experience becomes more of a passive one for attendees. Is there anything that you can do in the way that you structure the content that you’re actually teaching?

Rachel: Yes.

Drew: Or the way that you conduct it to encourage people to interact and to participate with the tools that have been provided?

Rachel: Yeah, and I think Vitaly does a lot more of that because he has more… some of our other instructors are going to have more group activities. I teach in person, very much classroom style. My courses are pretty much a brain dump of here’s the stuff I know about CSS, here it is with lots of examples. And I have people coding with me all day, when we do them, but I’m not so much a group activities thing. It’s hard to do a group activity on Here’s the Basics of Grid Layout. So I’ve just found that teaching classroom style works quite well. Whereas I know that Vitaly actually had people breaking off into groups and doing activities, and actually meeting up with some of these people from all over the world who are participating. And so, that’s really quite fun because I think people do get a lot from that, from just the meeting of the people who do their job. Particularly, if you were mostly on your own, to actually get chance to do an activity with other people is quite a nice thing too.

Drew: Is there anything special that’s been done to give the online events something of the feel of the brand, in the same way that you would in an in-person event? I know attending a Smashing event, it always feels like a Smashing event. There’s something of the brand that’s communicated in the way that everything’s done. Is there anything that can be done online to help communicate that same feel?

Rachel: I think it’s difficult, but I think part of it is the attitude that generally smashing has. We’re very friendly and try and be as approachable and sort of informal as it were. So people feel like they’re coming to something which is going to be fun and entertaining. Things like Vitaly was online before my workshop playing a load of music and so on, just because that’s the sort of thing we do at Smashing. We like to entertain people and have some fun. So I think, yeah… I think trying to bring some of that fun that we do have at the live events as much as you can with a virtual thing. I think that’s what we’re trying to do. We’re trying to make it feel like a Smashing thing as much as we can.

Drew: Of course, you mentioned that there are many people who can’t or aren’t willing to travel to in-person events anyway. There must be a lot of advantages, even for those who would normally attend an in-person event. There’s got to be advantages to actually attending a workshop from the comfort of your own desk with your own set up around you.

Rachel: I think definitely. I think that is something a few people mentioned, that it was just nice to be… have the whole set up. Because if you’re a developer working at home, you’ve probably got two screens, and you’ve got your comfortable keyboard and your chair. And certainly for my software workshop where people are coding the whole time, to actually be able to have the presentation on one screen and have your code in front of you. And not be working on a tiny laptop, squashed in with a load of other people, and on an uncomfortable chair for the day. There’s a lot of benefits to that. So I think there are some quite nice things. You obviously, don’t get all the sides. If you don’t get to go off with your new friends and have a drink and have a chat about it all. And there’s things that you do lose by doing this virtually, but there is an awful lot to be said for it as an experience.

Drew: One thing that I’ve seen done quite a lot in the past with online events, is to try and create a bit of a sense of community by having local hubs, even though it’s a distributed global event. Obviously, that’s not something that we can even do at the moment because everybody’s confined to their own home, more or less. Is there anything else that can be done to create that sense of community, do you think? Is there anything that’s Smashing has thought about to try?

Rachel: Yeah. I think it’d be interesting to see where this plays out and whether this becomes a temporary thing, or whether that’s something that we can just carry on doing. I think that… and it would be interesting to see how we can link people up. We also have the Slack channels, so people chat in there. And I think really it’s just trying to… and we know a lot of friendships are made and also work relationships are made, people get new jobs and so on, from coming along to things like a Smashingconf. It’d be nice to try and encourage that sort of… that it’s not just where we do this and then go away afterwards, but that we can carry on the conversations and so on. That people are making and there’s something very nice to be said as well about… we have people from all over the world in my workshop. And that’s pretty cool that all those people were able to get together and spend some time learning.

Rachel: So yeah, I think that there’s all sorts of possibilities for this. We obviously, kicked it all off in a bit of a rush like, let’s just do it and see what happens. But I say, Vitaly and myself, we sold out. There was a lot of interest, and the other tickets are selling really well. So there’s obviously a need for this, and whether it is just now or whether it’s going to be something that we carry on doing, see what people think.

Drew: Being delivered digitally, there’s the fact that a workshop can actually be recorded and then replayed by participants later to go back over everything they’ve missed. Is that something that Smashing is taking advantage of?

Rachel: Yep. Everyone gets copy of the recording, and also we’ve been asked to add to that. At the moment, we haven’t got live captions going during the workshops. That’s something we’re hoping to fix. We’re hoping to actually be able to get the captions in real time. At the moment we’re not doing that, but we are getting them transcribed after the event. So when they get the video, they also have a transcript of the stuff, which is great. It might help, particularly if people are struggling with accents, so what have you. So that’s quite good. And then say, we’d like to look at getting them captioned as well, actually as they go out, with a live captioner, which would then be something that we don’t do in person. Not saying that we can easily do, and with workshops that we’re running live, but actually we can do online. So that would be, I think, a really helpful thing, and hopefully it would open it up to more people.

Drew: You mentioned as a presenter, things are quite different in the way that you actually present and you teach, where you’re just basically shouting it at a computer, hoping that there’s somebody there. I guess it’s quite different because you’re having to take care of all your own technology, your own setup, everything to make sure that you’re in a position ready to present online. How does that differ to how things would go normally if you were going to an event?

Rachel: In some ways it’s easier because I’m quite used to doing stuff online. I think it might be harder if you’re not well set up for recording stuff, I do quite a lot of video and things. So I’m reasonably well set up. But also, we’ve got our crew, we’ve got people online. I think that’s actually really important, is that if you’re presenting, the last thing you want to have to do is deal with someone who can’t get into Zoom or can’t hear the sound or can’t… just having some problem. So we have other members of the team, just like we do in person, have members of the team to help out if someone’s having trouble getting on the wifi or whatever it is. With the online workshops, we have people online to keep an eye on the chat and make sure that people aren’t struggling. And also to alert the presenter, if suddenly they drop offline or something… their sound’s gone weird or whatever it is.

Rachel: We’ve actually had no real technical issues like that, but there’s always that thought when you’re presenting online like, can people hear me? Am I just like talking to my screen and nothing’s happening out there? So having the team online with… or their contact details to be able to get hold of me, if suddenly I dropped off that. It makes you feel a lot more safe and that it’s okay.

Drew: Is there anything that you’ve changed about your setup in your home office to make online presenting easier? What does your set up look like there?

Rachel: Yeah, it’s getting ridiculous to be honest. It is just an excuse to buy things. So for the workshops, I’m coding, so I’m sitting down. When I’m doing more like presentations, I realized that it is just weird to present sitting down. And I don’t feel like I can actually do it very well. So I’ve got a standing desk, and so everything I have in… I’ve got some lighting and bits and pieces, but because I have things bolted to my desk. If I wanted to present standing up, I can just make the desk go up and everything goes with it and then I can present from my feet. And I did an online presentation for the BBC recently that was meant to be an offline in-person thing and got changed. And it felt so much better, being able to move around.

Rachel: And so, I’ve got my camera set up, so I can move about a bit, and I don’t feel like I’m just tied to the spot. And so, that sort of thing, I think, is really useful, being able to feel natural when you’re presenting and not just that you’re slumped in your chair and talking to a camera. And decent lighting I think is really important. I seem to spend an awful lot of time in Zoom calls now. And just people being well-lit is incredibly helpful. And I think, when you presenting or doing a workshop, people want to be able to see your face and your expressions and things, and having some decent lighting will help with that.

Drew: I’ve seen photos from, I think it was Val Head who posted her setup where she had a great big screen, and I think a couple of different computers and maybe an iPad or something as well. What does your technology set up look like there?

Rachel: So I’ve got two too, I’ve got my laptop and then my screen and because… so there’s the chat and things going on, which I don’t tend to take Q&A during, while I’m talking. I tend to deal with it at the end. But I can see the chat, and so I can see if… Sometimes I’ll pick up that someone’s got a very specific issue that I can just deal with at the time, and I might do that. So I’ve got that going on just in the peripheral vision. Because I’m coding, I’ve got the main stuff I’m doing and the screen it’s being output to the attendees is my main screen.

Rachel: I turn all my notes in when I do in person workshops as well. I turn all my notes into an e-pub, so I can have that on my iPad, which is handy because I can jump back and forth with the indexing and so on. So I have all the notes and the stuff to help me remember what I want to do next. But pretty much, and mossy of it’s run as I do in-person workshops. I work with a bunch of examples, basically that we work through, and I explained different things. And then, the attendees can take those examples away to help them remember what they did. So I pretty much do the same thing online. I think what I do probably moves online the easiest because teaching classroom style is quite an easy thing to move online. So you see, I’ve not changed too much. It’s just really making… getting comfortable with the setup so I don’t have to worry about that while I’m working.

Drew: Are there any bits of technology that you have in place that you think a really useful and really recommended for anyone who’s looking to do something similar?

Rachel: I think the lighting and decent mics and decent headsets and mics, so you’re not leaking sound over your ears. That sort of stuff is, I think, important. I like the headset mic rather than a mic on a stand because I’m writing code. I find that if I have a mic on a stand, I move away from it, back and forth all the time because I’m doing things. So having the headset mic means I haven’t got to get around a microphone that’s in front of my face. So that’s what I tend to use and that works quite well for me. So that was my main thing. I think, yeah, having a decent… You don’t have to spend a fortune, but having a good mic and headphones and some lighting, I think makes all the difference.

Drew: They often say, don’t they, that audio quality is more important than video quality when it comes to these things.

Rachel: Yeah. It’s just painful to listen to if you’ve got bad crackly audio.

Drew: So what have you learned so far in this journey? You say that you and Vitaly were the Guinea pigs for the approach. Is there anything key that you weren’t expecting that you’ve learned along the way?

Rachel: I think I’m surprised how intimate it felt and how connected it felt with the people who were attending. I hadn’t expected that at all. I’d expected it to be quite impersonal, and that we’d try very hard to make it feel personal but it would still be that kind of, Oh I’m presenting online now, I’m going away. I think having a good set amount of time for questions… I had half an hour for questions at the end of both of my days, and we used them. And I then went back to the Google doc and answered some stuff in there afterwards. So I think that really helped because people were able to ask their specific questions. I think the approach was splitting them up into multiple days. When we do these things in person, they are full day workshops. And we just figured that a full day for people to sit with a very long time to concentrate.

Rachel: And also it meant that we could put them into a time zone that worked for more people. Because if you’re not going to find a full day, if you’re saying well actually, it’s two or three hours, then more people in different time zones can attend that. So this workshop was my evening. So then it was like 9:00 AM on the West coast of the States, which meant the people on the East coast, the States and also people in the UK and stuff could attend. The next one I’m doing is going to be UK morning, which means that people in Asia and so on and in Australia, it’s not too far out of their day to be able to attend. So that kind of thing works quite well, spacing them up over multiple days. And I think it is easier for people because it’s a long time, a full day listening to someone on a screen. I think you’re probably going to start to zone out no matter how interesting they are.

Drew: And people have other responsibilities in their jobs, don’t they? The number of times that you see people at a in-person conference and they have to leave at the lunch break because they’re needed in the office, because there’s things that have to be done. Life doesn’t stop just because you’ve got a day’s worth of training planned.

Rachel: Yeah, and I think here, and in the current situation as well. A lot of people are working from home and are having to do childcare or home educate their kids. So particularly in the current environment, I think asking both presenters and attendees to be able to block out two and a half, three hours is probably a lot easier for people than be able to block out a full day. Because if you’ve got young children at home, even if you’ve got a partner there, you’re basically saying, you’ve got to be all locked out of this room for nine hours today. That’s a lot. So I think actually, having those shorter sessions is, for a lot of reasons, is probably a good thing.

Drew: If other event organizers are thinking about doing the same with their events, they’re looking at their schedule ahead, seeing all their in person events being canceled, and thinking they’d really need to do something to keep everything ticking over. What should they be taking into consideration before embarking on moving their events online?

Rachel: I think to realize that it’s doable and that people are interested and will pay for this sort of thing. I think getting the tech in place and testing it is important. Having a team to back people up is really important, even if they don’t need to do very much, they’re just sitting there watching the output. It makes you feel a lot more confident as a presenter, knowing that that’s happening. So that I would say is, is important. And really just thinking about the ways in which you can make this seem not like a second class way of learning. It’s a different way of learning, but it doesn’t need to be a lesser way. And rather than being apologetic and saying, Oh, we’re really sorry we can’t do an event, but we’re going to do this. Say, No, hey, this is going to be a really great way for us all to get together and learn something and spend some time with other people, not just in our own four walls.

Rachel: And it’s just a different thing. And I think this is quite an exciting thing that we’re learning how to do. And it’s made us all at Smashing feel so much happier because it could have been quite depressing, losing the conferences. It’s when we were all… we were a little team and we love spending time together as well. We were all so excited to be going to San Francisco and seeing each other and doing the conference. But instead of feeling like we’ve lost that, we actually feel like we’re doing a really great thing and sharing knowledge with our Smashing community. And it’s been really nice. I think it feels like we’re moving forward.

Drew: So the Smashing online workshops are running throughout April, May, and June. And you mentioned some of the great speakers who are lined up for those. And listeners can find out about those and the rescheduled Smashingconfs that are coming to a city near you. Again, smashingmagazine.com/events. So I’ve been learning about online workshops. What have you been learning about lately?

Rachel: I’ve actually been learning the mandolin. I keep meaning to learn the mandolin, and it’s been like, well I’m stuck in the house, so might as well. So I’ve been doing that. That’s been good. I’m terrible. Absolute terrible. But it’s something nice to be doing. I’ve always been learning about gardening because I had a mud pit outside and I thought I might try and turn it into some sort of garden. So that’s what I’ve been doing to get away from the computer a little bit, so I’m not just sat here staring at this all day.

Drew: If you, the listener, would like to hear more from Rachel, you can follow her on Twitter, where she’s at Rachel Andrew. And find all of her writing, speaking, online training, and excellent CSS layout news email newsletter linked from my site at RachelAndrew.coderUK.

Drew: Thanks for joining us today, Rachel. Do you have any parting words?

Rachel: Just to say that, keep on enjoying learning stuff while we’re in this weird situation, but also don’t stress if you’re feeling like you really can’t do anything today because it is weird. Well, none of us were expecting this sort of thing to be happening, and it’s okay to feel not great and not want to learn and not be productive for a while too.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

laurakalbag-300x300-1
07 Apr

Smashing Podcast Episode 13 With Laura Kalbag: What Is Online Privacy?

by TBSCategories: News

Smashing Podcast Episode 13 With Laura Kalbag: What Is Online Privacy?

Smashing Podcast Episode 13 With Laura Kalbag: What Is Online Privacy?

Drew McLellan

Laura KalbagIn this episode of the Smashing Podcast, we’re talking about online privacy. What should web developers be doing to make sure the privacy of our users is maintained? I spoke to Laura Kalbag to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s a designer from the UK, but now based in Ireland, she’s co-founder of the Small Technology Foundation. You’ll often find her talking about rights-respecting design, accessibility and inclusivity, privacy, and web design and development, both on her personal website and with publications such as Smashing magazine. She’s the author of the book Accessibility for Everyone from A Book Apart. And with the Small Technology Foundation, she’s part of the team behind Better Blocker, a tracking blocker tool for Safari on iOS and Mac. So we know she’s an expert in inclusive design and online privacy, but did you know she took Paris Fashion Week by storm wearing a kilt made out of spaghetti. My Smashing friends, please welcome Laura Kalbag.

Laura Kalbag: Hello.

Drew: Hello Laura, how are you?

Laura: I am smashing.

Drew: I wanted to talk to you today about the topic of online privacy and the challenges around being an active participant online without seeding too much of your privacy and personal data to companies who may or may not be trustworthy. This is an area that you think about a lot, isn’t it?

Laura: Yeah. And I don’t just think about the role of us as consumers in that, but also as people who work on the web, our role in actually doing it and how much we’re actually making that a problem for the rest of society as well.

Drew: As a web developer growing up in the ‘90s as I did, for me maintaining an active presence online involved basically building and updating my own website. Essentially, it was distributed technology but it was under my control. And these days it seems like it’s more about posting on centralized commercially operated platforms such as Twitter and Facebook, the obvious ones. That’s a really big shift in how we publish stuff online. Is it a problem?

Laura: Yeah. And I think we have gone far away from those decentralized distributed ways of posting on our own websites. And the problem is that we are essentially posting everything on somebody else’s website. And not only does that mean that we’re subject to their rules, which in some cases is a good thing, you don’t necessarily want to be on a website that is full of spam, full of trolls, full of Nazi content, we don’t want to be experiencing that. But also we have no control over whether we get kicked off, whether they decide to censor us in any way. But also everything underlying on that platform. So whether that platform is knowing where we are at all times because it’s picking up on our location. Whether it is reading our private messages because if it’s not end-to-end encrypted, if we’re sending direct messages to each other, that could be accessed by the company.

Laura: Whether it’s actively, so whether people working there could actually just read your messages. Or passively, where they are just sucking up the stuff from inside your messages and using that to build profiles about you, which they can then use to target you with ads and stuff like that. Or even combine that information with other datasets and sell that on to other people as well.

Drew: It can be quite terrifying, can’t it? Have what you considered to be a private message with somebody on a platform like Facebook, using Facebook Messenger, and find the things you’ve mentioned in a conversation then used to target ads towards you. It’s not something you think you’ve shared but it is something you’ve shared with the platform.

Laura: And I have a classic example of this that happened to me a few years ago. So, I was on Facebook, and my mom had just died, and I was getting ads for funeral directors. And I thought is was really strange because none of my family had said anything on a social media platform at that point, none of my family had said anything on Facebook because we’d agreed that no one wants to find out that kind of thing about a friend or family member via Facebook so we’d not say about it. And then, so I asked my siblings, “Have any of you said anything on Facebook that might cause this strange?” Because I just usually just get ads for make-up, and dresses, and pregnancy tests, and all those fun things they like to target women of a certain age. And my sister got back to me, she said, “Well, yeah, my friend lives in Australia so I sent her a message on Messenger, Facebook Messenger, and told her that our mom had died.”

Laura: And of course Facebook knew that we’re sisters, it has that relationship connection that you can choose to add on there, it could probably guess we were sisters anyway by the locations we’ve been together, the fact that we share a surname. And decided that’s an appropriate ad to put in her feed.

Drew: It’s sobering, isn’t it? To think that technology is making these decisions for us that actually affects people, potentially in this example, in quite a sensitive or vulnerable time.

Laura: Yeah. We say it’s creepy, but a lot of the time people say it’s almost like the microphone on my phone or my laptop was listening to me because I was just having this conversation about this particular product and suddenly it’s appearing in my feed everywhere. And I think what’s actually scary is the fact that most of them don’t have access to your microphone, but it’s the fact that your other behaviors, your search, the fact that it knows who you’re talking to because of your proximity to each other and your location on your devices. It can connect all of those things that we might not connect ourselves together in order to say, maybe they’ll be interested in this product because they’ll probably think you’re talking about it already.

Drew: And of course, it’s not as simple as just rolling back the clock and going back to a time where if you wanted to be online, you had to create your own website because there’s technical barriers to that, there’s cost barriers. And you only need to look at the explosion of things like sharing video online, there’s not an easy way to share a video online in the same way you can just by putting it on YouTube, or uploading it to Facebook, or onto Twitter, there are technical challenges there.

Laura: It’s not fair to blame anyone for it because using the web today and using these platforms today is part of participating in society. You can’t help it if your school has a Facebook group for all the parents. You can’t help it if you have to use a website that, in order to get some vital information. It’s part of our infrastructure now, particularly nowadays when everyone is suddenly relying video calling and things like that so much more. These are our infrastructure, they are as used and as important as our roads, as our utilities, so we need to have them treated accordingly. And we can’t blame people for using them, especially if there aren’t any alternatives that are better.

Drew: When the suggestion is using these big platforms that it’s easy and it’s free, but is it free?

Laura: No, because you’re paying with your personal information. And I hear a lot of developers saying things like, “Oh well, I’m not interesting, I don’t really care, it’s not really a problem for me.” And we have to think about the fact that we’re often in quite a privileged group. What about people that are more vulnerable? We think about people who have parts of their identity that they don’t necessarily want to share publicly, they don’t want to be outed by platforms to their employers, to their government. People who are in domestic abuse situations, we think about people who are scared of their governments and don’t want to spied on. That’s a huge number of people across the world, we can’t just say, “Oh well, it’s fine for me, so it has to be fine for everybody else,” it’s just not fair.

Drew: It doesn’t have to be a very big issue you’re trying to conceal from the world to be worried about what a platform might share about you.

Laura: Yeah. And the whole thing about privacy is that it isn’t about having something to hide, it’s about choosing what you want to share. So you might not feel like you have anything in particular that you want to hide, but it doesn’t necessarily mean you put a camera in your bedroom and broadcast it 24 hours, there’s things we do and don’t want to share.

Drew: Because there are risks as well in sharing social content, things like pictures of family and friends. That we could be sacrificing other peoples privacy without them really being aware, is that a risk?

Laura: Yeah. And I think that that applies to a lot of different things as well. So it’s not just if you’re uploading things of people you know and then they’re being added to facial recognition databases, which is happening quite a lot of the time. These very dodgy databases, they’ll scrape social media sites to make their facial recognition databases. So Clearview is an example of a company that’s done that, they’ve scraped images off Facebook and used those. But also things like email, you might choose… I’m not going to use Gmail because I don’t want Google to have access to everything in my email, which is everything I’ve signed up for, every event I’m attending, all of my personal communication, so I decide not to use it. But if I’m communicating with someone who uses Gmail, well, they’ve made that decision on my behalf, that everything I email them will be shared with Google.

Drew: You say that, often from a privileged position, we think okay, we’re getting all this technology, all these platforms are being given to us for free, we’re not having to pay for it, all we got to do is… We’re giving up a little bit of privacy, but that’s okay, that’s an acceptable trade-off. But is it an acceptable trade-off?

Laura: No. It’s certainly not an acceptable trade-off. But I think it’s also because you don’t necessarily immediately see the harms that are caused by giving these things up. You might feel like you’re in a safe situation today, but you may not be tomorrow. I think a good example is Facebook, they’ve actually got a pattern for approving or disproving loans based on the financial status of your friends on Facebook. So thinking, oh well, if your friend owes lots of money, and a lot of your friends owes lots of money, you’re more likely to be in that same situation as them. So all these systems, all of these algorithms, they are making decisions and influencing our lives and we have no say on them. So it’s not necessarily about what we’re choosing to share and what we’re choosing not to share in terms of something we put in a status, or a photo, or a video, but it’s also about all of this information that is derived about us from our activity on these platforms.

Laura: Things about our locations or whether we have a tendency to be out late at night, the kinds of people that we tend to spend our time with, all of this information can be collected by these platforms too and then they’ll make decisions about us based on that information. And we not only don’t have access to what’s being derived about us, we have no way of seeing it, we have no way of changing it, we have no way of removing it, bar a few things that we could do if we’re in the EU based on GDPR, if you’re in California based on their regulation there that you can go in and ask companies what data they have on you and ask them to delete it. But then what data counts under that situation? Just the data they’ve collected about you? What about the data they’ve derived and created by combining your information with other people’s information and the categories they’ve put you in, things like that. We have no transparency on that information.

Drew: People might say that this is paranoia, this is tinfoil hat stuff. And really all that these companies are doing is collecting data to show us different ads. And okay, there’s the potential for these other things, but they’re not actually doing that. All they’re doing is just tailoring ads to us. Is that the case or is this data actually actively being used in more malicious ways than just showing ads?

Laura: No. We’ve seen in many, many occasions how this information is being used in ways other than just ads. And even if one company decides to just collect it based on ads, they then later might get sold to or acquired by an organization that decides to do something different with that data and that’s parts of the problem with collecting the data at all in the first place. And it’s also a big risk to things like hacking, if you’re creating a big centralized database with people’s information, their phone numbers, their email addresses, even just the most simple stuff, that’s really juicy data for hackers. And that’s why we see massive scale hacks that result in a lot of people’s personal information ending up being publicly available. It’s because a company decided it was a good idea to collect of that information in one place in the first place.

Drew: Are there ways then that we can use these platforms, interact with friends and family that are also on these platforms, Facebook is the obvious example where you might have friends and family all over the world and Facebook is the place where they communicate. Are there ways that you can participate in that and not be giving up privacy or is it just something that if you want to be on that platform, you just have to accept?

Laura: I think there’s different layers, depending on what we would call your threat model is. So depending how vulnerable you are, but also your friends and family, and what your options are. So yeah, the ultimate thing is to not use these platforms at all. But if you do, try to use them more than they use you. So if you have things that you’re communicating one-on-one, don’t use Messenger for that because there are plenty of alternatives for one-on-one direct communication that can be end-to-end encrypted or is private and you don’t have to worry about Facebook listening in on it. And there’s not really much you can do about things like sharing your location data and stuff like that, which is really valuable information. It’s all of your meta information that’s so valuable, it’s not even necessarily the content of what you’re saying, but who you’re with and where you are when you’re saying it. That’s the kind of stuff that’s useful that companies would use to put you in different categories and be able to sell things to you accordingly or group you accordingly.

Laura: So I think we can try to use them as little as possible. I think it’s important to seek alternatives, particularly if you’re a person who is more technically savvy in your group of friends and family, you can always encourage other people to join other things as well to have. So use Wire for messaging, that’s a nice little platform that’s available in lots of places and is private. Or Signal is another option that’s just like WhatsApp but it’s end-to-end encrypted as well. And if you can be that person, I think there’s two points that we have to really forget about. One, is the idea that everyone needs to be on a platform for it to be valuable. The benefit is that everyone’s on Facebook, that’s actually the downside as well, that everyone’s on Facebook. You don’t need everyone you know to suddenly be on the same platform as you. As long as you have those few people you want to communicate with regularly on a better platform, that’s a really good start.

Laura: And the other thing that we need to embrace, we’re not going to find an alternative to a particular platform that does everything that platform does as well. You’re not going to find an alternative to Facebook that does messaging, that has status updates, that has groups, that has events, that has live, that has all of this stuff. Because the reason Facebook can do that is because Facebook is massive, Facebook has these resources, Facebook has a business model that really makes a lot out of all that data and so it’s really beneficial to provide all those services to you. And so we have to change our expectations and maybe be like, “Well okay, what’s the one function I need? To be able to share a photo. Well, let’s find the thing that I can do that will help me just share that photo.” And not be expecting just another great big company to do the right thing for us.

Drew: Is this something that RSS can help us with? I tend to think RSS is the solution to most problems, but I was thinking here if you have a service for photo sharing, and something else for status updates, and something else for all these different things is RSS the solution that brings it all together to create a virtual… That encompasses all these services?

Laura: I’m with you on that for lots of things. I, myself, I’ve built into my own site, I have a section for photos, a section for status updates, as well as my blog and stuff. So that I can allow people to, if they don’t follow me on social media platforms, if I’m posting the same stuff to my site, they can use RSS to access it and they’re not putting themselves at risk. And that’s one of the ways that I see as just a fairly ordinary designer/developer that I can not force other people to use those platforms in order to join in with me. And RSS is really good for that. RSS can have tracking, I think people can do stuff with it, but it’s rare and it’s not the point of it. That’s what I think RSS is a really good standard for.

Drew: As a web developer, I’m aware when I’m building sites that I’m frequently being required to add JavaScript from Google for things like analytics or ads, and from Facebook for like and share actions, and all that sort of thing, and from various other places, Twitter, and you name it. Are those something that we need to worry about in terms of developers or as users of the web? That there’s this code executing that it’s origin is on google.com or facebook.com?

Laura: Yes. Absolutely. I think Google is a good example here of things like web fonts and libraries and stuff like that. So people are encouraged to use them because they’re told well, it’s going to very performant, it’s on Google servers, Google will grab it from the closest part of the world, you’ll have a brilliant site just by using, say a font off Google rather than embedding it, self-hosting it on your own site. There’s a reason why Google offers up all of those fonts for free and it’s not out of the goodness of their Googley little hearts, it is because they get something out of it. And what they get is, they get access to your visitors on your website when you include their script on your website. So I think it’s not just something we should be worried about as developers, I think that it’s our responsibility to know what our site is doing and know what a third party script is doing or could do, because they could change it and you don’t necessarily have control over that as well. Know what their privacy policies are and things like that before we use them.

Laura: And ideally, don’t use them at all. If we can self-host things, self-host things, a lot of the time it’s easier. If we don’t need to provide a login with Google or Facebook, don’t do it. I think we can be the gatekeepers in this situation. We as the people who have the knowledge and the skills in this area, we can be the ones that can go back to our bosses or our managers and say, “Look, we can provide this login with Facebook or we could build our own login, it will be private, it would be safer. Yeah, it might take a little bit more work but actually we’ll be able to instill more trust in what we’re building because we don’t have that association with Facebook.” Because what we’re seeing now, over time, is that even mainstream media is starting to catch up with the downsides of Facebook, and Google, and these other organizations.

Laura: And so we end up being guilty by association even if we’re just trying to make the user experience easier by adding a login where someone doesn’t have to create a new username and password. And so I think we really do need to take that responsibility and a lot of it is about valuing people’s rights and respecting their rights and their privacy over our own convenience. Because of course it’s going to be much quicker just to add that script to the page, just to add another package in without investigating what it actually does. We’re giving up a lot when we do that and I think that we need to take responsibility not to.

Drew: As web developers are there other things that we should be looking out for when it comes to protecting the privacy of our own customers in the things that we build?

Laura: We shouldn’t be collecting data at all. And I think most of the time, you can avoid it. Analytics is one of my biggest bugbears because I think that a lot of people get all these analytics scripts, all these scripts that can see what people are doing on your website and give you insights and things like that, but I don’t think we use them particularly well. I think we use them to confirm our own assumptions and all we’re being taught about is what is already on our site. It’s not telling us anything that research and actually talking to people who use our websites… We could really benefit more from that than just looking at some numbers go up and down, and guessing what the effect of that is or why it’s happening. So I think that we need to be more cautious around anything that we’re putting on our sites and anything that we’re collecting. And I think nowadays we’re also looking at regulatory and legal risks as well when we’re starting to collect people’s data.

Laura: Because when we look at things like the GDPR, we’re very restricted in what we are allowed to collect and the reasons why we’re allowed to collect it. And that’s why we’re getting all of these consent notifications and things like that coming up now. Because companies have to have your explicit consent for collecting any data that is not associated with vital function for the website. So if you’re using something like a login, you don’t need to get permission to store someone’s email and password for a login because that is implied by logging in, you need that. But things like analytics and stuff like that, you actually need to get explicit consent in order to be able to spy on the people visiting the website. So this is why we see all of these consent boxes, this is why we should actually be including them on our websites if we’re using analytics and other tools that are collecting data that aren’t vital to the functioning of the page.

Drew: I think about some of even just the side projects and things that I’ve launched, that just almost as a matter of routine I’ve put Google analytics on there. I think, “Oh, I need to track how many people are visiting.” And then I either never look at it or I only look at it to gain an understanding of the same things that I could’ve just got from server logs like we used to do in the old days, just by crunching over their web access logs.

Laura: Exactly. And yet Google is sitting there going, “Thank you very much.” Because you’ve instilled another input for them on the website. And I think once you start thinking about it, once you adjust your brain to taking this other way of looking at it, it’s much easier to start seeing the vulnerabilities. But we do have to train ourselves to think in that way, to think about how can we harm people with what we’re building, who could lose out from this, and try to build things that are a bit more considerate of people.

Drew: There’s an example, actually, that I can think of where Google analytics itself was used to breach somebody’s privacy. And that was the author of Belle de Jour, The Secret Diary of a Call Girl, who was a London call girl who kept a blog for years and it was all completely anonymous. And she diarized her daily life. And it was incredibly successful, and it became a book, and a TV series, and what have you. She was intending to be completely anonymous, but she was eventually found out. Her identity was revealed because she used the same Google analytics tracking user id on her personal blog where she was her professional self and on the call girl blog as well. And that’s how she was identified, just-

Laura: So she did it to herself in that way as well.

Drew: She did it to herself. Yeah. She leaked personal data there that she didn’t mean to leak. She didn’t even know it was personal data, I suspect. There are so many implications that you just don’t think of. And so I think it pays to start thinking of it.

Laura: Yeah. And not doing things because you feel that that’s what we always did, and that’s what we always do, or that’s what this other organization that I admire, they do it, so I should, I think. And a lot of the time it is about being a bit more restrictive and maybe not jumping on the bandwagon of I’m going to use this service like everybody else is. And stopping, reading their privacy policy, which is not something I recommend doing for fun, because it’s really tedious, and I have to do a lot of it when I’m looking into trackers for Better. But you can see a lot of red flags if you read privacy policies. You see the kinds of language that means that they’re trying to make it free and easy for them to do whatever they want with your information. And there’s a reason why I say to designers and developers, if you’re making your own projects, don’t just copy the privacy policy from somebody else. Because you might be opening yourself up to more issues and you might actually be making yourself look suspicious.

Laura: It’s much better to be transparent and clear about what you’re doing, everything doesn’t need to be written in legal ease in order for you to be clear about what you’re doing with people’s information.

Drew: So, in almost anything, people say that the solution to it is to use the JAMstack. Is the JAMstack a solution, is it a good answer, is it going to help us out of accidentally breaching the privacy of our customers?

Laura: There’s a lot of stuff I like about the JAMstack stuff, but I would say I like the “JMstack”, because it’s the APIs bit that worries me. Because if we’re taking control over our own sites, we’re building static sites, and we’re generating it all on our machines, and we’re not using servers, and that’s great that we’ve taken away a lot potential issues there. But then if we’re adding back in all of the third party functionality using APIs, we may as well be adding script tags to our pages all over again. We may as well have it on somebody else’s platform. Because we’re losing that control again. Because every time we’re adding something from a third party, we’re losing control over a little bit of our site. So I think that a lot of static site generators and things like that have a lot of value, but we still need to be cautious.

Laura: And I think one of the reasons why we love the jam stack stuff because again, it’s allowed us to knock up a site really quickly, deploy it really quickly, have a development environment set up really quickly, and we’re valuing again, our developer experience over that of the people that are using the websites.

Drew: So I guess the key there is to just be hyperaware of what every API you’re using is doing. What data you could be sending to them, what their individual privacy policies are.

Laura: Yeah. And I think we have to be cautious about being loyal to companies. We might have people that we are friends with and think are great and things like that, that are working for these companies. We might that they are producing some good work, they’re doing good blogs, they’re introducing some interesting new technologies into the world. But at the end of the day, businesses are businesses. And they all have business models. And we have to know what are their business models. How are they making their money? Who is behind the money? Because a lot of venture capital backed organizations end up having to deal in personal data, and profiling, and things like that, because it’s an easy way to make money. And it is hard to build a sustainable business on technology, particularly if you’re not selling a physical product, it’s really hard to make a business sustainable. And if an organization has taken a huge amount of money and they’re paying a huge amount of employees, they’ve got to make some money back somehow.

Laura: And that’s what we’re seeing now is, so many businesses doing what Shoshana Zuboff refers to as surveillance capitalism, tracking people, profiling them, and monetizing that information because it’s the easiest way to make money on the web. And I think that the rest of us have to try to resist it because it can be very tempting to jump in and do what everyone else is doing and make big money, and make a big name. But I think that we’re realizing too slowly the impact that that has on the rest of our society. The fact that Cambridge Analytica only came about because Facebook was collecting massive amounts of people’s information and Cambridge Analytica was just using that information in order to target people with, essentially, propaganda in order to make referendums and elections of their way. And that’s terrifying, that’s a really scary effect that’s come out of what you might think is an innocuous little banner ad.

Drew: Professionally, many people are transitioning into building client sites or helping their clients to build their own sites on platforms like Squarespace and that sort of thing, online site builders where sites are then completely hosted on that service. Is that an area that they should also be worried about in terms of privacy?

Laura: Yeah. Because you’re very much subject to the privacy policies of those platforms. And while a lot of them are paid platforms, so just because it’s a platform doesn’t necessarily mean that they are tracking you. But the inverse is also true, just because you’re paying for it, doesn’t mean they’re not tracking you. I’d use Spotify as an example of this. People pay Spotify a lot of money for their accounts. And Spotify does that brilliant thing where it shows off how much it’s tracking you by telling people all of this incredible information about them on a yearly basis, and giving them playlists for their moods, and things like that. And then you realize, oh, actually, Spotify knows what my mood is because I’m listening to a playlist that’s made for this mood that I’m in. And Spotify is with me when I’m exercising. And Spotify knows when I’m working. And Spotify knows when I’m trying to sleep. And whatever other playlists you’ve set up for it, whatever other activities you’ve done.

Laura: So I think we just have to look at everything that a business is doing in order to work out whether it’s a threat to us and really treat everything as though it could possibly cause harm to us, and use it carefully.

Drew: You’ve got a fantastic personal website where you collate all the things that you’re working on and things that you share socially. I see that your site is built using Site.js. What’s that?

Laura: Yes. So it’s something that we’ve been building. So what we do at the Small Technology Foundation, or what we did when we were called Ind.ie, which was the UK version of the Small Technology Foundation, is that we’re tying to work on how do we help in this situation. How do we help in a world where technology is not respecting people’s rights? And we’re a couple of designers and developers, so what is our skills? And the way we see it is we have to do a few different things. We have to first of all, prevent some of the worst harms if we can. And one of the ways we do that is having a tracker blocker, so it’s something that blocks trackers on the web, with their browser. And another thing we do is, we try to help inform things like regulation, and we campaign for better regulation and well informed regulation that is not encouraging authoritarian governments and is trying to restrict businesses from collecting people’s personal information.

Laura: And the other thing we can do is, we can try to build alternatives. Because one of the biggest problems with technology and with the web today is that there’s not actually much choice when you want to build something. A lot of things are built in the same way. And we’ve been looking at different ways of doing this for quite a few years now. And the idea behind Site.js is to make it really easy to build and deploy a personal website that is secure, has the all the HTTPS stuff going on and everything, really, really, easily. So it’s something that really benefits the developer experience, but doesn’t threaten the visitor’s experience at the same time. So it’s something that is also going to keep being rights respecting, that you have full ownership and control over as the developer of your own personal website as well. And so that’s what Site.js does.

Laura: So we’re just working on ways for people to build personal websites with the idea that in the future, hopefully those websites will also be able to communicate easily with each other. So you could use them to communicate with each other and it’s all in your own space as well.

Drew: You’ve put a lot of your expertise in this area to use with Better Blocker. You must see some fairly wild things going on there as you’re updating it and…

Laura: Yeah. You can always tell when I’m working on Better because that’s when my tweets get particularly angry and cross, because it makes me so irritated when I see what’s going on. And it also really annoys me because I spend a lot of time looking at websites, and working out what the scripts are doing, and what happens when something is blocked. One of the things that really annoys me is how developers don’t have fallbacks in their code. And so the amount of times that if you block something, for example, I block an analytics script, and if you block an analytics script, all the links stop working on the webpage, then you’re probably not using the web properly if you need JavaScript to use a link. And so I wish that developers bear that in mind, especially when they think about maybe removing these scripts from their sites. But the stuff I see is they…

Laura: I’ve seen, like The Sun tabloid newspaper, everybody hates it, it’s awful. They have about 30 different analytics scripts on every page load. And to some degree I wonder whether performance would be such a hot topic in the industry if we weren’t all sticking so much junk on our webpages all the time. Because, actually, you look at a website that doesn’t have a bunch of third party tracking scripts on, tends to load quite quickly. Because you’ve got to do a huge amount to make a webpage heavy if you haven’t got all of that stuff as well.

Drew: So is it a good idea for people who build for the web to be running things like tracker blockers and ad blockers or might it change our experience of the web and cause problems from a developer point of view?

Laura: I think in the same way that we test things across different browsers and we might have a browser that we use for our own consumer style, I hate the word consumer, use, just our own personal use, like our shopping and our social stuff, and things like that. And we wouldn’t only test webpages in that browser, we test webpages in as many browsers can get our hands on because that’s what makes us good developers. And I think the same should be for if you’re using a tracker blocker or an ad blocker in your day-to-day, then yeah, you should try it without as well. Like I keep Google Chrome on my computer for browser testing, but you can be sure that I will not be using that browser for any of my personal stuff, ever, it’s horrible. So yeah, you’ve got to be aware of what’s going in the world around you as part of your responsibility as a developer.

Drew: It’s almost just like another browser combination, isn’t it? To be aware of the configurations that the audience your site or your product might have and then testing with those configurations to find any problems.

Laura: Yeah. And also developing more robust ways of writing your code, so that your code can work without certain scripts and things like that. So not everything is hinging off one particular script unless it is absolutely necessary. Things completely fall apart when people are using third party CDNs, for example. I think that’s a really interesting thing that so many people decided to use a third party CDN, but you have very little control over it’s uptime and stuff like that. And if you block the third party CDN, what happens? Suddenly you have no images, no content, no videos, or do you have no functionality because all of your functional JavaScript is coming from a third party CND?

Drew: As a web developer or designer, if I’d not really thought about privacy concerns about the sites I’m producing up until this point, if I wanted to make a start, what should be the first thing that I do to look at the potential things I’m exposing my customers to?

Laura: I’d review one of your existing pages or one of your existing sites. And you can take it on a component by component basis even. I think any small step is better than no step. And it’s the same way you’d approach learning anything new. It’s the same way I think about accessibility as well. Is you start by, okay, what is one thing I can take away? What is one thing I can change that will make a difference? And then you start building up that way of thinking, that way of looking at how you’re doing your work. And eventually that will build up into being much more well informed about things.

Drew: So I’ve been learning a lot about online privacy. What have you been learning about lately?

Laura: One of the things I’ve been learning about is Hugo, which is a static site generator that is written using Go. And I use it for my personal site already, but right now for Site.js, I’ve been writing a starter blog theme so that people could just set up a site really easily and don’t necessarily have to know a lot about Hugo. Because Hugo is interesting, it’s very fast, but the templating is quite tricky and the documentation is not the most accessible. And so I’m trying to work my way through that to understand it better, which I think I finally got over the initial hurdle. Where I understand what I’m doing now and I can make it better. But it’s hard learning these stuff, isn’t it?

Drew: It really is.

Laura: It reminds you how inadequate you are sometimes.

Drew: If you, dear listener, would like to hear more from Laura, you can find her on the web at laurakalbag.com and Small Technology Foundation at small-tech.org. Thanks for joining us today, Laura. Do you any parting words?

Laura: I’d say, I think we should always just be examining what we’re doing and our responsibility in the work that we do. And what can we do that can make things better for people? And what we can do to make things slightly less bad for people as well.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
paul-boag-300x300-1
24 Mar

Smashing Podcast Episode 12 With Paul Boag: What Is Conversion Optimisation?

by TBSCategories: News

Smashing Podcast Episode 12 With Paul Boag: What Is Conversion Optimisation?

Smashing Podcast Episode 12 With Paul Boag: What Is Conversion Optimisation?

Drew McLellan

Paul BoagIn this episode of the Smashing Podcast, we’re talking about the user experience around converting site visitors into customers. Can our selling techniques leave customers feeling cheated? And how can that be avoided? I spoke to conversion optimisation specialist Paul Boag to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s a user experience consultant, digital transformation expert, and conversion rate optimization specialist hailing from the southwest of the UK. He is the author of many books, including User Experience Revolution from Smashing Magazine, and the forthcoming title Click! How to Encourage Clicks Without Shady Tricks. He’s also a veteran web design podcaster with a show running more or less weekly for 15 years. So we know he’s an expert at user experience design, but did you know he’s also the world authority on papier-mache? My Smashing friends, please welcome Paul Boag. Hi, Paul. How are you?

Paul Boag: Oh, I’m smashing, apparently.

Drew: So we’re in the middle of a global pandemic.

Paul: Yeah, and you’ve just made me say I’m feeling smashing in the middle of a pandemic. That’s great. Thanks.

Drew: What I want to know is, what’s on your shopping list?

Paul: Oh, dear. Do you know, this pandemic has changed very little in my life. Social distancing, I’ve been doing that for 18 years. I’ve worked from home for 18 years. We homeschooled our son. My wife works from home. Nothing has changed in my life. In fact, if anything, I’m now more sociable because everybody’s creating these WhatsApp groups and things, where, “Oh, let’s all pull together as a community.” So I’m having to talk to people now. It’s just dreadful, dreadful time.

Drew: Oh, wow. I’ll tell you what’s on my shopping list.

Paul: Oh, yeah.

Drew: It’s a new book of yours.

Paul: Oh. That was smooth, Drew. I’m super impressed by that.

Drew: It’s a heck of a title, How to Encourage Clicks Without Shady Tricks. Tell me about that.

Paul: Well, that wasn’t the original title that I wanted. Do you know this story?

Drew: No, I don’t know this story.

Paul: Oh, okay. I got vetoed by Vitaly.

Drew: Oh, dear.

Paul: Because I wanted to call it Encouraging Clicks Without Being a… But apparently, that’s not professional enough. So the basis of the book is that we all need to improve our conversion rate. Websites aren’t there, although we talk about being user-centric and user-focused, and all those things are entirely correct, but at the end of the day, websites have to create and return on investment for whoever owns them. And that’s entirely understandable and as it should be. But increasingly, people are under enormous pressure to improve their conversion rates. Marketers have got targets they’ve got to meet, designers are under pressure. And part of the problem is, in the early days when your website is rubbish, it was easy to increase your conversion rate.

Paul: And so as a result, then that set expectations, because the conversion rate went up quite a lot every year. And so management ended up expecting that to happen over the long term, and of course, it becomes harder and harder. So the result is that people are inevitably turning to dark patterns. Not because necessarily they want to, but because they’re under pressure to. They’re under pressure to bring about results.

Paul: So the premise of this book is, first of all, to explain why dark patterns are a bad idea. And not from an ethical point of view. I don’t feel I’m the kind of person that can preach on ethics. But I talk about it from a purely business point of view, that these are the business reasons why dark patterns are ultimately damaging. And then that inevitably leads to the question of, well, if dark patterns aren’t the answer, then what is? And that’s what the majority of the book is exploring, that, what you can do to improve your conversion rate without resorting to these kinds of more manipulative techniques. So I actually got really excited about this book. It’s been one of the most enjoyable ones to write, and I actually think it’s probably the most practical and tangible book for the biggest majority of people out of the ones I’ve written.

Drew: So in a previous episode of this podcast, I talked to Michael and Trina about their book on ethical design.

Paul: Yes.

Drew: Also from Smashing magazine.

Paul: Yeah.

Drew: I guess that makes your book a good complement to that one, if they’re looking at the ethics of it, and maybe your approach is slightly more from the practical and business side.

Paul: Absolutely, yeah.

Drew: And not just the ethics.

Paul: Yeah. And I was quite chuffed when I found out that my book would be following on from theirs. I felt that that was a really good relationship between the two. Because don’t get me wrong, I think the ethics of how we design online and the decisions that we make and those kinds of things is massively important. And I think we’re in a very dangerous time in terms of that kind of thing, with many of the decisions that are being made, especially by larger organizations. But that’s not an area that I am an expert in, or that I feel I can comment on. But what I am seeing are significant long-term consequences of adopting these more manipulative techniques. Because I think there’s a perception that users are unaware that they’re being manipulated. Because these techniques work, people go, “Oh, okay, therefore people aren’t aware that we’re manipulating them. So everything’s fine.”

Paul: The truth is very different from that. Those things, these forms of manipulation, are happening on a subconscious level, yes. And they work because they’re subconscious, but people are still consciously aware of it. I’ve done a lot of usability testing on things like hotel booking sites, which are well known for this kind of thing. And the truth is, people will go, “Oh, I hate all this manipulative crap.” But then they’re still influenced by it. So it’s the impact of the fact that people are aware of it, and then also it’s got a lot of hidden costs associated with it. You tend to see high returns, you tend to see more contacting of support and those kinds of things. And a lot of organizations are not joined up enough to realize that that kind of thing is happening because of these dark patterns.

Drew: I guess it’s a bit like going to a theme park and buying lunch there. You know that you’re being way overcharged, but you want your lunch at the theme park, and so it leaves, not literally, a bad taste in your mouth, hopefully. But there’s a bit of that regret there, that you know that you’re being shafted but you go along with it all the same. But you might not be keen to return next time you’re budgeting your holiday.

Paul: Absolutely. But then there’s also the element of buyer’s remorse, that a lot of time if you bounce someone … You can bounce people into doing pretty much anything you want. And that’s fine, take out ethics for a minute. But you could argue, but that’s fine from a business point of view. But what you end up with is an audience of customers who are suffering from buyer’s remorse. Buyer’s remorse is extremely dangerous because that’s what leads people to complain online, that’s what leads people to return items and all of those kinds of things. So it’s incredibly important that people are happy with their decision, they’re happy with their purchase. And that’s really what the book is about, is how do you get people to a point as fast as possible where they’re happy with their decision without them then afterwards regretting that decision?

Drew: So say that you’ve been using some of these perhaps slightly underhanded techniques on your site, and you’ve seen that it’s converting well, you’re turning visitors into customers quite effectively. But you want to, perhaps you’re seeing more returns or you’re seeing some bad reviews, or you’re seeing some of the consequences of this buyer’s remorse that we were talking about, and you want to try and improve things, get rid of the underhanded techniques, and bring in a more ethical or more customer-friendly ways of converting people. How are you going to know if you’re actually having an effect? You presumably have to come up with some way of measuring your conversion before you can start making changes?

Paul: Yeah, absolutely. And I think, again, this is something that many organizations are quite poor at, is being clear about how they’re going to measure success. Now, yes, your conversion rate is one metric you should absolutely be following. But even with conversion, you need to be a little bit more sophisticated than how many people are buying. You also need to pay attention to average order value, you need to pay particular attention to lifetime value. So how much are customers worth over their entire life? Because you may well find that you’re getting quite high churn of customers if you’re using dark patterns and things like that.

Paul: But really, conversion should be just one of the metrics that you’re measuring. There’s also things like, you need to be paying attention to engagement, how engaged are people with your content. Because that makes a big difference in whether they eventually go on to convert. So you’re looking at things like, how much of your videos do they watch? How long do they spend on your site and what are they looking at while they’re doing it? Are they engaging on social media and those kinds of things? And then the final aspect is obviously usability. You need to be measuring how quickly someone can complete a particular task on their website, and how easy they find the system to use, and various different other criteria.

Paul: And there are loads of mechanisms that you can use for measuring those different things. There are some great tools out there. And also some good metrics that you can adopt. So, for example, with usability, there’s something called the system usability scale, which could be a very useful metric to measure. But equally, there are tools like maze.design, is one that I often use, which will measure how long it’s taking someone to make a purchase, for example, get through the checkout. So yeah, having that broad range of metrics, you’re not just focusing on how many sales did we make this quarter. You’ve got to look at the bigger picture.

Drew: Are there any dangers that you could end up measuring the wrong thing?

Paul: Yes. Yes, absolutely. And so as a result, I think any metric that you’re looking at, that’s why you really need a range of metrics. If you just focus in on one particular metric, so for example, a lot of marketing professionals are judged on the number of leads that they’ve generated in a particular quarter or whatever. If you just have one metric like that, then it’s going to, A, skew the reality of what’s going on, but B, it’s going to end up encouraging some less than perfect behavior. So let me give you an example. I worked with a company that produces project management software. And they had a marketing department and they had a sales department. And the marketing department was tasked with generating leads. That was their job. They had to generate as many leads as possible.

Paul: The sales department were judged and assessed on how many leads they converted. Now, the website was owned by the marketing department. So the marketing department came to the conclusion that it was a really good idea to, the product demo that they had on the website, they were going to make people register before they could see the product demo. Because that would generate a large number of emails and a large number of leads to help them meet their target. Sure enough, it did. It generated a huge number of leads, a lot of people just gave up and went away, but many people did actually sign up to see the demo.

Paul: Now, the problem that that created is, the majority of those leads weren’t good quality leads. They were people that were nowhere near the point of being ready to talk to a salesperson, and so when the salesperson contacted them, they weren’t interested. They didn’t want to talk to them. But the salesperson had already wasted the time and the effort in calling them. And then they also had to filter through all the people that entered “Donald Duck@Disney” as their email address. So actually they created a huge amount of internal work for the sales team, and the sales team conversion rate plummeted through the floor. Because they had all these poor quality leads. So that’s a great example of how things can go wrong if your metrics are too narrow and too skewed in a particular direction.

Drew: And I guess a lot of it comes down to understanding who the user is. In order to turn somebody into a customer, you need to understand who they are. I guess so much about user experience design is effectively putting yourself in the place of your user and empathizing with what they’re trying to do. So how do we go about understanding who our user is?

Paul: Well, again, there are lots of different ways of doing that, depending on your time and your budget and things like that. I’m a great believer in actually meeting with users. I think there is a bit of a tendency at the moment towards, we’ve got all these wonderful analytics and survey tools and that kind of thing. And sure enough, those are great. I’m not in any way knocking them. But if you’re trying to convince somebody to take action, as you say, you need to empathize with them. And knowing that somebody has 2.3 children, works in the city, and I don’t know, spends their weekends kayaking, doesn’t really help you to know and empathize with them as people.

Paul: So personally, I’m a much bigger fan of actually speaking to people and doing user interviews. Even if they’re over the phone or remotely, which they have to be at the moment. They’re very much worthwhile in terms of getting to know people. Now, that said, I think another thing that I love to do, and just kind of blows you away, you can’t do this at the moment, but hopefully you will be able to soon, which is, you go and visit people in their homes. Now, the reason that I find this so valuable is because you find out about the reality of their experience in a way that you would never get from just talking to them over the phone or from a survey.

Paul: Now, I’m not saying you need to do this a lot. Probably doing it once is enough. But essentially … Let me give you an example. I was once testing an e-commerce site, and so I decided to visit some people in their home and actually test the site with them in their own home. So I went to visit this one lady, and she opened the door, and immediately all these cats came out and crawled around my legs and disappeared off. And she was a stereotypical cat lady. I’m sorry to be rude, but she really was. Every surface in the house was covered with knickknacks and ornaments relating to cats in some way. There were pictures of cats on the wall. She had a total of nine cats, which is just insane.

Paul: So we talked for a while, and we sat down to use this, to test with this website. And we used her computer, which I tell you took 10 minutes to boot up because it was this old tower computer, it was an absolute nightmare. And that whole desk was covered with clutter and knickknacks and things. And she had post-it notes all around her screen. Now, the minute she sat down in front of that computer, a cat jumped on her lap. So she spent the rest of that usability session trying to juggle a cat that was on her lap. The cat got so fed up at one point that it wasn’t getting enough attention that it decided to crawl across the keyboard and sit on the keyboard. Which I know you understand because you’ve got a cat and I’ve seen pictures of your cat doing the same thing.

Drew: I feel seen.

Paul: Yeah, exactly. And then, on top of which, I asked her at one point, “Add a product to the basket,” which she was able to do. And then I said, “Now, go to the basket,” and I realized there’s no way she’s going to find the basket. Because she had a post-it note stuck on the screen over the top of the basket. Now, that is the real-world experience. We sit down and look at our websites and we think they’re so easy to use and so simple. But if you’re juggling with a cat and if you’re living in chaos, or you’ve got distractions and that kind of stuff, then you don’t have that clean, clear mental point of view to approach the website. You are under what is called cognitive load.

Drew: So I guess one solution to that might be for every design studio to be equipped with cats.

Paul: Yeah, absolutely. And not only that, but equipped with (bad) computers. Because we all sit, don’t we? I’m doing it right now, I’m sitting in front of a lovely iMac with this gorgeous screen. And that’s not what most people … I remember another occasion I was designing a website for an elderly audience. Well, I say I was designing it, I was doing the UX side of things. And I was getting quite frustrated with the designer, because the designer was a young guy, and he did these beautiful interfaces that was all subtle and lovely and gorgeous. And I was saying, “I’m sorry, but this old audience are not going to be able to see what you’re doing, and they’re not going to be able to click on all these little links and stuff. And you’ve got to make it more brash and horrible,” which obviously he didn’t want to do.

Paul: So I came into the office one day with a pair of reading glasses and a pair of ski gloves. And I made him put on the reading glasses and put on the ski gloves. Now, he didn’t need reading glasses, just to be clear on that. And I said, “Now use the site.” And, of course, he couldn’t. He couldn’t see properly, he had lost motor control in his hands because he had these big, thick ski gloves on. So that helped him to empathize and understand what his audience was going through. And so things like that, I think, are really important to do. Obviously, that’s a bit of an extreme example, it was me making a point and rubbing my designer’s nose in it. But you get the idea.

Drew: You mentioned the cognitive load of buying. Making personal decisions online can be fairly overwhelming at times. Are there things that we should be doing that are going to help the customer have a better experience and be more likely to convert, more likely to actually make a purchasing decision?

Paul: Yeah. It’s really funny, cognitive load is a fascinating thing in terms of how it affects us. So what cognitive load is basically, is having to think too much. We have two systems in our brains. We have system one and system two. And system one is that unconscious decision making that we make all the time, and system two is our conscious mind. Now, our conscious mind is incredibly powerful, but it easily gets overwhelmed. It easily gets tired out. And that’s known as cognitive load. And when we are overwhelmed, when our cognitive load goes up, it has all kinds of really bad impacts on conversion rate. So suddenly your website feels hard to use, it feels untrustworthy and a little bit suspicious, and it feels just downright bad. So our conscious minds are very cynical as well, so we start not believing what’s being said on the site. And it really has an enormous impact.

Paul: So the way that you lower cognitive load is really about simplifying your website. So removing unnecessary distractions that are on the website. It’s about being consistent in your website. So buttons don’t move around, things don’t change. But not only consistent within your own website, consistent with people’s expectations from a website. So to give you an example of what I mean, let’s say I asked you to search on a website. Where would you look? You’d look in the top right-hand corner, wouldn’t you?

Drew: Right.

Paul: Everybody looks at the top right-hand corner, so the first thing, they look at the top right-hand corner, then they look for an input field. They enter their search query in the input field, and they press the button next to it. That’s what’s called procedural knowledge. We have learned that that is a procedure that, if we go to a website, look at the top right-hand corner, use the input field, click the button, we will search on that website. But the minute that you break that procedural knowledge, our cognitive load goes up. So at that point, we’re starting to go, “Well, hang on, where’s the button?” Or, “Why isn’t the search field the way it’s supposed to look?” Or, “Why isn’t it in the top right-hand corner?” So that consistency with expectations matters a lot.

Paul: And then our mood matters as well. Bizarrely, you know what it’s like, some days you wake up and you’re in a really good mood. And everything seems to be easier. And then other days you wake up in a bad mood, everything seems to be harder. So actually, the mood we’re in affects our level of cognitive load. So things like design delighters, nice little friendly copy, colorful graphics, all those things, they help as well to put us in a good mood that lowers our cognitive load. So it’s really mood, inconsistencies in the interface, confusing, too much information being displayed, and then finally priming people. So in other words, setting their expectations about what will happen and why it will happen.

Drew: I guess all these things weigh into how much trust somebody has in the website. And I think trust is quite a big factor, isn’t it, in inciting someone to actually buy from you?

Paul: Oh, enormous.

Drew: Because anyone can build a website online, we all know that. We’re web people. And there are thousands of places that you can buy the same product or service from, quite often. So there needs to be some way of building up trust. Are there other ways that we can build up trust in a site?

Paul: Yeah. You’re right, people buy from people they trust and from organizations they trust. So when it comes to trust, a lot of it is about humanity. Being a human being. You know how many times you go to a website and it just feels like it’s spouting marketing BS at you? Do you know what I mean? The great example I use in a book, where there’s some copy on a university website. I think it was the University of Essex website. And basically, that copy was written in the third person. So it’s talking about the reader as students, it was talking about themselves as the University of Essex. And it just felt, it lacked any kind of humanity and any sense that they cared about you or liked you. And simply turning that around and writing it in the first person, so talking about “we” and talking about “you,” makes an enormous difference in making that connection with people.

Paul: Other ways that you can do that, obviously, is through things like social proof. You can build trust by demonstrating that you’re a trustworthy brand. But again, you’ve got to accept that people are very cynical these days. So it’s not a matter of just slapping some logos on your website and going, “There’s your social proof.” Or slapping a text testimonial. Because people know that some companies just make that stuff up. So one of the things, actually a product of your own, actually, Perch, I don’t think you do this anymore, but for a long time on your website, you used to have testimonials that came straight from Twitter. They were pulled straight out of Twitter. And that was such a good idea, because those testimonials, people can click through and see that there’s a real human being behind it.

Paul: Another example is videos. If you’ve ever watched video testimonials on websites, where the person that’s speaking is beautifully lit, has got perfect teeth, and says a whole spiel about how great the company is without pausing, without going, “um,” without making mistakes, they’re obviously just reading off a script. That’s insincere. However, if you have a shitty video that’s filmed on a webcam, that the audio’s a bit crap, that’s actually more effective. Because it’s more real. A great example of this is: there’s a guy called Paul Jarvis who sells an online course called Chimp Essentials, which teaches you how to use MailChimp. And if you go to chimpessentials.com, he’s got all these videos, just like he’s obviously just chatting to someone over a webcam and them talking about how great the course was and how much it helped. And that is so powerful, because it’s authentic, it’s real, it’s human. And that’s what it’s about. It’s about coming across as a human being and making a connection with people.

Paul: So yeah, I’m a huge fan of that kind of sincerity and openness and honesty. Buffer is another example of that. Buffer, they lay out everything online. You can see how much their employees are paid, you can see how much they earned in the last month, you can see what their diversity range of staff and employees are. You can see everything about that company. And so you know they’re not hiding anything. You know that they’re being sincere and open. And that goes such a long way.

Drew: So we understand who our customer is. We want them to buy from us. Is there a single moment when a conversion happens on our site?

Paul: No. No, conversion is very much a journey. So it’s a series of micro-interactions. And I think that’s part of the problem that people have, is that they perceive, “Okay, they’ve clicked on the ‘buy now’ button, we’re done.” Or they’ve sent us a contact form, we’re done. And actually it’s a lot more nuanced than that. There are many, many steps in a journey that someone goes on. So let’s take, I don’t know, donating to charity, for example. So the first interaction might be, you see an update that a friend shares on social media about some crisis in the world. So your first point of conversion really is just clicking on that link in that social media update, which takes you to a blogpost. And then your second conversion is actually reading that blogpost and looking at it.

Paul: And your third, maybe, is to sign up for updates about that particular crisis. And then maybe you receive some emails about it. So your next conversion point is actually opening those emails and reading the content. And then it might be that they, in those emails, ask you to make a donation. So the next step is to make a single donation, one-time donation. And then they’ll follow up with you again, and that might turn into a monthly donation. And then that might lead you to actually start volunteering for them or fundraising for them. And, eventually, it might even lead to you leaving a legacy when you die.

Paul: So actually, any point of conversion is just a step in an ongoing journey. And we need to start thinking of conversion as a journey of relationship with a customer, rather than, “Okay, we’ve got them to sign on the dotted line, we’re done.” Because there’s so much more potential than just that.

Drew: So every interaction you have with that customer is a point where really you’re selling with them. It’s always be closing, right? ABC.

Paul: Yeah. Yes, you know, I hadn’t thought of that. Yes, it’s absolutely straight off of that, isn’t it? Yeah.

Drew: So you’ve carefully designed a site, you’ve done your best to ensure that you’re going to get some good conversions without any dirty tricks, without anything underhand. You launch the site. Is that it? Are you done?

Paul: No.

Drew: What should we be doing over time?

Paul: You’re asking questions that I know you know the answers to. That’s the sign of a great interviewer, when you’re happy to ask questions that other people might need the answer. No, of course it is. You’ve run Perch for years, you know that you can’t just start something and then walk away from it. When it comes to conversion, really that initial launching is the very, very beginning of the process. And actually, what is important in the journey is that ongoing optimization, that ongoing monitoring and improvement. It’s interesting, I’ve literally just written a report for a company outlining this approach. So basically it begins, you go through a cycle. And the cycle begins with, you try and identify problem areas in your site. So typically you would look at your analytics. And you’d look at pages that have got a high dropout rate for the number of visitors that they have to that particular page. So a high percentage of dropouts. So you know that something is going wrong on that page. So that’s your first step. Then you try and narrow down, well, what’s going wrong on that page?

Paul: Now, you can either do that through session recorders, which allows you to watch back users interacting with that particular page, and you might be able to spot where it’s going wrong. Perhaps you’re having problems with a form or perhaps they scroll straight past some critical button, or something else. Alternatively, if that doesn’t work, you might want to do some remote usability testing, and that’s so cheap and easy these days, using services like usertesting.com or User Brain. There are all these great services that make it really easy to test those kinds of pages. So that will enable you, probably, to work out what the problem is. Once you’ve done that, then the next step is, now we need to identify how we’re going to fix that problem. And in that particular case, you can have a couple of different approaches.

Paul: If the problem is relatively easy to fix, so if it’s just things like changing imagery or changing button colors or that kind of very simple thing, then probably you’ll want to go straight to A/B testing. So you use something like Google Optimize to send some of your users to an alternative version of the page with these small changes being made. You see whether that improves things. And if it does, you push it live. If it’s more substantial changes, then you’ll probably want to mock that up or prototype that before you go to all the expense and time of building it properly. And then you can test that either by doing some more usability testing, or if it’s just a static mockup, in other words, it’s not an interactive thing, then you might want to do something like a first-click test, where you say, “Okay, where would you click on this mockup in order to complete X task?” And see whether people are clicking in the right place.

Paul: Or another test that you can do is something called a five-second test, where you show them the mockup for five seconds, take it away, and you ask them what they recalled. And that’s a really good way for ascertaining whether or not they spotted that call to action they previously scrolled straight past. So you have to use a bit of imagination, but basically you then test your hypothesis, if you like, about how to fix it. Presuming you’re right, you then roll it out. Now, you’re not at the end of the process then. Because you now go back to the beginning again. You look at, “Well, what’s the next page that people are most exiting the site from?” And you repeat the process. And you just keep doing that, really, forever, slowly and incrementally improving your conversion rate over time.

Drew: This all sounds very logical, very attractive to somebody who, like me, who’s a business owner and I’ve got digital product, and I think, yes, I could be doing this. Some of the listeners will be freelancers working on an hourly rate for a customer who has these sorts of problems. And I can see it might be difficult to convince that customer that this is what they should be doing, this is something they should invest in. Because all the time spent in even just setting up some monitoring and setting up something to measure conversion is money that that client is going to have to pay out for the designer to do it. What would you say to those designers? Is there an effective way they can persuade their client that this is what they should be doing?

Paul: Yeah. This is a tricky one because it’s very hard to persuade anybody of anything, in my opinion. People become very entrenched in their ways of thinking. But it’s worth finding out what they care about. Because there will be certain metrics that they want to move. It might be they want more leads, it might be they want more quality leads, it might be that they want to reduce their cost of sale. Whatever it is. And then you start talking about these kinds of optimization techniques in that context. That said, you’re never going to get someone to commit to a major program of incremental design and usability testing and all those things in one go. What I would start with is just trying to encourage them to go through that cycle once. So it might be that you even have to install the analytics on your dime. But it’s not a big deal, is it, to add something like Google Analytics or something like Hotjar for session recorders.

Paul: So you basically then just take them through it once. You say, “Okay, well, let’s give it a go for one time. Let’s see if we can make a difference to the conversion rate by looking at the analytics, by mocking up one thing, and just improving that one thing.” If that works, you rinse and repeat. They don’t necessarily need to commit to an ongoing retainer where you’re continually optimizing it. This could be done as a series of sprints, effectively, going through the loop one thing at a time. In terms of more general stuff, like for example, just simplifying the interface, then in those kinds of cases, often it’s a matter of actually showing them what better might look like. Now, I’m afraid to even say this in front of you, Drew, because I remember many, many years ago … Or no, it wasn’t you, actually, I was about to say that it was you I remember going on about speculative design. But it wasn’t. Yeah, you’re off the hook.

Paul: It was you ranting about the fold. That was the thing that I’m remembering. Anyway, that’s beside the point. So one of the things you can do there is actually try … For the first time, I’m not saying do this regularly. But if you’ve got an existing client and you’re seeing glaring problems, mock up an alternative version of doing a particular page, and then do those five-second tests that I mentioned, or do a, what was the other one, a first-click test. And see whether those can make improvements, and show that evidence to the client. So you can use a tool like usabilityhub.com that will allow you to do those tests really easily. If you don’t want to do that because you don’t want to put the effort of mocking those things up, the other thing that you can do is just record a few videos of people using the website. And then edit down all of the bits of them moaning and complaining about how crap the site is to use into a two-minute horror reel, and send it to the client. That can do it as well.

Drew: So would these generally be, would these be the tips you’d give somebody who was just wanting to get some quick wins to start? They’ve done no optimization, and they just want to get started. Are these the same sort of things they’d do for a quick win?

Paul: Yeah, to some extent. Often I find, where I start, if I get a new client, the thing I normally start with is simplifying the user interface. Because inevitably sites end up bloated with a load of things that don’t really help. So the way that I tend to do it is, I’ll take a particular page, let’s say a home page, for example, and I will systematically look at every single element on that page. And I will ask myself three questions in order. Question number one I ask is, could I remove this element? If I removed this element, what would be the negative consequences of doing so? So you’d be amazed at how much you can just strip out of a website. And of course, every element that’s on the screen is every element a user is having to process and look at. Every element adds to their cognitive load. So anything that you can remove, great.

Paul: Then if you can’t remove an element because it’s critical to the completion of a key task or convincing users to take action or whatever else, then the next question you ask yourself is, can I hide this element? Could I move it deeper in the information architecture? Could I put it under a tab? Could I put it under an accordion? Whatever else, just to get it out of the site for the majority of people. So that often helps. And then if the answer is, well, this really is absolutely critical, so I’ll give you an example, maybe you’re forced to have some compliance copy on your website. That happens, I get that a lot with my bigger clients. “Oh, yes, legal department says we have to have this.”

Paul: So my third option, my final option, is can I visually shrink this? So can I de-emphasize it, put it in the footer or make it smaller or make it lighter text? Anything to draw attention away from that and focus it on stuff that really matters. So that’s almost always my first starting point with any kind of conversion, is just to simplify everything. The other thing that I do alongside that, which is a really useful starting point, is called objection handling. So I will make a list of as many reasons that someone might choose not to act as possible. And I then make sure that those are all addressed clearly on the website. Because often they’re not. So a classic example of that might be, somebody who comes to sign up for a newsletter. Now, you think, when you sign up to a newsletter all these things go through your head, are they going to sell me an email address? Are they going to spam me? Is the content going to be relevant? Can I unsubscribe in one click?

Paul: All of these objections. Are you addressing those? And not only are you addressing them, but are you addressing them at the point that you want people to convert? So for example, yes, you probably say something about whether you’re going to sell their email address or how much you’re going to email them and stuff. That’ll be in your privacy policy. But that’s going to be buried in a completely different part of the site where no one ever looks. And to be honest, it’s all illegible anyway because it’s written in legalese. So answering people’s questions at the point they have them is also another really good starting point for just giving your conversion rate that little boost.

Drew: That’s fantastic. And I think all these tips are things that you go into in quite a lot of depth in the book.

Paul: Mm-hmm (affirmative).

Drew: I found it to be a really great read, I’ve enjoyed browsing through it so far. I know it’s in the late stages of production and it’s coming out from Smashing magazine this spring, 2020.

Paul: Mm-hmm (affirmative).

Drew: That’s Click: How to Encourage Clicks Without Shady Tricks. And you can find out more about the book if you go to encouragingclicks.com. And then when it’s released you can go to smashingmagazine.com/books and you’ll be able to find it and buy it from there. Now, Paul, I guess if people are listening to this, I presume that they like podcasts. You’ve been podcasting for I guess almost 15 years now?

Paul: Yeah. Yeah, we were the first web design podcast in the world, that’s my claim to fame.

Drew: There we go. If a listener hasn’t come across the Boagworld podcast, what sort of thing could they expect from it?

Paul: Nonsense, generally. No, it’s a season-based show that covers all aspects of web design in a pretty broad sense. We don’t do a lot on development, to be honest. So it’s mainly design, project management, content creation, all of those kinds of things. A lot of UX stuff, because that’s my personal passion. It’s quite a laid-back conversational show. We have seasons, and different seasons are on different topics. So for example, there’s a whole season dedicated to conversion rate optimization, if people want to learn more about that as a subject area. So you can pick and choose which seasons you listen to. Yeah, I don’t think there’s a huge amount more to say about it. The current season has been one about almost like a virtual meet-up, where we’re having conversations with people listening to the shows. You can come along and join in. But next season will be something totally different. So it’s a bit of an eclectic mix, to be honest.

Drew: I’ve listened to it on and off for a good number of those 15 years, and it’s always an enjoyable listen. So I would recommend that people check it out if they haven’t done so already. So I’ve been learning from you about honest ways to convert users into customers. What have you been learning about lately, Paul?

Paul: I’ve been getting slowly more and more obsessed with psychology. Because obviously that relates quite a lot to both user experience design and conversion rate optimization, so I’ve been realizing how little I know about psychology. So it started off very simply, by following a guy called Joe Leech, who’s written a free e-book that you can download called Psychology for Designers. So that got me thinking more about psychology and understanding how to approach the subject. And then I’ve started to read proper psychology books now. I feel like I’m a bit more of a grownup in the field. So for example, earlier I was talking about system one and system two, that comes from a book called Thinking Fast, Thinking Slow, that I would highly recommend.

Paul: It’s a bit of a stodgy read at places. It’s not the easiest book to read. But it’s very, very much applicable to the kind of world that we’re looking at. So a lot about psychology. I’m also always nosing into things like marketing and sales as well, because I’m quite interested of how people apply sales techniques offline. So all that stuff I was talking about, like when I talked about objection handling, that comes from traditional sales, basically. So yeah, those are the two big areas at the minute.

Drew: If you, dear listener, would like to hear more from Paul, you can follow him on Twitter, where he’s @Boagworld, or find his podcast, blog, and details of how you can hire him to consult on your digital projects at boagworld.com. Thanks for joining us today, Paul. Do you have any parting words?

Paul: Keep safe, I guess, at the moment. That’s the sad thing that you’re having to say, isn’t it? And yeah, just start experimenting with conversion rate optimization. You’ll be amazed at the results you see.

Smashing Editorial (dm, ra, il)


Articles on Smashing Magazine — For Web Designers And Developers

falbe-frederiksen-400x400-1
25 Feb

Smashing Podcast Episode 10 With Trine Falbe And Martin Michael Frederiksen: What Is Ethical Design?

by TBSCategories: News

Smashing Podcast Episode 10 With Trine Falbe And Martin Michael Frederiksen: What Is Ethical Design?

Smashing Podcast Episode 10 With Trine Falbe And Martin Michael Frederiksen: What Is Ethical Design?

Drew McLellan

A photo of Trine Falbe on the left, and Martin Michael Frederiksen on the rightIn this episode of the Smashing Podcast, we’re talking about Ethical Design. What does it mean for a design to be ethical, and how do we make improvements in our own projects? I speak to Trine Falbe and Martin Michael Frederiksen to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is a human-centered UX strategist, designer and teacher who works at the intersection between people and business. She’s deeply passionate about ethical design and designing for children and she’s also a keynote speaker at conferences and a UX advisor in strategic projects. He is a serial entrepreneur born with a practical appreciation for the crossroads between business and digital development. He’s published the books cross channel and the CEO’s guide to IT Projects that cannot fail.

Drew: He works as an independent consultant for businesses that needed devil’s advocate when trying out new strategies and ideas. Together, they are two of the authors of the ethical design handbook, new from smashing this month. So we know their experts in the topic of ethical design, but did you know that also an amateur bobsled team? My smashing friends, please welcome Trine Falbe and Martin Michael Frederiksen. Hi Trine. Hi Martin. How are you?

Martin Michael Frederiksen: I’m smashing.

Trine Falbe: We’re smashing.

Drew: I wanted to talk to you today about the subject of ethical design, particularly in light of the new book you’ve written alongside Kim Anderson. So this isn’t the first book you’ve all written together, is it?

Trine: No, we actually have a project that’s three years old now. We published the book about white hat user experience. So that was our first book project together and that went so well that we decided to do another one.

Drew: So you’ve written about the topic of ethical design and this is a term that we’re hearing sort of more and more of lately is really rising up in the consciousness of designers, it seems to me at least. Why do you think that ethical design is becoming more relevant now?

Trine: We’re seeing a lot of tendencies in the world. We’re seeing a lot of lawsuits coming up. We’re seeing a lot of tendencies where people are starting to speak up against privacy issues and violations. So there are a lot of mega trends that are pointing towards a more ethical demand from the consumer side, so that’s just one of the things that we’re starting to see. It’s still pretty early on, still something that is slowly developing, but we definitely see some changes in the currents. So I think that that’s the reason why we’re starting to discuss ethical design at a much grander scale. There are also all sorts of issues related to lack of diversity, privacy in the sense of data being hacked and lacked. So we are starting to see an increase in general consumer awareness in this area, so obviously the industry needs to take that seriously and that’s what they’re slowly starting to do.

Martin: And it’s not without reason, I would say. There’s a famous photo of Mark Zuckerberg; it’s an official Facebook press photo and you can clearly see in that photo that he has put tape over the camera on his laptop. So he probably know that we are being under surveillance from social media and other platforms. He has definitely taken his precautions and the entire social media industry and the online advertising industry is listening on whatever we do, and the ethical design thinking is simply a pushback towards that.

Drew: Do you think that the rise in smartphones and the everyday use of digital products has an impact on this as well?

Martin: Of course it has. And I’m not thinking that marketing people or business people of today are more evil than 30 years ago. It’s just a different time, and the tools are different. But the scale of business, the number of days that you can aggregate using a digital technology is just huge and it just creates a new set of problems.

Drew: So getting back to basics, we talk about ethics. What do we really mean by ethics and how does that map to what we do in terms of design work?

Trine: So in the book we have a couple of definitions that are actually quite important. One is the definition of ethics, but the other one is the definition of ethical design because they’re not the same. So the definition of ethics we’ve brought down to something relating to duty and responsibility to treat others with fairness and respect. There are a couple of terms that are important, so responsibility and fairness and respect. And that’s something that we can tie over to design, to what we do in design because what we need to understand is that if we are to practice ethical design, we need to create products and services that grow from this principle, from ethics, the principle of fairness and fundamental respect.

Trine: But we also need to broaden that to understand that our business model and the way that we grow these products and services need to also be rooted in a fairness and respect towards, not just the people that are at the receiving end of our products, the customers, but also to the people that are involved with making these products. And that’s really what ethical design is about too; it’s about showing a fundamental fairness and respect towards everyone involved in a project or in a business running a product.

Drew: So sometimes it’s helpful to think of what the opposite of what ethical design is. Obviously there are lots of examples out there of unethical design and things that might perhaps emotionally manipulate users and customers. Have you seen lots of examples of that in your research?

Trine: Well, for sure, we’ve seen a lot more examples of unethical design than ethical design. That’s actually been a bit of a, not a pain but a struggle or at least a challenge when writing the book and researching for it. We’ve spent a year of doing this, is to find the good examples. It’s a lot… We’ve seen a lot more bad examples. Martin who brought up the Zuckerberg photo with the Mark Zuckerberg’s computer webcam being hidden or taped over is one. There are lots of examples, really big ones. Cambridge Analytica where with huge data breaches and, or data trade and potential manipulation of political results.

Trine: But we’re also seeing lots of products that just have all these really manipulative, dark patterns in their interfaces like booking.com, Viagogo, which is also they resell tickets to an increased price. So they have pretty much every manipulative pattern in the book that you can think of from trying to entice us to buy by saying all these other people are buying, we’re running out of stock, hurry up, hurry up. So all these different types of manipulative design patterns we’ve seen a whole bunch of.

Martin: But also, in a smaller scale, it’s also just sometimes it’s because there’s an evil business strategy, but most likely it’s just because no one really checked the customer journey. Like I was at a conference in New York, I booked a hotel and ever since they’ve been sending me emails. And, so the unsubscribe function on that email doesn’t work. You can send an email to the hotel, they don’t care or the one who received the email, it’s not her job or whatever. And a lot of what we see in dark patterns is just nobody cares or no one has the responsibility to do anything about it. And you shouldn’t confuse that because there’s the evil business model and then there’s the, we didn’t know how to do it right, and the latter is actually what we try to in the book is to explain how can you do this in a proper manner.

Martin: And of course you’re allowed to have a business model where you make a living out of your app or service or whatever you do. And one example is if you make a fitness app, you can have a paid version of the fitness app, you can have advertising, you can have a data brokering as the business model, but you could also just make it free. And then you could have a feature, limited free version that you can use to upsell one of the paid versions. And if I as a customer want to purchase that app, I may want to keep my data out of the cloud, so that could be an option in that fitness app that I pay a subscription fee and then all my fitness data is on my phone and only on my phone. And that would be one very simple example of having an ethical business model where you can actually make money from that fitness app, which is totally okay.

Drew: So it’s a lot more about putting the user first, which is something that we talk about in so many different areas of design, isn’t it? We talk about that in usability and in accessibility. And really that’s I guess the driving force behind good design, isn’t it? Is putting the user or the person who experiences that design first. I guess we see lots of examples of, I know when I’ve been, maybe purchasing tickets these sorts of things online and there’s sort of banners, nagging, say, 50 people are looking at this now, or sort of countdown timers that try and pressure you into making a quick decision without thinking things through. And those would be all examples of manipulating users, would you say?

Trine: Yeah, that’s a really classical tricks from the book; from manipulative design 101. And it’s, I mean, Martin and I just discussed this a lot because there is a business case for doing this, otherwise they wouldn’t be doing it. And we’re not really trying to convince the companies that deeply believe that this is okay, that this is fine, that let’s make our money like this. What we’re trying to do is empower the companies and teams and individuals who know that it might be a good idea to change directions to do something else because we know that there is a sound business in, and just it’s good business logic to do ethical design and it’s not like it’s something that just makes you feel better because that’s not… It’s a good argument, but it probably won’t convince the majority of CEOs that this will make you sleep better at night.

Trine: But you also have to understand that you don’t necessarily have to manipulate people into buying your product because that tends to backlash at you. You have to remember that treating people well means that they stay you’re loyal to your brand so you don’t get all this brand damage from manipulating people into buying a product that they don’t really need or want. You also have to be mindful of or respect the fact that a simple UI typically gives a better conversion rate. So when we declutter stuff, when we declutter an interface, it typically results in a better conversion because it’s simpler to perform an action. There’s not all the cognitive load that comes with a hugely cluttered interface like we see in a lot of poorly designed websites.

Trine: And then there’s obviously all the legislation that is appearing; not just in Europe but most recently in California as well. And this is also a tendency that we’re seeing. So that’s also something to look out for. And then, focusing your budget on creating good products and good customer service instead of always trying to handle backlash on social media is also a pretty compelling argument that you might want to look into. So it is a good business logic to do ethical design, it isn’t the opposite.

Drew: Would you say it comes down to short term versus longterm thinking? Because presumably these, the manipulations, the dark patterns, those sorts of things produce; they do produce business results in the short term. You can put something in place and see your conversion rate go up, but then perhaps over the long term, that damage to your brand starts having an effect.

Martin: I think that’s perfectly true. I think you have to look at the business that you do online as if you had a store on the main street in a medium sized city where you have to keep your reputation intact, and if you don’t treat your customers well, then longtime… If you don’t treat your customers well, longterm you run out of business because people, they would go to some other store or they will buy from online. So whatever you do online, you really have to think of that there’s a longterm effect. And also there’s a kind of a there’s a hidden cost in doing things that are complex or things that manipulate, and if you declutter, as Trine says, there will be a longterm saving. And that’s never calculated when you talk about business model. You always talk about how much money you can make.

Martin: You never talk about the cost of making that amount of money. And especially in business to business project, you see lots of, and I’m not the type of guy, I’m involved in these projects, so I’ve firsthand experience from this. You see salespeople, they have a very complex pricing structure, and that’s because 20 years ago, 30 years ago, they would meet with all the customers and they will make individual pricing for the customers because that was how you did business before digital. Now they implement that and you’ll see that every customer will have his own price or her own price for any item, and you will synchronize millions of products every night. And if you create a more segmented business strategy, simpler pricing, it’s easier for customers to compare your pricing against the competitors. And if customers today are aware or they assure that they are not being… That they’re not paying too much for their products, they… That the pricing is not an issue, and the great customer service is the advantage.

Drew: We mentioned briefly legislation a sure while ago. In Europe, we think of GDPR a lot lately. How does something like GDPR as a piece of legislation play into ethical design?

Trine: Well, it plays into ethical design in the sense that we’ve added an additional layer of reasons why ethical design is that is an increasingly good idea because now we are not just facing… Our companies are not just facing potential backlash, and as Martin mentioned, additional costs that are related to doing manipulative design in your interfaces, and in the way that you conduct your business. You also face huge fines that come with GDPR and the California recently a privacy law in California. So that’s one thing. I think another thing is also that there is a pretty expensive cost related to compliance; legislative compliance that’s would be reduced if you have proper data models, proper data structure instead of just collecting everything you can get your hands on, but if you just go ahead and connect the data that you actually need to run your business, you have a much greater success rate in being complied to the legislation because you know what you have and you only have exactly what you need and when you’re deleting the data and how you’re deleting it and how you’re storing it instead of just putting everything in a pile in your database because you can.

Martin: I don’t think there’ll be huge fines for the GDPR except for a few big companies that will be toasted in public to show that the EU is focusing on this. Well, I think there will be lawsuits that will follow data breaches. So instead of fearing the GDPR, police will come after you at any time if there’s a data leak or a problem in your team, then you may have a problem. But the much bigger problem is that a lot of consumers will actually follow your brand and they will monitor if you do anything wrong. And the damage you can get from cheating on your customers is much higher than whatever you have to pay to the EU. And one is simple example is that a lot of consumers just like myself, will sometimes use a unique email address to sign up for a product or service.

Martin: And if you later on get an advertisement or some kind of contact based on that unique email address, you know that the source, so even the GDPR police from the EU is not at your office to check what you are doing, consumers will be checking on you all the time. And that’s, I think that’s, I think it’s wonderful. I think that GDPR is wonderful for European businesses because as a consumer, I now have a weapon against the business. I can contact them and I can say, I want the data that you have stored on me. I want to see the files. What do you have? And I think that’s good protection for your identity.

Trine: Totally agree. And I also think that GDPR has really impart, even if the common consumer doesn’t know how to utilize GDPR directly, the fact that GDPR has been so widely discussed and has had so much media attention. Ever since it’s, before it came into effect, and even today, in the general media, what that does to the general consumer is that it empowers them to talk about and consider and worry about and become critical towards their own privacy. This is something that we haven’t seen before; the pretty common perception from people who didn’t work in digital was I have nothing to hide, so I don’t really care, and I know the products are free and I know that I’m kind of paying with something, but they really have had very little idea as to what that currency was.

Trine: Today, they have a much greater knowledge on what data privacy and digital privacy is because GDPR has been so widely discussed in Europe. So I think that’s something that really has had a significant, has made a significant change in consumer awareness.

Martin: In Europe.

Trine: In Europe.

Martin: Because if you are an American, you are used to that you have no protection, whatsoever.

Trine: Exactly, if you live in California, right. And that’s just the first state. I’m pretty sure that that will be an example; leading example.

Martin: I think the funny part of this is actually that when you make a new law like the GDPR as an international company, all your software platforms will comply to that regulation because it’s too expensive to run two different software setups, one in Europe and one in the rest of the world. So a lot of countries outside of Europe, they are actually benefiting from GDPR because it will be the same software platform and the company don’t want to be out of business in Europe.

Drew: So I guess a lot of ethical design is not just how we design our interfaces, but maybe how we design our systems to handle our customer’s data as well, and looking at the whole experience from the beginning to the end of doing the right thing for the customer.

Martin: Yeah. And data storage is extremely important because you have to prove that you you keep my data in a safe place. And let’s say that I delete my app, I delete my account. Can you then verify that you actually deleted my data from all the backups? That’s extremely complicated. So you have to put that into place and you also have to test for it. There’s something wrong in the perception that I get a job in a software team and then I can kind of change everything and make everything ethical because a single person cannot do anything in this area. It needs to be a team effort.

Martin: And even you have the best intentions of what you do, it also matters that you can actually test and verify that it’s done right. And you will see in a software team that if you’re a developer and you write code, you will have to make a lot of decisions on your own because you have a business team behind you. They set up all the requirements. They have never time to meet with you. They will never answer your questions and they don’t understand your language. So as a programmer, you need to make a lot of decisions on your own. And for that reason, the importance of the test team is just, it’s so vital that they do that job, and testing if data are stored in the right place using the right methods. It’s just complicated.

Drew: So if I am a programmer or a designer within an organization, and in my view, the organization isn’t taking the most ethical approach, is there anything I can do to help to correct that, to help start changing course? Is there something that a designer can do or is it a case of get a new job?

Martin: Well, I think sometimes it’s a matter of getting a new job, but when I’m involved in a project, I always try to change things for the better. And one good way of doing so is to write up a small IT governance model for the project that you do because usually we can all agree in the principles. So after we’ve done that, we also have to follow the guidelines that we’ve been setting up. So let’s say that one of the guidelines is privacy first; the private, the privacy settings should by default be as private as possible for any user. Then if that’s your governance principle, then no matter what you do, you have to check, do we follow that principle and small steps, that’s also great. You don’t have to change everything from day one and you can’t do that, but you can make a small change every week. And then in a year or two, it makes a big difference.

Drew: So do you think it’s best just a work guerrilla style and put some sort of ethical influence on the parts of their product that you actually touch? Is there any mileage to be gained in trying to make a business case or trying to persuade the people at the top of the organization that this is a change they should make? What do you think? It’s just small changes from below to try and help where you can.

Martin: It all depends on your job title and your responsibility because if you’re a programmer, you can do a lot of invisible stuff that’s done right and no one will ever find out how good you are, but you can still do it. And if you work in a business unit, if you work in communication or in sales, you may be worried about the brand value, the reputation, the longterm effects. So it can also be meeting with some of the others in other roles and see how you can influence them.

Trine: Sometimes it’s also a matter of, if you are in that, again, I agree with Martin. It depends on your job title; how much reach you basically have. But a good way of sparking change or starting this ethical transformation that we call it is to pick a project that is kind of isolated where you can also… So a project that you have responsibility of that you can make your own and make that the changes that you, the ethical changes that you find important because what happens is you also have a piece of a project that you can now measure on. So that is the first step to proving the business case is to be able to measure that it actually had a positive impact. So that’s a very specific way to get started on this.

Drew: So if I’m starting out a new project or starting at a new organization or even maybe working on a side project that I would like to become something bigger, is there a good approach that I can take? Are there any frameworks that I could work within to help me make good ethical design choices?

Trine: Yes, there are plenty of frameworks. One is to be mindful of the consequences that you have. So there are some questions that you could ask for any decision that you’re making to make sure that it complies with certain ethical principles. One is, what are the longterm and short term consequences of the decision you’re about to make? Is it something that has any negative impact, either long or short term to the people that you’re designing your product for or to the team that’s dealing with, because consequences doesn’t just have to do with and users. It also has to deal with the business. If you’re making a decision that potentially hurts the brand of the company, then that’s a pretty serious consequence as well.

Trine: I think a good asset test if you’re doing a product or doing a feature is to ask yourself whether you would want one of your loved ones to be using this feature because if the answer is a clear no, then that’s an indicator that what you’re making might not be super clear cut; might need to be revisited to understand why it is that you’d want the business customers to use this, but you wouldn’t want your sister or mother or spouse to be using the same feature. And then you have to ask yourself, why is that?

Martin: I would like to quote from the book because we have a case story with LINGsCARS and it’s a car leasing and Ling Valentine, she’s just so different from the rest of her business. And she describes, and this is a quote from the book, “I would describe my ethic ethics as honesty wrapped in a boxing glove.” And if you just set up a very straightforward principle for whatever you do, it’s easy to follow.

Trine: Very true. Ling is exceptional. As you said Martin, she is in an industry that is notoriously known for not doing anything ethical or not doing a lot of things with an ethical mindset, but she will… I actually read through her entire privacy policy, which is normally a really, really dull thing to do, but I had the time of my life while doing so. She has something like… Yeah, I made Marsden read it. Yeah, I know.

Martin: That’s funny.

Trine: She had something like, I wish I could sell all this. I know I could make a ton of money selling the data of my customers, which is a compelling thought, but I won’t, I will… And she says something like, I will put it in a can of worms and dig it to the ground and sit on it before I do. So she knows that she’s sitting on a pot of gold and she also knows that she would never, ever sell it and that she’s very straight forward in that. And she has to, I mean, I encourage you. I normally never encourage anyone to go through the agony of reading a privacy statement because they’re usually so boring, but LINGsCARS is the exception. It’s a great Sunday read, go for it.

Drew: The book has lots of case studies throughout it. Are there any that stand out in your mind that would be interesting to highlight?

Martin: I think it’s actually more important that the book is also trying to provide a method for what to do. And it’s based on the case stories. It’s based on all the personal experiences we’ve had over the past 25 years in the software business. And I think when you read the case stories, they are unique in different ways and they all add to that general picture of what to do in the future. And then at the end of the book, we have four different blueprints for how to do a website, eCommerce solution, program an app, create technology for internet of things. And that’s actually how you get started. So after reading the case stories and the other content in the book, what is really important is that you create a change.

Martin: And we’ve been talking for many years about digital transformation, but the next level is actually the ethical transformation where you take all the ethical principles for good software design and you build that into the process and you have to understand that ethical design is not like you have a birthday cake and it’s made out of aero planes and pineapple and then you have a nice frosting on top of that cake; it will not be a good treat anyways. But it’s something that ethical design is actually a part of the entire design process, and that’s what we try to accomplish with the blueprints at the end of the book.

Trine: Yeah, I think, I honestly believe that that’s what will make this book something that will empower people to create that change and to start, because of course we raised the different concerns that are pretty commonly known, but we also know and we… Well, yeah, we also know that the readers of this book already know about the problems, right. It’s all over the place. What we’re trying to do is to give people some tools to get started on doing change and doing stuff differently. And the blueprints is one approach. We also included an ethical scorecard in the book, which basically is a way you can utilize it in different ways. You can utilize it to get an overall picture of whether of the ethical, where on the ethical scale your company is; where your product is.

Trine: But you can also actually use it to, you can take out different statements and different areas of the scorecard, and use it as your KPI to measure on ethical design. And that’s something that is still not being talked a lot about. How do we actually measure on these types of things, but it’s totally possible to do so and that’s something that we’ve spent significant time on addressing as well because we know that we need to, the people need to be able to make the business case. They can’t just go to their CEO and say, this will make you sleep better at night.

Martin: I have an example of a customer journey that will score really bad on ethical design. And this is a real example. It’s Serge Egelman on Twitter. He writes, “In order to verify my identity over the phone, Macy’s wanted to send me a one time password via SMS. They then asked me to give them a number to send that one time password too.” And this is just a completely broken customer journey and nobody has, no one has tested it. And these examples, they are all over the internet. When you start looking for them, you’ll find lots of broken customer journeys. And that’s why the evaluation method, using that ethical scorecard is so important because it takes like half an hour to go through the scorecard and then you will know where to improve.

Drew: That was something that really pleasantly surprised me with the book because I think I was expecting the book to be, to explain the case for ethical design; to motivate me to make changes. What I was then pleasantly surprised with was the things like the scorecard to help me actually evaluate a design. And then the very practical blueprints as you say in their sort of last third of the book that actually describe how I would practically go about creating more ethical designs. So that was, I thought that was very refreshing and a really nice approach to a book of this nature.

Martin: Thank you. We also discussed being angry if that would be a good idea. You can always write a book about ethical design and then blame everyone for doing it wrong or we thought that wouldn’t be as helpful.

Trine: Yeah, I think we decided very early on that we will leave it to others to be angry, and then we’ll focus on being optimistic. The whole book has been written with an optimistic mindset, meaning that if you’re not optimistic that you can actually do this, then it’s really hard to convince others to join you. So we’re aiming for optimistic.

Drew: That’s great.

Trine: Martin has touched upon it the fact that you can’t really, it’s very hard to make ethical transformation on your own and sometimes the answer to, do I try to, do I fight for it in this company or do I find another job, but sometimes the answer is finding another job. It’s actually interesting that the… And this also speaks towards what why it’s might be a good idea to actually start doing this. I recently read, there is an estimated 66% of millennials who actually want to start their own business because they’re so fed up with these big corporations where they can’t have any impact.

Trine: So if you’re opening up your processes and your work structures to people actually getting to have a say and actually allow them to make changes because millennials also a lot more value driven than the older generations. Then you may have a better chance at retaining talent, which is actually also one of the cases that we have in the book. We tried to really cover very broadly into in the sense that we know that ethical design is not just about product development. It’s not just about the website or the app. It’s not just about the business model. It’s not just about data handling or teams or work processes. It really is about it all, and we’ve really tried to include all of that so that it becomes apparent that this is not just about products.

Martin: If we go back to the guerrilla model and talk about you make small changes, you do that on your own and later on you will have to prove to your team and to your boss that you are actually doing something good. First of all, the ethical scorecard is a really easy method of establishing a baseline and then whatever you improve later on you can actually show that the things they are changing for the better. And that business case that you have to create is, in my experience, always that you end up doing things in a better way and it will not cost you more money, which is one of the best business cases that you can ever present to your organization. So sometimes it’s a good idea to work in the hidden for like two or three months, probably in a small team, create the changes, implement them, show the better results, and then go to your boss and say it would be a good idea to establish this as the way we work in the future because it’s actually, it’s not costing us any money, but it’s just giving us better results.

Martin: And the wonderful thing about online is that as a consumer, the competition is always just one click away. So as a consumer, you can move in any direction at any time if you want to. And business managers, they should be aware that they are in a market where there’s no loyalty in the market if you don’t behave well or if you are too expensive, the loyalty is gone in a second. So as a business, you really have to be serious about this.

Drew: The ethical design handbook is full of loads of really good examples, case studies, and practical information to get started. And it’s available now from smashing at smashingmagazine.com/books. So I’ve been learning all about ethical design. What have you been learning about lately?

Trine: So I’ve actually been researching a lot on the financial impacts on diversity or lack of diversity, however you want to… Well, most of the case studies are still due to lack of diversity, but that’s something that I’ve become increasing interested in; to understand how diversity can actually make for better businesses and better products. I’m also diving into some new and alternative approaches to design thinking and some activities and things that you can do there. So that’s what I’ve been up to since the writing work of the ethical design handbook stopped.

Martin: And for me currently, I’ve worked with the ethical design in the internet of things, which is actually quite interesting because if you monitor what’s going on in a factory and you collect a lot of data, you can do lots of mistakes. But you can also do a lot of things right if you have the right strategy. And then I’m trying to improve how I can throw a Frisbee longer with my sidearm shot.

Drew: I love it. If you, dear listener, would like to hear more from Trine or Martin, you can find Trina on the web at trinefalbe.com and Martin at MartinMichael.IO. Thank you for joining us today both. Do you have any parting words?

Trine: Buy the book.

Martin: I agree with her.

Smashing Editorial (dm, ra, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
stephanie-walter-300x300-1
11 Feb

Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

by TBSCategories: News

Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

Drew McLellan

Stéphanie WalterAs a developer myself, one of the things that I like about UI frameworks is that they often come with default styling, but is that something that we should be relying on in projects? Simply using the default styling and trusting that whoever produced the framework has done a really good job in designing those components? Join me for today’s podcast episode where I speak to UX Designer Stéphanie Walter about things we should be considering when building on a UI framework.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s a user centered designer and expert in mobile experience, who crossed delightful products and interfaces with a special focus on performance. She’s worked on projects for clients such as the University of Luxembourg, European Investment Bank, BMW and Microsoft to name but a few, and she helps those clients deliver successful projects to their audience all the way from strategy to the final product. She’s a Google Developer expert in product design and a passionate teacher sharing her knowledge in numerous blog posts, articles, workshops and conference presentations. So we know she’s an expert user experience designer, but did you know she once had a job fitting carpets with Sir Elton John? My Smashing friends, please welcome Stéphanie Walter. Hello Stéphanie, how are you?

Stéphanie Walter: Hi, I’m smashing and loved the introduction.

Drew: So I wanted to talk to you today about a particular issue and that’s the subject of using off-the-shelf user interface frameworks. Now you’re a user experience designer and you work with lots of different clients and your job is to help those clients create the best possible user experiences through crafting highly usable user interfaces. So the idea of being able to do that with an off-the-shelf set of tools seems like a bit of a stretch to me. Is the use of UI framework something you see a lot throughout your work?

Stéphanie: Yeah, it’s something I’ve seen a lot, especially in the last few years because I started working with an agency and now I work within the company. So in those super big IT tech teams and yeah, at the moment there’s a lot of framework UIs like the one that I’ve seen the most is Material-UI, basically Material design is a Google design kind of guidelines and thing, and Material-UI is the team from Angular, but also the team from React. They created their own framework using kind of the look and feel of the Material design from Google. But it has nothing to do with Google anymore. It’s just like they, I don’t know, I think they liked the look and feel. So at the moment, those are the two main UI framework I work with. And also there’s something called Ant Design, that’s grew quite popular.

Stéphanie: It’s a React framework. I don’t know if they have Angular too. I think it was made by a team in China. And it’s interesting because not only does it provide the components, everything in React, but if you go to their website you’ll also get the scratch files, which is actually quite interesting because then it kind of motivates or helps the designer build or shape the interface into the UI components used by that framework. So yeah, it’s something I’ve seen a lot, especially in big IT teams because most of the times those don’t have a designer. At the moment I’m basically UX team of one in a small team at a European investment bank. So it’s me as a UX designer. I work with a team of developers, business analysts, all the good people, but still is one designer for the whole project.

Stéphanie: Until I arrived there was no designer. So it’s kind of a solution implemented in a lot of companies, especially on internal products for instance. Where they usually say, okay, we don’t really need a designer for that. We just need something that works for our internal users and let’s just use a framework because it’s convenient for the developers. Most of the components are already there and since they don’t have designers in the team, then it’s kind of replacing, as to say, the role of a UI designer. Yeah, problem with that is that, okay, then you have the components, but the role of the UI designer is not just to decide about should the button be red, green, orange, blue, whatever. Usually the role of the UI designer is information architecture, understanding user needs. So everything that goes beyond the interface. So even if you have this kind of framework that kind of takes care of the whole UI, So visually what you see on the screen.

Stéphanie: You still need someone at some point to do the job of understanding what do we put on the screen, how is it going to behave? What happens when we click here? How does the user accomplish their goal? How do we go from point A to point B? Because we can use a model, we can use tabs, we can use all of the components. So that’s why it’s always kind of a little bit complex and tricky.

Drew: Is it possible, do you think be able to create a usable user interface using an off the shelf UI framework, or is it always going to be a bit of a compromise?

Stéphanie: I kind of hope so. I kind of hope so because otherwise I’m building not usable interfaces. So this answer is totally biased, but yeah, I think it is, but it also depends on the level of compromise you’re willing to do and there’s compromises on both sides. At the moment I’m compromising a lot of buttons for instance, because you have some really specific buttons in Material-UI, and I don’t really like the ripple effect on the button. I think it works great on mobile because on mobile you need a kind of a big feedback when user clicks on or touches the button. But then the steps is kind of ripple effect that goes all the way on the button. It’s a little bit overkill, especially when there’s a lot of button. But still we are going to keep this ripple effect because it would be super complex to remove it because this was built in to the React framework. And to have another hover effect on this button, something more subtle that will not be this kind of whooshy thing here. It would be super complex.

Stéphanie: So this is the kind of compromises you do. But on the meantime, I don’t compromise on specific things which is custom components. Where I was working before, the current client for a travel and airline company. And airline has some really, really super specific needs. The calendar for the airline for instance, you want to put prices, you want to put… if you don’t travel to this destination on a specific date, you don’t know when to put that, you have this departure and arrival and the basic calendar of most of those UI frameworks don’t provide these kind of things. So at some point you can say, okay, we will just use the calendar they have. And that’s it. You need to go beyond that. So most of the compromises are basically built on, do we use the basic component? Do we create a custom one that will fit the user needs? Or do we make a mix of the two? In the case of the calendar, for instance, we use the calendar grid, so we use the basic component and then we enhanced it with customization on top of that. So it was a lot of React development for that one.

Stéphanie: And yeah, so usually you do a lot of compromises.

Drew: So it sounds like using a user interface framework can get you a certain amount of the way there, but to really have a good user interface as a result of it, you need to do quite a bit of customization on top?

Stéphanie: Usually. Yeah.

Drew: Does that customization go beyond theming?

Stéphanie: Yeah, my developer wished it wouldn’t go beyond theming. Eugene If you listen to me. I think he would be super happy if we would just change a few colors on everything. But yes, at some point you need to go beyond the customization because first, like UI frameworks are like Lego tools is kind of a toolbox. So you have a lot of different components in the box, but this doesn’t build a page. You still need a header, you still need a footer. You still need extra content that was not in the framework. So sometimes you can tweak a component into what you needed. From what I understood, we are using the card component to build a modal windows, but the thing with the modal windows is that it doesn’t really behave like a card.

Stéphanie: You are kind of going a little bit beyond that. You need a background with obscurification. You need to trigger it on click while usually your card is already there in the interface. So we are using this card component because it has a lot of the things we need like the background, a header and a title at the top, some buttons at the bottom. So we have the structure and then we tweak it a little bit. But we end up with some conflict sometimes about semantics, HTML as well. Because for instance, I wanted to have buttons that didn’t have button shapes, so just like link button and the developer said, “Okay, so we use a link like your href link.” I said, “No, this is not a link. It’s a button. When they click it, it doesn’t open a new page. It clears everything that is into the form.”

Stéphanie: So it should be technically from a semantical point of view, it should be a button. “Yeah. But it doesn’t exist in the framework.” I say “So okay, I know so what do we do?” So usually you start discussing these little things and since I’m really annoying my developers with accessibility also, this is another extra layer of trying to make sure that we have the basic components that they work well with. But also that they are semantically like I don’t want to have buttons with gifs within gifs within gifs. Otherwise we’ll have issues in the end.

Drew: I guess starting a new project that’s going to use a UI framework, you probably need to start with some sort of user research.

Stéphanie: Yes.

Drew: Is that fair?

Stéphanie: You should. You need to. So yes, usually you can have all the components you want. You still need to know what do your users need on the pages, how are they going to navigate? You need to build a flow. So usually even before deciding on a framework, what we do is we go to our users, we talk to them, we try to understand their needs. So at the moment I’m quite lucky because the users are internally within the bank. So we do a lot of workshops with them and you have to imagine it’s a super complex interface. We are migrating from something that was built, I don’t know, I think 10 or even 15 years ago to something all new shiny using Material-UI React. So it’s quite a big change and you have to understand that during those 15 years, everyone who wanted something could go to the support and then they ask the IT team to implement it. So at the moment my interface is like 400 pages with tables, within tables, within tables, with other tables, and stuff that shouldn’t even be in tables.

Stéphanie: Like we have a lot of things that are just key value, key value, key value. So they build the table with two columns. I’m like, “Nope, maybe we can do something better with that.” So at the moment what we are doing is we did some user research to understand the different goals of the users. So what we identified is that what they do with the interface, they have some planification goals. They need to plan their work. So I want to know that this operation is going to go to this meeting, so I need that on that schedule, stuff like that. They want to monitor a thing, they want to report the data. So monitoring is just like looking at the data and making sure everything is fine. Reporting is being able to exploit the data, to do something with it they want to share and to kind of collaborate with colleagues and all of that we discovered by discussing directly with the users.

Stéphanie: And what we discovered is that actually some of the things we were planning on migrating at the end are some of the most important things on a daily basis for the user. So the planification user goal is one of the kind of biggest one at the moment. So we are really, really working on that. So yeah we do use the interview and now we are in the phase where at the moment we are super high level saying okay we need to build the shell, we need to understand navigation. But at the moment we didn’t really go through all of the data and this is now what we are going to do. And it’s interesting because we have a lot of tables and we said we can either go the kind of not smart way and just put the tables in the new interface and we’re done, or we can say, okay, let’s try to understand what those tables are, What do our users use this table for?

Stéphanie: And then maybe some of the tables could be displayed as data visualization and then to do that you need to understand the whole business So that the data makes sense. So if you have a nice framework and you say, okay, let’s use this chart… I think is called chart JS framework. You have a lot of things, you can have histogram, pie charts and graphs and everything, but at some point you still need a designer to help you decide. Okay, this data, does it make sense if we show it into a graph or it makes more sense to show it as a pie because we want to show part of the whole, or we want to compare evolution for one country in the last 10 years, then a histogram is more interesting. So based on what the user wants to do with the data, you are going to display them a whole other way.

Stéphanie: And usually it’s not a developer job to do that. Our developer, they’re super smart guy. I’m sorry, but I honestly work with guy developers, I wish I had some ladies, but no. None of them are women. So super smart guys but they are not super qualified to say, okay, this data should be displayed like that, that, that and that. So in the end you still need some designers go to talk to the users, understand what you can do with the data and this goes far beyond just saying, okay, this should be a tab bar or this should be a navigation on the left.

Drew: And after making those sorts of decisions based on talking to the users. Would you typically take the resulting prototypes or designs back to users to test them again to see if they understand your type of chart choice for example?

Stéphanie: Yeah, we did that a lot actually, which is really nice because then you don’t develop something until you know it’s going to be useful and usable. So it depends. If it’s quicker to actually develop the thing because they have already most of the components, what I usually do is I do really quick paper prototyping and then we develop the thing because it’s quick, even without the data. If it’s something complex, something really, really new that will take a lot of time to develop, then we say, okay, we design a few screens and we do some testing directly on the screen. So we have a tool it’s called InVision, where basically you put all of your design, you can create links between the different parts. The thing is it also depends what you want to test. If you want to test phones for instance, it’s a nightmare to test those in InVision because the people can’t really feel them and especially on mobile phone for example.

Stéphanie: So it’s always kind of being smart. What’s the fastest and cheapest way? Is it faster and cheaper to test only designs. Is this enough? For forms usually, not really because you have auto completes all of the heavy lifting you put in the front end who have actually the user fill a form so for forms, maybe it’s more efficient to actually build a form and test it. But for new things, yeah, we do a lot of designs. We go to the users. So at the moment we either do one-on-ones, but my users are really busy people. It’s a European investment bank so they don’t have that much time. So what we usually do is that if we come to one-on-one with the users, we do some small meetings, like more like focus groups. And it’s also interesting because then you have kind of a confrontation sometimes. Some people say, “Yeah, I think it works for me because I work like that and that,” and then there’ll be other people who are like, “Oh you work like that? Actually no, I do it like that and that.”

Stéphanie: So it’s also interesting to kind of have a few people in the room and to listen just to the conversation, taking notes and say, “Oh maybe then we could do that” and “This component would be better based on what I just heard.” And things like that.

Drew: If you’re working with a more general audience for your product. So perhaps not internal users like you have, but more the general public, are there inexpensive ways that designers can get that use of research in? Are there easier ways if you don’t know directly who your users are going to be?

Stéphanie: You should know who they are going to be otherwise it does the job of the marketing people before building the product. But yeah, we did some guerrilla user testing for instance, You can still use InVision for instance. So you can build some prototypes in InVision and then you can recruit the users through social media, for instance. I was working for a product that helped, what is the name, car dealerships mechanics who repair things and then to also inform the client about extra repairs, things like that. So we had already kind of a growing community on LinkedIn and Facebook. So what you can do is you can recruit those people. You can do remote testing, like we are having conversation in a tool like an online tool. You can do some screen sharing. So we did that for some project also.

Stéphanie: I would just give you one advice is test the tool before, because I was using, it was called appear.in. But I think they changed the name to Whereby or something, but it’s really in the browser who I said, okay, it’s nice because then the users don’t need to install anything but do users were not on a real computer. They were into VM, into a Citrix and they didn’t have microphones so what we ended up doing is like they used my tool to share the screen. They were clicking on the prototype and at the same time I had them over the phone, like a landline phone, to talk to them directly. So there’s always, this was a quite cheap because it was a wonderful day of recruiting, I think we had 10 users or something like that. Yeah, you can do a lot of things even if you can’t go face to face, I’ve done a lot of usability testing directly on Skype or things like that. So there’s always some cheap ways to do that.

Drew: When it comes to choosing a UI framework to work with, if that’s the route that you’re going, is that something that you would leave just to the developers or is that something that designers should get involved in too?

Stéphanie: For me, you should involve the whole team. Like the designers, the developers, maybe also architects if you have some, because how the framework is built might also influence these kind of things. Unfortunately, most of the time when they arrive on the project, the framework was already decided. No, actually it’s funny, either it’s already decided or they ask me to validate their choice of the framework, but I didn’t do any reviews or research. I have strictly no idea what’s in the project because they didn’t even show me their screens. They’re like, “Yeah, do your thing. We can use this framework.” I don’t know. Well, do we have a screen? So they ended up showing you a few screens, which was a Windows native app they wanted to migrate in the cloud. They said, “Yeah, we only need the buttons and mostly like forms and things like that.”

Stéphanie: But it’s really hard to say, “Yeah, go for this framework, we have all of the components we need.” Or like, “Don’t go if you don’t have a rough idea of what’s your content going to be, what is the navigation.” So I think you should still have kind of a global overview before choosing your frameworks unless you’re 100% sure you have all of the components. But I have a feeling that most of the time the framework choice is basically based on what technologies do developer like at the moment, do they have experience with a framework before that? We used Ant on some projects just because a few developers had experience with that and they really liked it and they were kind of efficient using Ant. And for the Material React UI it’s the same. It’s like because the developer already used it on previous projects, so they are efficient with it.

Drew: So really it’s got to be a balance between what the developers are comfortable with, what they know, what’s going to work with their technology stack and then what the requirements of the product are in terms of creating a good user interface. And you somehow need to balance the two of those to find the ideal framework for it.

Stéphanie: Yes. I have a kind of a specific requirement for some project, which is… I’m in Luxembourg, we have a lot of European institutions and things like that, so we have an extra accessibility requirement for some of those. And usually when the framework was decided, they didn’t really check about the accessibility of their framework and then they come back a few months after the beginning of the project saying, “Oh, just told us that there’s this new law and we should be accessible but we don’t know how to do that.” Like yeah, it’s a little bit too late. So for me, to choose a framework you need really to know all of the constraints at the beginning of the project and if accessibility is one of them you need to test your components and make sure that they are going to be accessible. But I am not a React or Angular developer, but I’m pretty sure that it’s super complex to turn a not accessible UI framework into something accessible. I guess it might be a little bit complex to rebuild all of the components, so things like that.

Drew: If you find yourself working on a project where that process hasn’t taken place and a UI framework has already been chosen, is there a danger that the user interface could start being influenced by the components that already exist within that framework rather than being driven by the needs of the user?

Stéphanie: It really, honestly, most of the projects I worked on, eventually you end up having a lot of trade offs, even if you really try to push. So it’s mostly about balance and discussing with the developers. So usually what I do is we do some wire frames, even quick paper wire frames, say okay, on this page we will need that and that and that component, the first thing I do is I ask the developer do we have that in our framework at the moment? What does it look like? And then we decide together, okay, this is a component that would do the job or okay this will not do the job. Do we tweak it? Like do we still keep the component but change it a little bit so that it does the job, or do we build something from scratch?

Stéphanie: And at the end of the day it will depend on the budget of course. So you ended up doing trade offs. Like I would be okay for small components that are almost never used if they’re not perfect and there’s kind of few issues. But for main navigation, main structure, things that you see all the time on the screen, for instance, this really needs to work. The user’s needs to understand how they work efficiently and yeah, it’s, as you said, finding a balance between the ideal experience you wish you would have if you didn’t have any framework and what you have at hand and the budget and also the timing. If we say, okay, for these sprints, the feature needs to be finished at the end of this sprint, and then they say, okay, but if you want your components we will never finish the feature at the end of this sprint then you start discussing, okay, do we finish this feature in the next screen, do we take more time to do it properly? And usually it really depends.

Stéphanie: The things that frustrate me the most is when I know that we use a crop fix component and they say to me like, Oh no, don’t worry. We will fix that later. And I knew that the later unfortunately might never happen. So depends on the team. But after a while you have the experience and you know, will this later arrive and or will it not? Yeah, it’s about compromises. When you are working with these kind of tools.

Drew: As a developer myself, one of the things that I like about UI frameworks is that they often come with default styling. So that means that I don’t necessarily need to have a designer maybe to help me with the look and feel of all the components. Is that something that we should be relying on in projects? Just the default styling and trusting that whoever produced the framework has done a really good job in designing those components? Or would you be styling those components yourself?

Stéphanie: I think it truly depends. The problem for instance with Material-UI is the look and feel of your a web app will be basically the configured Google products. So if you don’t actually change the font, change a few colors and kind of bring your own brand identity and do that, you’ll have a product that will just looked like any Google product, which could be a good thing because if your users are used to Google products it might help them understand it. So usually if you don’t have a designer in the team, do you have any choice? Like a lot of the different work I’ve seen, they come with custom themes so at least you can change the colors. I think you can change the fonts also pretty easily. But again, like if you change the colors and you’re not super good at design or even accessibility, maybe the colors you will use will clash, they might have contrast problems.

Stéphanie: For instance, I love orange, but it’s one of the most annoying color to work with because to have a real accessible orange, for instance, as a button with white text, it almost looks brownish. And if you want to have this really shiny orange, you need dark text on top of it to make it readable but it kind of makes your interface look like Halloween at the end of the day. Yeah, I see you laughing. But it’s true. So it’s always about these kind of compromises and say if you’re a developer and you want to use the framework as it is and you don’t have a designer, I think it’s still better than not having anything and building it from scratch and then it’s super complex to use. But the thing is, just because you have the components doesn’t mean you will build a great interface. It’s like Lego bricks. If you have the Lego bricks, okay it’s fine, but you can do a real nice spaceship or you can do something that isn’t holding together and will fall apart because you didn’t have really a plan.

Stéphanie: So design is kind of more than that. Design is about really understanding what’s going to be on the screen, how it will work. And I know some developers who actually have the capability to do that. So they are really good with usability guidelines and they understand a lot of design rules, for instance. So when it comes to choosing the components, they’re really good at that. And I know developers who have no idea what components to choose and choose the first one that does the job. But after a while it doesn’t work anymore. Like tabs for instance, we had an interface where some developers chose tabs. I think it makes sense at the beginning when you only have three items. But then there was 12 items on the screen and then you have the tabs that are three lines of tabs, and all of those are the same level one tabs, and there’s tabs within tabs. So they had the component, it looked nice because they use the framework, but it wasn’t really usable.

Stéphanie: And I had the same with like a modal windows for instance. Where they build the projects without a designer and after a while I think the client asked for more and more stuff into this modal. So they ended up with a screen with a table and when you click on add a row, you open a modal, and in this modal you have two tabs, and then in one of those tabs you even have another table and then they wanted to add an extra stuff into that, I was like, okay, maybe we can put a modal on top of a modal. And at some point the designer would reply, okay, if you have that much content in the modal, it should not be a modal window. It should be a page. So even if you have the component, you still need kind of an architect to do the plan and make sure that all of those components work well together.

Drew: So if as a designer, you’re being asked to change the styling of some components, would you just try and change all of the styling? Would you customize all of it or are there certain areas that you’d focus on?

Stéphanie: Colors I think because it’s the first thing you see, colors can actually bring you identity. If you have like a strong brand identity, at least having the colors of your product on the buttons or the icons and things like that, already helps you customize the framework. Fonts because I think it’s easy, if the framework is well-built, usually you change the whole font family in someplace and then it should kind of cascade on the rest of the site. So colors and fonts is I think two easy ways to quickly customize the framework. Icons is another nice way to bring personality, but it might be difficult because from what I’ve seen, most of the framework come with custom icons or Font Awesome or like a library already built in. So to replace those, first you need a lot of icons if you want to replace them all. So it might be a little bit complex. I have also seen frameworks that lets you choose which icon pack you want to use. like Font Awesome, Glyphicons and some of the other ones. So this is the kind of things you can quite easily customize.

Stéphanie: And then it’s about look and feel, for instance the header, usually you have different kinds of headers, footers. How do you navigate things like that. So there’s already a lot of small customization you can bring so that it doesn’t look Material-UI-ish, it more looks like your brand and then you can play around with border radius’s for instance. Whether you want completely rounded buttons, or you want square buttons or you want something in the middle like shadows also. So some small stuff that are kind of usually easy to customize because most of those frameworks have them in CSS variables. This is the kind of small things that you can customize without I think a lot of effort, except for these ripple effects. I hate that. I’m going to fight it. I kind of hope they change it eventually.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn’t easy to change? Is that just a case of speaking to your developers to find out what’s going to be easy to customize and what’s not going to be easy?

Stéphanie: Yeah, usually, especially if they’re used to work with the framework, they know what’s easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don’t know if we can customize it because I can’t see it in the API. I was like, what API? It’s like CSS class, CSS definition. You remove the uppercase from the CSS and it’s done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there’s no API for that, I think you can change it in CSS.

Stéphanie: But then it’s complex because if you have to change this in like all of the CSS line. So it’s usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don’t know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I’m looking forward to it, but we are still Internet Explorer 11 at the moment. And what’s happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stéphanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it’s like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it’s this kind of discussion also, do we want to customize it but then it’s kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there’s an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stéphanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn’t damage the performance and if he doesn’t damage the rest of your experience, otherwise it’s perfectly normal that the browser element don’t look the same on any browsers. So at the end, don’t customize everything.

Drew: I guess it’s a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you’ve got your UI framework in place, you’ve got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stéphanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stéphanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a ‘Read me’ tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it’s after three, what happens in the meantime?

Stéphanie: So there’s a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it’s supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don’t have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it’s kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stéphanie: Everything you’ve customized is kind of starting to become your own little design system. So at the end you’re building a design system, but instead of building it from scratch, you’re basically building it using React, Material or, what was the other one? Ant or something like that. So it’s the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stéphanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn’t do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it’s implemented, we do tests to make sure it works. And then again we go back to the users.

Stéphanie: And it’s also interesting because we are building a community with the users. So they’re actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don’t have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don’t have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don’t have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it’s deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you’ve built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you’ve experienced where a new version has come, your developers want to update but it might have implications on the design?

Stéphanie: Yeah. The thing is we have test environments, so they’re really quick and easy thing to do is like, okay, let’s put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it’s not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stéphanie: So they’re already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I’m not a developer but I feel at some point you’ll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stéphanie: It does. Okay. So yeah, you make sure it still works, but I don’t have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don’t have any new version every year or something. It’s a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you’re building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they’re currently working on a project where they’re rebuilding and riffing on React. The first version was built three years ago with another technology. I really don’t remember the technology, but they say, okay, we are three years later, they’re already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you’re in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stéphanie: I feel we covered a lot of things. Well, the thing is like, there’s always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don’t design or build in a silo and try to have other people at least look at what you’ve created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don’t ask the designer to put paint on top of the framework at the end of the project because it’s kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We’re all about learning. So what is it that you’ve been learning lately?

Stéphanie: I’ve been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stéphanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it’s really super complex and there’s… Apparently not everyone agrees on the explanation of most of those illusions, but it’s interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it’s interesting to see like all the different aspects of psychology. So the interesting part of this course is it’s an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it’s actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it’s nice because it’s an online class, so I’m basically learning stuff on my couch with some tea, and yeah, that’s really, really cool.

Drew: Oh, that’s super interesting. If you, dear listener, would like to hear more from Stéphanie. You can follow her on Twitter where she’s @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stéphanie. Do you have any parting words for us?

Stéphanie: Thanks for having me. It was a smashing experience.

Smashing Editorial (dm, ra, il)


Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us